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

[Rimmer, Todd]

> From: Roland Dreier [mailto:rdreier at cisco.com]
> Sent: Monday, September 25, 2006 12:41 PM
> To: Rimmer, Todd
> Cc: Michael S. Tsirkin; openib-general at openib.org
> Subject: Re: [openib-general] [PATCH] IB/ipoib: NAPI
> 
>     Todd> Its inefficient to peek the CQ if the next operation is
>     Todd> likely to then be a poll.  Performing the poll_and_notify in
>     Todd> one call is more efficient.
> 
> Yes, but if you think carefully about how to implement NAPI for IPoIB,
> you'll see that poll-and-notify is not a useful operation.  If a
> device does not support the "exact" Mellanox CQ notify semantics, then
> there is no way around using peek CQ somehow.
> 
>  - R.
Roland,

What were your thoughts on how to handle this part of Eli's proposed
code:
	ib_req_notify_cq(cq, IB_CQ_NEXT_COMP);
	/* TODO we need peek_cq here for hw devices that
	   could would not generate interrupts for completions
	   arriving between end of polling till request notify */

	return 0;

On a non-Mellanox HCA, if the CQ is not empty here, isn't this required
to poll it til empty and process all the CQEs (otherwise we may not get
another interrupt).  If instead we return 1 from the dev->poll routine
here, we could be scheduled for a future poll and a future interrupt
(which might be bad).

Todd