[openib-general] ib_req_ncomp_notif in core_ layer

[Michael S. Tsirkin]

Quoting r. Sean Hefty (mshefty at ichips.intel.com) "Re: [openib-general] ib_req_ncomp_notif in core_ layer":
> On Wed, 11 Aug 2004 20:38:49 +0300
> "Michael S. Tsirkin" <mst at mellanox.co.il> wrote:
> 
> > I dont see how its a problem. I think,  a simplest interface
> > that gives a best performance possible shall be presented.
> > Thats the idea of abstraction, right?
> 
> I view the overall goal of the access layer more along the lines of incorporating common code from the ULPs and device driver, than abstraction.

Semantics matter though.

Currently some things are unclear:

If you get an event and do req_comp_notif 
immediately, without polling - do you expect to get an event immediately?
What currently happends as far as I can see, is:
for req_comp_notif you dont, for req_ncomp_notif you do.
For n=1 the behaviour of req_ncomp_notif probably does not
make sence ...

If you dont for req_ncomp_notif, what would you expect?

> > Indeed, why not just have req_ncomp_notif and pass in n?
> > Why is there a special call for n=1? Is it to save a conditional
> > branch? Hardware could just ignore the n parameter if it
> > cant support it.
> 
> I'm fine with trying merging the two calls, especially since ib_req_n_notify_cq can handle the case of solicited completions.  Users who care will know whether they can expect fewer HW generated events by checking the device_cap_flags.
> 
> How would something like this be:
> 
> ib_req_notify_cq( *cq, cq_notify, wc_cnt );
> 
> If cq_notify is set to IB_CQ_NEXT_COMP - an event is generated after wc_cnt completions or after the next solicited completion, whichever comes first.  If cq_notify is set to IB_CQ_SOLICITED, wc_cnt is ignored, and an event is generated after the next solicited completion.


Looks good.
As I see it any hardware has an upper bound on the max legal value
for wc_cnt - if a bugger value is given, is defaults to IB_CQ_NEXT_COMP.
For devices without support for ib_req_n_notify_cq, the upper bound
is simply 0. So device drivers could advertise this bound in
their structure, and the access layer would call the proper 
method according to n.


I'd also like to see another option in addition to IB_CQ_SOLICITED and
IB_CQ_NEXT_COMP  - something like IB_CQ_WQE, where the user labels work
request for completion of which he wants to get event, and the event generated
which such a work request is completed or of there is a solicited or error
completion.
This is often more convenient than counting how much wqes were posted.

Again, hardware not supporting such events can always do IB_CQ_NEXT_COMP.

MST