[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 12/03/14 10:28, Ian Campbell wrote:
On Tue, 2014-03-11 at 23:24 +0000, Zoltan Kiss wrote:
On 11/03/14 15:44, Ian Campbell wrote:

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 don't think that would make sense. I think everywhere where this macro
is called the caller is not interested in pending request (pending means
consumed but not responded)

It might be interested in such pending requests in some of the
pathological cases I allude to in the next paragraph though?

For example if the ring has unconsumed requests but there are no slots
free for a response, it would be better to treat it as no unconsumed
requests until space opens up for a response, otherwise something else
just has to abort the processing of the request when it notices the lack
of space.

(I'm totally speculating here BTW, I don't have any concrete idea why
things are done this way...)

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?

Also, let me quote again my example about when rsp makes sense:

"To clarify what does this do, let me show an example:
req_prod = 253
req_cons = 256
rsp_prod_pvt = 0

req will be UINT_MAX-2, as the values changed in the meantime, and rsp is 0. It's reasonable to return 0 here, as the backend hasn't replied anything yet, so we clearly shouldn't have any unconsumed request in the ring."


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.