[openib-general] ib_req_ncomp_notif in core_ layer

[Sean Hefty]

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.
 
> 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.