I have to agree that in some ways this seems a good fit with ibverbs. Also, without the multicast support, the whole thing is well under 1 kloc in the kernel, making it a good candidate for being combined with another module.
My biggest objections, though, would be: 1. If it's been working for a couple of years now, do we really need to change it? 2. The async events in ibverbs are all local events, are we really keeping things simple by adding remote notifications to mix, or making a simple interface much more complicated? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jason Gunthorpe Sent: Friday, May 21, 2010 12:50 PM To: Mike Heinz Cc: Sean Hefty; [email protected] Subject: Re: Proposal for adding ib_usa to the Linux Infiniband Subsystem 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:[email protected]] > Sent: Friday, May 21, 2010 11:30 AM > To: Mike Heinz; [email protected] > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
