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

[Michael S. Tsirkin]

Quoting r. Roland Dreier <rdreier at cisco.com>:
> Subject: Re: [PATCH] IB/ipoib: NAPI
> 
>  > I just find a flag + conditional peek a much simpler approach.
>  > Since all our testing is done on mthca anyway, almost
>  > all approaches amount to doing a NOP in various ways for us.
> 
> Umm, that's a pretty parochial attitude...

But what do you suggest? I don't have all IB hardware.
All I was saying was that on mthca

ib_req_notify(&lost)
if (lost) {
	reschedule
}

and

ib_req_notify
if (dev->flags & NEED) && peek_cq() {
	reschedule
}

never calls reschedule, so they are equivalent from that POV.

>  > So I would suggest
>  > - get Eli's patch with simple flag into shape & working on all hardware,
>  >   push into git.
>  > - people interested in specific hardware test performance and propose patches
>  >   to improve it even further.
> 
> What is a 'simple flag'?

Something like IB_DEVICE_IMMEDIATE_COMPETION_EVENT, set in mthca.

ib_req_notify
if (!(dev->flags & IB_DEVICE_IMMEDIATE_COMPETION_EVENT) && peek_cq() {
	reschedule
}

> Who is going to implement peek_cq() for ehca
> and ipath?

I can do that - it's easy. But it's still true I only really test mthca.

> I'm not really that interested in the most micro-optimized approach.

I'm still not convinced an extra peek cq is *that* expensive.
Maybe we can just always peek without any clever tricks?

> I'd rather have something simple and easy to maintain -- in other
> words, I don't want 2 or 3 completion handling paths in IPoIB.  And
> from that perspective, extending req_notify_cq() looks pretty good to
> me.

Hmm, OK I guess.
So, can you post the patch updating req_notify_cq?
Eli can then respin the IPoIB patch to use that.

-- 
MST