[openib-general] VAPI like API

[Rimmer, Todd]

> -----Original Message-----
> From: Roland Dreier [mailto:roland at topspin.com]
> Sent: Thursday, July 29, 2004 10:50 AM
> To: openib-general at openib.org
> Subject: Re: [openib-general] VAPI like API
> 
> 
>     Sean> If not ib_device, I'm guessing that there will be some
>     Sean> structure per client in the access layer...?  I do agree
>     Sean> that having separate send and receive handlers would be
>     Sean> better than a single completion handler.  So, at a minimum,
>     Sean> I'd vote for _at least_ two completion handlers per client.
> 
> There's no fundamental reason for the AL to have a per consumer
> structure right now, although we still need how to work out how to tie
> into the kernel device model.  By the way, I don't think the IB spec's
> concept of enumerating HCAs and then having the consumer open the HCAs
> it like works well in the kernel.  That's sort of like the old PCI
> driver model, and it doesn't work well in a dynamic world where
> devices can come and go.  We should rather think in terms of consumers
> registering with the AL and getting called back when devices appear or
> disappear (and I'm hoping the driver model can do this for us without
> having to create our own mechanism).
> 
> BTW, if we're going to have two completion handlers, it seems we might
> as well have the handler be per CQ (since it seems worse to me to have
> an index/pointer stored in struct ib_cq that's just used to look up
> the actual function pointer to call).

Yes in our implementation, the HCA drivers call into the access layer on
PCI device discovery.

ULPs can register with the access layer for callbacks when CA's appear
(and or the state of a link changes).

This does not mean that open is a bad call, the response to these notifications
was for the access layer or ULP to open the CA and begin performing
operations against it.

Todd R.