> From: Roland Dreier [mailto:[EMAIL PROTECTED] > Sent: Monday, September 25, 2006 2:55 PM > To: Rimmer, Todd > Cc: Michael S. Tsirkin; [email protected] > 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
