Hey Roland,
I was about to post v2 of my patch to avoid port space collisions with
the native stack. Can we get that 2.6.24? It is high priority IMO.
I've tried to solicit review on it, but I think folks are reluctant... ;-)
Steve.
Roland Dreier wrote:
With 2.6.24 probably opening in the not-too-distant future, it's
probably a good time to review what my plans are for when the merge
window opens.
At the kernel summit, we discussed patch review (doing a web search
for "kernel summit" "reviewed-by:" should turn up lots of info on
this). Due to an unfortunate combination of vacation and conference
travel, summer colds, and other inconveniences, I am very backed up on
reviewing. And in any case, I've allowed too much code review to be
dumped on me -- when there are dozens of people working on IB and RDMA
stuff, it obviously doesn't work to expect me to do all the reviewing.
Unfortunately, due to the length of the backlog and the fact that
2.6.23 seems fairly close, some of the things listed below are going
to miss the 2.6.24 merge window. So, although the plan is to phase in
requiring "Reviewed-by:" gently, for this merge, if you can get
someone other than me to review your work, then the chances of it
being merged increase dramatically. I'm talking about a real review--
ideally, someone independent (from another company would be good) who
is willing to provide a "Reviewed-by:" line that means the reviewer
has really looked at and thought about the patch. There should be a
mailing list thread you can point me at where the reviewer comments on
the patch and a new version of that patch addressing all comments is
posted (or in exceptional cases, where the patch is perfect to start
with, where the reviewer says the patch is great).
For example, given the number of IPoIB changes pending, it might be a
good idea for the people submitting them to get together and trade
reviews (ie "If you review my patch, I'll review your patch"). There
are a few cases where getting a review may not be necessary. First of
all, trivial and obvious patches don't need a review. It's a
judgement call what is trivial or obvious, and it's always a good idea
to provide a changelog that makes it clear why a patch is trivial and
obviously correct. Second, hardware driver patches may not make sense
to anyone outside of the company whose hardware the driver is for.
Still, in this case, an internal Reviewed-by: would be nice, and also
a changelog that explains the reason for the change always helps
(don't just tell me what your patch does, but also explain what the
patch fixes and what the impact of the current situation is).
Anyway, here are all the pending things that I'm aware of. As usual,
if something isn't already in my tree and isn't listed below, I
probably missed it or dropped it by mistake. Please remind me again
in that case.
Core:
- My user_mad P_Key index support patch. I'll test the ioctl to
change to the new mode and merge this I guess, since Hal and Sean
have tested this out.
- A fix to the user_mad 32-bit big-endian userspace 64/32 problem
with the method_mask when registering agents. I'll write a patch
to handle this in a way that doesn't change the ABI for anything
other than the broken case and hope to get someone to review this
so it can be merged.
- Sean's QoS changes. These look fine at first glance, and I just
plan to understand the backwards compatibility story (ie how this
works with an old SM) and merge. Anyone who objects let me know.
- Sean's IB CM MRA interface changes. Don't know at this point. It
seems OK but I'm not clear on what if any real-world improvement
this gives us.
ULPs:
- Pradeep's IPoIB CM support for devices that don't have SRQs. I
think the basic approach makes sense (I don't think faking SRQs at
some other layer is really feasible) and I need to find time to
look at the details to see if the current patch looks workable. I'm
likely to merge this; getting an independent Reviewed-by: would
certainly be appreciated too.
- Moni's IPoIB bonding support. This seems mostly an issue of
getting the core bonding maintainer's attention. However getting a
Reviewed-by: for the IPoIB changes wouldn't hurt too.
- Rolf's IPoIB MGID scope changes. Certainly we want to fix this
issue but the specific changes need review.
- Eli and Michael's IPoIB stateless offload (checksum offload, LSO,
LRO, etc). It's a big series that makes quite a few core changes.
I think it needs some careful review and is probably at risk of
missing this merge window. Sorting in order of invasiveness so we
can merge at least some of it (if splitting it makes sense) might
be a good idea.
HW specific:
- I already merged patches to enable MSI-X by default for mthca and
mlx4. I hope there aren't too many systems that get hosed if a
MSI-X interrupt is generated.
- Jack and Michael's mlx4 FMR support. Will merge I guess, although
I do hope to have time to address the DMA API abuse that is being
copied from mthca, so that mlx4 and mthca work in Xen domU.
- ehca patch queue. Will merge, pending fixes for the few minor
issues I commented on.
- Steve's mthca router mode support. Would be nice to see a review
from someone at Mellanox.
- Arthur's mthca doorbell alignment fixes. I will experiment with a
few different approaches and post what I like (and fix mlx4 as
well). I hope Arthur can review.
- Michael's mlx4 WQE shrinking patch. Not sure yet; I'll reply to
the latest patch directly.
Here are a few topics that I believe will not be ready in time for the
2.6.24 window and will need to wait for 2.6.25:
- Multiple CQ event vector support. I haven't seen any discussions
about how ULPs or userspace apps should decide which vector to use,
and hence no progress has been made since we deferred this during
the 2.6.23 merge window.
- XRC. Given the length of the backlog above and the fact that a
first draft of this code has not been posted yet, I don't see any
way that we could have something this major ready in time.
Here is the complete list of patches I have in my for-2.6.24 branch
waiting for the merge window so far. Mostly I haven't merged anything
big out of my backlog, so this is essentially all
Ali Ayoub (1):
IB/sa: Error handling thinko fix
Anton Blanchard (3):
IB/fmr_pool: Clean up some error messages in fmr_pool.c
IB/ehca: Make output clearer by removing some debug messages
IB/ehca: Export module parameters in sysfs
Dotan Barak (1):
mlx4_core: Use enum value GO_BIT_TIMEOUT_MSECS
Eli Cohen (2):
IPoIB: Fix typo to end statement with ';' instead of ','
IPoIB: Fix error path memory leak
Michael S. Tsirkin (2):
mlx4_core: Enable MSI-X by default
IB/mthca: Enable MSI-X by default
Peter Oruba (1):
IB/mthca: Use PCI-X/PCI-Express read control interfaces
Roland Dreier (6):
IPoIB: Make sure no receives are handled when stopping device
IB: find_first_zero_bit() takes unsigned pointer
mlx4_core: Don't free special QPs in QP number bitmap
IB/mlx4: Use set_data_seg() in mlx4_ib_post_recv()
IB/ehca: Include <linux/mutex.h> from ehca_classes.h
IB/mlx4: Fix up SRQ limit_watermark endianness
Steve Wise (1):
RDMA/cxgb3: Make the iw_cxgb3 module parameters writable
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
