Re: [Xen-devel] [PATCH] netif.h: Document xen-net{back, front} multi-queue feature

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 20 February 2014 11:04
> To: Andrew Bennieston
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu; Paul Durrant; David Vrabel
> Subject: Re: [PATCH] netif.h: Document xen-net{back,front} multi-queue
> feature
> 
> On Thu, 2014-02-20 at 10:58 +0000, Andrew Bennieston wrote:
> > As such, I think the docs should, for now, say something along the lines of:
> >    Mapping of packets to queues is considered to be a function of the
> >    transmitting system (backend or frontend) and is not negotiated
> >    between the two. Guests are free to transmit packets on any queue
> >    they choose, provided it has been set up correctly.
> 
> That's the sort of thing I was looking for, thanks.
> 
> (fixing Paul's CC at last...)
> 

That all sounds fine. There will be some changes when we attempt to implement 
Toeplitz and Windows RSS (Receive Side Scaling)...

Briefly, the Windows stack provides a hash key at start of day which needs to 
be fed to the backend (which I guess we'll do via xenstore) so that it can use 
it in its calculation. The stack also provides a hash->queue mapping table 
which is updated on a fairly infrequent basis (so we can probably still use 
xenstore for that) to dictate which TCP flows coming from the backend should 
appear on which queue (and hence get processed by which frontend vCPU). The 
other complication is that the actual hash value needs to be passed to the 
stack with each TCP packet, so I suspect we'll have to use a new 'extra 
segment' type to pass that across.

All of this, as the same suggests, is (guest) receive side. There is no 
connection with transmit side, although I believe Windows will ensure that the 
transmissions of any particular TCP flow will occur on the same CPU that the 
hash->queue mapping mandates for reception (modulo a bit of mismatch whenever 
the table is updated).

  Paul

> Ian.
> 

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