Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Zoltan Kiss
> Sent: 13 March 2014 12:29
> To: Ian Campbell; Paul Durrant
> Cc: Wei Liu; xen-devel@xxxxxxxxxxxxxxxxxxxx; Tim (Xen.org)
> Subject: Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness
> 
> On 13/03/14 12:19, Ian Campbell wrote:
> > On Thu, 2014-03-13 at 10:58 +0000, Paul Durrant wrote:
> >>> -----Original Message-----
> >>> From: Ian Campbell
> >>> Sent: 13 March 2014 10:03
> >>> To: Paul Durrant
> >>> Cc: Zoltan Kiss; Wei Liu; xen-devel@xxxxxxxxxxxxxxxxxxxx; Tim (Xen.org)
> >>> Subject: Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS
> oddness
> >>>
> >>> On Thu, 2014-03-13 at 09:26 +0000, Paul Durrant wrote:
> >>>> guarantee that netback will always respond in order on the rx ring.
> >>>
> >>> I don't believe this is guaranteed byt the protocol, even if it happens
> >>> to work out that way for the Linux netback implementation.
> >>>
> >>
> >> Indeed it's not guaranteed by the protocol but it's the only way that
> >> (non-prefix) GSO can possibly work, which is why I think something
> >> really needs to be documented.
> >
> > There are possibly ordering constraints on the completion of the gso
> > info slot and the rest but I don't think there are any such restrictions
> > on the fragment slots themselves, are there?
> 
> Well, the Linux frontend doesn't take the id from the response, it just
> assume that the response is in the same slot as the request.

... so for compatibilities sake, the ring had better complete in order!

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