> 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? Is this an issue for the current arrangement where 8 WCs are polled at a time? — 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
