Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness

[Zoltan Kiss <zoltan.kiss@xxxxxxxxxx>]

On 12/03/14 11:38, Paul Durrant wrote:
> > -----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.
I think it's not: it consumes a request for the metadata, and when the 
packet is grant copied to the guest, it creates a response for that slot 
as well.

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