I've said this before, but again.. There are too many orthogonal interfaces here. We really don't need more libraries or kernel modules or /dev/ devices. Really.
Subscribing and multiplexing notifications from a GSI service should just be a general function in the mad code.. On Fri, May 21, 2010 at 10:57:48AM -0500, Mike Heinz wrote: > Would it be better to omit the multicast support from ib_usa and simply add > it as a way to handle notifications? > > From: Sean Hefty [mailto:sean.he...@intel.com] > Sent: Friday, May 21, 2010 11:30 AM > To: Mike Heinz; linux-rdma@vger.kernel.org > Subject: RE: Proposal for adding ib_usa to the Linux Infiniband Subsystem > > >Why is this needed? > >The SA protocol allows notices and multicast membership to be managed at a CA > >port level.? As a result, if multiple processes want to receive notices or > >join > >multicast groups, that registration must be coordinated per CA port.? > >Existing > >code in the Linux kernel exists for this purpose, coordinating the needs of > >various Infiniband kernel modules and presenting a single "per server CA > >port" > >perspective to the SA.? The IB user space SA module provides a mechanism for > >user space applications to take advantage of this existing kernel code for > >managing SA registrations. > > The AF_IB support that is being requested for the rdma_cm would provide > greater > support for IB multicast join/leave membership. Some additional work would be > needed to allow the user to specify the full MCMemberRecord, but the basic > infrastructure should be there. Just mentioning this as a possibility. (The > IB > ACM code joins multicast groups using libibumad and sends MADs directly to the > SA.) > > - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
