Re: [Xen-devel] RING_HAS_UNCONSUMED_REQUESTS oddness

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-03-13 at 12:28 +0000, Zoltan Kiss wrote:
> 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.

Oops, I was thinking of guest tx not rx, sorry. Tx can complete in any
order (txrsp->id is the index into tx_skbs[]) but not rx apparently.

Ian.


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