Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-03-12 at 14:27 +0000, Zoltan Kiss wrote:
> 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

I think to make sense of this I need to see the sequence of reads/writes
from both parties in a sensible ordering which would result in reads
showing the above. i.e. a demonstration of the race not just an
assertion that if the values are read as is things makes sense.

> 
> 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."
> 
> Zoli



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel