On Mon, Sep 21, 2015 at 9:15 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > >> On Sep 21, 2015, at 1:51 AM, Devesh Sharma <devesh.sharma@xxxxxxxxxxxxx> wrote: >> >> On Sun, Sep 20, 2015 at 4:05 PM, Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> wrote: >>>>> It is possible that in a given poll_cq >>>>> call you end up getting on 1 completion, the other completion is >>>>> delayed due to some reason. >>>> >>>> >>>> If a CQE is allowed to be delayed, how does polling >>>> again guarantee that the consumer can retrieve it? >>>> >>>> What happens if a signal occurs, there is only one CQE, >>>> but it is delayed? ib_poll_cq would return 0 in that >>>> case, and the consumer would never call again, thinking >>>> the CQ is empty. There's no way the consumer can know >>>> for sure when a CQ is drained. >>>> >>>> If the delayed CQE happens only when there is more >>>> than one CQE, how can polling multiple WCs ever work >>>> reliably? >>>> >>>> Maybe I don't understand what is meant by delayed. >>>> >>> >>> If I'm not mistaken, Devesh meant that if between ib_poll_cq (where you >>> polled the last 2 wcs) until the while statement another CQE was >>> generated then you lost a bit of efficiency. Correct? >> >> Yes, That's the point. > > I’m optimizing for the common case where 1 CQE is ready > to be polled. How much of an efficiency loss are you > talking about, how often would this loss occur, and is > this a problem for all providers / devices? The scenario would happen or not is difficult to predict, but its quite possible with any vendor based on load on PCI bus I guess. This may affect the latency figures though. > > Is this an issue for the current arrangement where 8 WCs > are polled at a time? Yes, its there even today. > > > — > Chuck Lever > > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
