[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness
On Thu, 2014-03-06 at 15:47 +0000, Zoltan Kiss wrote: > Hi, > > I was wondering for a while why this macro looks like this: > > #define RING_HAS_UNCONSUMED_REQUESTS(_r) \ > ({ > \ > unsigned int req = (_r)->sring->req_prod - (_r)->req_cons; \ > unsigned int rsp = RING_SIZE(_r) - \ > ((_r)->req_cons - (_r)->rsp_prod_pvt); \ > req < rsp ? req : rsp; \ > }) > > I would expect to check prod - cons, like RING_HAS_UNCONSUMED_RESPONSES does: > > #define RING_HAS_UNCONSUMED_RESPONSES(_r) \ > ((_r)->sring->rsp_prod - (_r)->rsp_cons) > > By my understanding, there is no way rsp could be smaller than req, so > there is no point having this. Am I missing something? Just looking at this again. All that stuff I said about wraparound was misleading/irrelevant since req and rsp are not the pointers, but actually the number of things. Sorry. Is it the case that this macro considers a request to be unconsumed if the *response* to a request is outstanding as well as if the request itself is still on the ring? I wonder if this apparently weird construction is due to pathological cases when one or the other end is not picking up requests/responses? i.e. trying to avoid deadlocking the ring or generating an interrupt storm when the ring it is full of one or the other or something along those lines? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |