Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Paul Durrant
> Sent: 12 March 2014 11:26
> To: Ian Campbell; Zoltan Kiss
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu; Tim (Xen.org)
> Subject: RE: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness
> 
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> > bounces@xxxxxxxxxxxxx] On Behalf Of Ian Campbell
> > Sent: 12 March 2014 10:28
> > To: Zoltan Kiss
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu; Tim (Xen.org)
> > Subject: Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness
> >
> > 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.
> >
> 
> Huh? The act of consuming the request will create the space for the
> response. If responses and requests are not balanced then I'd argue that the
> protocol is broken.
> 

Actually ancient memory tells me that, unfortunately, netback's 
backend->frontend GSO protocol is broken in this way... it requires one more 
response slot than the number of requests it consumes (for the extra metadata), 
which means that if the frontend keeps the ring full you can get overflow. It's 
a bit of a tangent though, because that code doesn't use this macro (or in fact 
check the ring has space in any way IIRC). The prefix variant of the protocol 
is ok though.

  Paul

>   Paul
> 
> > (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?
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel

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