[openib-general] [PATCH] IB/ipoib: NAPI

[Michael S. Tsirkin]

Quoting r. Roland Dreier <rdreier at cisco.com>:
> Subject: Re: [PATCH] IB/ipoib: NAPI
> 
>     Michael> Actually, the reason it is hard to come up with the name
>     Michael> is that what this enables is the natural poll/request
>     Michael> notification order.
> 
> Over the weekend and I thought about this and I came up with an idea I
> kind of like, inspired by Todd Rimmer's comments about poll-and-notify.
> 
> We could change ib_req_notify_cq() to have an extra parameter:
> 
> static inline int ib_req_notify_cq(struct ib_cq *cq,
> 				   enum ib_cq_notify cq_notify,
> 				   int *lost_event_possible)
> 
> and if non-NULL is passed in for lost_event_possible, then
> req_notify_cq should do the equivalent of a CQ peek after arming the
> CQ event.

I thought about this too.

But this has a disadvantage over the device-wide flag: when flag is device-wide,
we can just have 2 polling routines - with and without peek - and select the
correct one at device open depending on the hardware capabilities.
Thus we can avoid a conditional branch on the fast path,
which I think is nice.

So I think if we want to enable mthca-specific optimization,
the righ tway is with device flags.

On a separate note - ib_req_notify_cq is also testing the lost_event_possible flag -
so now we have 2 conditional branches on fast path, and this hurts all ULPs. Ugh.

If we extend the interface, I would rather make  a new call
	ib_req_notify_and_peek_cq(truct ib_cq *cq, enum ib_cq_notify cq_notify)
that returns 0 on empty CQ, 1 on non-empty and negative on error.

-- 
MST