[openib-general] ib_req_ncomp_notif in core_ layer

[Michael S. Tsirkin]

Hello!
Quoting r. Sean Hefty (mshefty at ichips.intel.com) "Re: [openib-general] ib_req_ncomp_notif in core_ layer":
> On Tue, 10 Aug 2004 09:20:44 +0300
> "Michael S. Tsirkin" <mst at mellanox.co.il> wrote:
> 
> > I'd like to point out that any device can always implement
> > req_ncomp_notif by means of req_comp_notif and cq peek
> > or possibly even just alias req_ncomp_notif to req_comp_notif
> > since the user will be always prepared to get a spurious
> > event, right?
> 
> The problem with abstracting this call is that the performance of the abstraction isn't what the client might expect.  So, the abstraction does not behave as described. 

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?

Performance is hardware-dependend, anyway. 
Even if the driver does implement it you dont get any
guarantees that req_ncomp has better performance that req_comp,
especially for small values of n. On some hardware the reverse may be
true.


So, why is it a good idea to have all clients do something like
if (req_ncomp_notif()) req_comp_notif()

Why not make this part of the layer already?

If the client wants to check whether req_ncomp_notif is implemented
and do something else (hard for me to think what) he can always
check the pointer in the driver structure.

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.

MST