[lkml]   [2007]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ofa-general] Updated InfiniBand/RDMA merge plans for 2.6.24
No mention about the iwarp port space issue?

Here is the status of the current proposed patch:

- needs another round of changes based on Sean's feedback

- Arkady raised issues about the pain this puts on admins

- it forces services like nfs-rdma, which already separates the nfs-rdma
server by port number, to needlessly use a separate subnet for the rdma

I'm at a loss as to how to proceed.

Any ideas?


Roland Dreier wrote:
> Since 2.6.23 still isn't out, and I've managed to reduce my patch
> review backlog a bit, it's probably a good idea to give another update
> about what I have queued for 2.6.24 already and what I hope to get to
> before the merge window opens.
> Core:
> - My user_mad P_Key index support patch. Merged this, although I
> still owe Sasha a patch to update libraries to use this.
> - A fix to the user_mad 32-bit big-endian userspace 64/32 problem
> with the method_mask when registering agents. Merged.
> - Sean's QoS changes. Merged.
> - Sean's IB CM MRA interface changes. I merged these -- what the
> heck, if it breaks we can back them out.
> ULPs:
> - Pradeep's IPoIB CM support for devices that don't have SRQs. Sean
> started reviewing but I didn't see any updated patches.
> - Moni's IPoIB bonding support. Seems like we found a clean set of
> changes, and these will go in via another (Jeff Garzik's?) tree.
> - Rolf's IPoIB MGID scope changes. No review progress here.
> - Eli and Michael's IPoIB stateless offload (checksum offload, LSO,
> LRO, etc). Not much review progress here; I'll try to chip away at
> the series and see what we can get into 2.6.24.
> - Or's IPoIB/userspace multicast coexistence stuff. I think we've
> converged on this; I'll merge this once a final version of the
> patch appears.
> 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. Merged. I guess the fix for
> running in Xen domU may need to wait for 2.6.25, but I'll see what
> I can do.
> - ehca patch queue. Merged everything I think.
> - Steve's mthca router mode support. No one looked at it, seems like
> it's at risk of missing the window.
> - Arthur's mthca doorbell alignment fixes. I still need to check
> various approaches; I'll definitely merge something for 2.6.24.
> - Michael's mlx4 WQE shrinking patch. May miss the window and go for
> 2.6.25, I'll see if I can get to it.
> 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.
> ===========
> I keep patches in a git tree, available from
> git://
> There are several branches of interest in this tree:
> for-2.6.23 - changes queued for merging into the current kernel release
> for-2.6.24 - changes queued for the next merge window
> for-linus - changes I have asked Linus to pull upstream
> for-mm - pulled by Andrew for inclusion in -mm
> I frequently rewrite history and rebase my tree, so the best way to
> track it is to keep a clone of Linus's tree around and then pull a
> fresh copy of my tree with
> git clone --reference /path/to/linus/tree \
> git://
> If you would like me to merge a patch, please send it to me as soon as
> it is ready. Do NOT wait for the merge window to open; if your change
> is not strictly a fix and you send it to me after the merge window
> opens, then it will likely have to wait for the next merge window.
> Please let me know if your patch is a fix that should go into the
> current release or if it can wait for the next merge window; if it is
> a fix, please describe the severity of the issue your are fixing, so I
> can make a good judgement about which release it should go into.
> Including a good changelog entry that explains what you are changing,
> why you are changing it, and how your change accomplishes your goal
> will greatly increase the chance of your patch being merged promptly.
> Getting an independent review and a Reviewed-by: line also helps a lot.
> The files Documentation/SubmittingPatches and Documentation/SubmitChecklist
> in kernel source tree also have a lot of good advice that makes it
> easier for me to handle your patches.
> =======
> Here is the complete list of patches I have in my for-2.6.24 branch:
> 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
> Hoang-Nam Nguyen (4):
> IB/ehca: Use remap_4k_pfn() to map firmware contexts to user space
> IB/ehca: Fix large page HW cap defines
> IB/ehca: Fix mem leak of firmware ctrlblock in ehca_create_srq()
> IB/ehca: Adjust 64-bit alignment of create QP response for userspace
> Jack Morgenstein (5):
> IB/mlx4: Display misc device information under /sys/class/infiniband/
> mlx4_core: Support ICM tables in coherent memory
> mlx4_core: Write MTTs from CPU instead with of WRITE_MTT FW command
> IB/mlx4: Implement FMRs
> mlx4_core: Increase max number of QPs per multicast group to 56
> Joachim Fenkes (11):
> IB/ehca: Refactor hvcall tracing
> IB/ehca: Print return codes as signed decimal integers
> IB/ehca: ehca_gen_warn() should always print
> IB/ehca: Add check for max #SGE to create_qp()
> IB/ehca: Path migration support
> IB/ehca: Serialize MR alloc and MR free hvCalls
> IB/ehca: Replace get_paca()->paca_index by the more portable raw_smp_processor_id()
> IB/ehca: Bump version number and change its format
> IB/umem: Add hugetlb flag to struct ib_umem
> IB/ehca: Only use MR large pages for hugetlb regions
> IB/ehca: Return srq_attr->max_sge in ehca_query_srq()
> 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
> Ralph Campbell (1):
> IB/core: Fix handling of multicast response failures
> Roland Dreier (14):
> 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
> IB/iser: Remove unnecessary includes
> mlx4_core: Change capability decoding: SRC->XRC
> IB/umad: Add P_Key index support
> IB/umad: Fix bit ordering and 32-on-64 problems on big endian systems
> IB/uverbs: Make ib_uverbs_release_event_file() static
> mlx4_core: Reserve the correct number of MTT segments
> mlx4_core: Fix meaning of dev->caps.reserved_mtts
> IB/mthca: Increase max number of QPs per multicast group to 56
> Satyam Sharma (1):
> IB/ehca: Misc cpuinit section annotations and #ifdef cleanups
> Sean Hefty (7):
> IPoIB: Specify Traffic Class with path record queries for QoS support
> IB/sa: Add new QoS fields to path record
> RDMA/cma: Add ability to specify type of service
> RDMA/ucma: Allow user space to set service type
> IB/srp: Add QoS support through service ID
> IB/cm: Modify interface to send MRAs in response to duplicate messages
> RDMA/cma: Queue IB CM MRAs to avoid unnecessary remote retries
> Stefan Roscher (2):
> IB/ehca: Small QP userspace support
> IB/ehca: Support more than 4k QPs for userspace and kernelspace
> Steve Wise (2):
> RDMA/cxgb3: Make the iw_cxgb3 module parameters writable
> RDMA/cma: Use neigh_event_send() to start neighbour discovery
> _______________________________________________
> general mailing list
> To unsubscribe, please visit
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-10-07 18:21    [W:0.108 / U:1.004 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site