[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 1/5] public/io/netif.h: document the reality of netif_rx_request/reponse id



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 19 October 2015 17:01
> To: Paul Durrant
> Cc: Ian Campbell; Ian Jackson; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir
> (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v4 1/5] public/io/netif.h: document the reality of
> netif_rx_request/reponse id
> 
> >>> On 19.10.15 at 15:53, <paul.durrant@xxxxxxxxxx> wrote:
> > The id field of the netif_rx_request_t abd netif_rx_response_t structures
> > is actually useless.
> >
> > Because GSO metadata is passed from backend to frontend using
> > netif_extra_info segments, which do not carry information stating which
> > netif_rx_request_t was consumed to free up their slot, frontends assume
> > that the consumed request is the one that previously occupied that same
> > slot in the shared ring. Also, whilst theoretically possible for other
> > responses to be re-ordered, they never have been and that assumption
> has
> > always been baked into Linux xen-netfront.
> 
> Is all this true even for frontends not supporting GSO and other
> "extra" stuff?
> 

Maybe, but backends need to be compatible with Linux netfront and regardless of 
whether it has enabled GSO on the receive side, it makes no use of response id. 
However, looking again, maybe the restriction can be relaxed a little.

When netfront posts an rx request it sets the request id to ring slot modulo 
ring size but, when processing responses, it simply looks up the context it 
saved (e.g. grant ref) based on request id by assuming the identity relation 
between slot number and id.
So, because it does not verify the identity relation, it is sufficient to 
simply make sure that responses appear in the same ring slot as their 
corresponding request.
So, I think it is sufficient to say response id must match request id (for 
those frontends, like the Windows  one, that do use it) and responses must 
appear in the same slot as requests (to keep compatibility with Linux 
netfront). I'll adjust the patch accordingly.

  Paul

> Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.