***SPAM*** Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.29

[Ron Livne]

Roland,

Any chance create_qp_flags will get in?

Thanks,
Ron


On Tue, Dec 23, 2008 at 12:25 AM, Roland Dreier <rdreier at cisco.com> wrote:
> I guess now is probably a good time to send out my plans for the
> 2.6.29 cycle.  I'm not operating at full speed (since I'm kind of on
> paternity leave and kind of on holiday break), but I'll try to get
> through as much of my backlog as possible.
>
> I should mention that I've changed the way I manage my git tree
> slightly.  I've started using "topic" branches to organize the patches
> I have queued; so for example I'll put IPoIB changes in my "ipoib"
> branch and ehca changes in my "ehca" branch.  Then I merge everything
> that I consider ready for the next merge window into my "for-next"
> branch (which is included as part of Stephen Rothwell's linux-next
> tree).  Any topics that I'm not sure are ready get to stay on their
> own branch until they are ready (or get dropped); for example, I've
> had an "xrc" branch for XRC work for a while now.
>
> 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.
>
> As usual, when submitting a patch:
>
>  - Give a good changelog that explains what issue your patch
>   addresses, how you address the issue, how serious the issue is, and
>   any other information that would be useful to someone evaluating
>   your patch or reading it years from now.
>
>  - Please make sure that you include a "Signed-off-by:" line, and put
>   any extra junk that should not go into the final kernel log *after*
>   the "---" line so that git tools strip it off automatically.  Make
>   the subject line be appropriate for inclusion in the kernel log as
>   well once the leading "[PATCH ...]" stuff is stripped off.  I waste a
>   lot of time fixing patches by hand that could otherwise be spent
>   doing something productive like watching youtube.
>
>  - Run your patch through checkpatch.pl so I don't have to nag you to
>   fix trivial issues (or spend time fixing them myself).
>
>  - Read your patch over so I don't see a memory leak or deadlock as
>   soon as I look at it.
>
>  - Build your patch with sparse checking ("C=2 CF=-D__CHECK_ENDIAN__")
>   and make sure it doesn't introduce new warnings.  (A big bonus in
>   goodwill for sending patches that fix old warnings)
>
>  - Test your patch on a kernel with things like slab debugging and
>   lockdep turned on.
>
> And while you're waiting for me to get to your patch, I sure wouldn't
> mind if you read and commented on someone else's patch.  None of this
> means you shouldn't remind me about pending patches, since I often
> lose track of things and drop them accidentally.
>
> Core:
>
>  - Multiple CQ event vector support.  I don't see much progress on
>   making this actually usable or useful, but maybe the best way to
>   make progress on getting the correct interface for applications to
>   actually figure out which vector to use is to merge the multiple
>   vector support for some low-level drivers.  I have the mlx4 changes
>   merged, and I plan to try and do some analogous changes for mthca.
>   A resurrection of the ehca multiple vector support would be welcome
>   as well.
>
>  - I plan to merge Aleksey's patches for RDMA CM IPv6 support when I
>   have a version that applies to the current kernel.  Might be a good
>   idea for cxgb3 and nes guys to look at this and make sure that we
>   at least don't have any kernel crashes caused if someone tries to
>   make an IPv6 connection.
>
> ULPs:
>
>  - I sincerely appreciate everyone who resent IPoIB patches recently.
>   I will review them and apply this week most likely.
>
> HW specific:
>
>  - A bunch of ipath fixes.
>
>  - A bunch of nes cleanups and fixes.
>
>  - A few ehca fixes and cleanups.
>
> Here are a few topics that I believe will not be ready in time for the
> 2.6.29 window and will need to wait for 2.6.30 at least:
>
>  - Jack's XRC patch set.  I think we're getting closer to converging
>   here, but I still want to get a clean solution for the "free XRC
>   domain with other objects still associated because multiple
>   contexts share XRCDs" problem.
>
> Here all the patches I already have in my for-next branch:
>
> Chien Tung (2):
>      RDMA/nes: Add loopback check to make_cm_node()
>      RDMA/nes: Cleanup warnings
>
> Dave Olson (4):
>      IB/ipath: Don't count IB symbol and link errors unless link is UP
>      IB/ipath: Only do 1X workaround on rev1 chips
>      IB/ipath: Fix spi_pioindex value
>      IB/ipath: Add locking for interrupt use of ipath_pd contexts vs free
>
> David Disseldorp (1):
>      IB/iser: Avoid recv buffer exhaustion caused by unexpected PDUs
>
> Faisal Latif (6):
>      RDMA/nes: Cleanup cqp_request list usage
>      RDMA/nes: Lock down connected_nodes list while processing it
>      RDMA/nes: Avoid race between MPA request and reset event to rdma_cm
>      RDMA/nes: Forward packets for a new connection with stale APBVT entry
>      RDMA/nes: Fix TCP compliance test failures
>      RDMA/nes: Check cqp_avail_reqs is empty after locking the list
>
> Joachim Fenkes (1):
>      IB/ehca: Fix locking for shca_list_lock
>
> Julia Lawall (1):
>      IB/ehca: Remove redundant test of vpage
>
> Michael Ellerman (1):
>      IB/ipath: Fix pointer-to-pointer thinko in ipath_fs.c
>
> Ralph Campbell (3):
>      IB/ipath: Improve UD loopback performance by allocating temp array only once
>      IB/ipath: Fix PSN of send WQEs after an RDMA read resend
>      IB/ipath: Check return value of dma_map_single()
>
> Roland Dreier (1):
>      mlx4_core: Delete incorrect comment
>
> Stefan Roscher (1):
>      IB/ehca: Replace modulus operations in flush error completion path
>
> Yevgeny Petrilin (1):
>      mlx4_core: Add support for multiple completion event vectors
>
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>