[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