[openib-general] DAPL for openib

Michael S. Tsirkin mst at mellanox.co.il
Wed Aug 25 13:37:20 PDT 2004


Hello!
Quoting r. Michael S. Tsirkin (mst at mellanox.co.il) "Re: [openib-general] DAPL for openib":
> Hello!
> Quoting r. Michael S. Tsirkin (mst at mellanox.co.il) "Re: [openib-general] DAPL for openib":
> > Quoting r. Roland Dreier (roland at topspin.com) "Re: [openib-general] DAPL for openib":
> > >     Michael> I'm not sure I understand the semantics - if SMA simply
> > >     Michael> registers without supplying version, class or method,
> > >     Michael> will it get to see all MADs?
> > > 
> > > In the OpenIB MAD API each MAD can be dispatched to only one
> > > consumer.  So if the SMA sees all MADs by registering this way, no
> > > other consumer would be able to receive MADs.
> > > 
> > 
> > Pity.
> > Is this dictated by difficulty of implementation?
> > 
> > Maybe have something like linux probe function - 
> > in linux device driver model after device matches 
> > class vendor and device id parameters specified by the
> > driver, and probe function  is called to make it possible
> > for driver to decide if it wants to handle this device based on other
> > fields.
> > 
> > In the same vein, for each MAD API cold probe matching consumers
> > and let them examine the MAD until one says "its mine".
> > 
> > So SMA could just refuse all MADs.
> > 
> > MST
> >
> 
> To clarify, 
> 
>    typedef void (*ib_mad_recv_handler)(struct ib_mad_agent *mad_agent,
>                   struct ib_mad_recv_wc *mad_recv_wc);
> 
> could be
> 
> 
>    typedef int (*ib_mad_recv_handler)(struct ib_mad_agent *mad_agent,
>                   struct ib_mad_recv_wc *mad_recv_wc);
> 
> MST
>

That would have to be for unsolicited MADs only, of course.
Hmm ... I see where this gets messy.

MST



More information about the general mailing list