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

[Rimmer, Todd]

> From: Roland Dreier [mailto:rdreier at cisco.com]
> Sent: Monday, September 25, 2006 2:55 PM
> To: Rimmer, Todd
> Cc: Michael S. Tsirkin; openib-general at openib.org
> Subject: Re: [openib-general] [PATCH] IB/ipoib: NAPI
> 
>  > 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).
> 
> That's exactly where we need peek CQ.  We can't repoll the CQ, because
> netif_rx_complete() has already been called, so the poll routine might
> already be running on another CPU.  The only thing I can see to do is
> peek in the CQ, and if it's not empty, then go through the whole
> netif_rx_reschedule() song and dance.
> 
>  - R.

I agree.  This would also mean the ipoib_warn in ipoib_ib_completion
would go away (would be a valid situation).

I'm going to keep thinking about this, seems like we can't call
req_notify until after netif_rx_complete, otherwise we have a different
race.  That leads to the req_notify and peek approach.

It's a shame, because for all other ULPs, the poll_and_notify approach
works well.

I too would prefer not to see dual algorithms and a device flag as it
could quickly lead to a lot of redundant code.

Todd Rimmer