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. > > >> >>> Would it be better to poll for 1 in every >>> poll call Or >>> otherwise have this >>> while ( rc <= ARRAY_SIZE(wcs) && rc); >>> > -- 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
