Re: Proposal for adding ib_usa to the Linux Infiniband Subsystem

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 
> Sent: Friday, May 21, 2010 11:30 AM
> To: Mike Heinz; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html