Re: [Xen-devel] [PATCH net] xen-netback: bookkeep number of queues in our own module

On 23/06/14 10:20, Paul Durrant wrote:

quoted

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: 23 June 2014 10:09
To: Paul Durrant
Cc: Wei Liu; xen-devel@lists.xen.org; netdev@vger.kernel.org;
boris.ostrovsky@oracle.com; Ian Campbell
Subject: Re: [PATCH net] xen-netback: bookkeep number of queues in our
own module

From: Paul Durrant <redacted>
Date: Mon, 23 Jun 2014 07:59:16 +0000

quoted

Bear in mind that the original intention of the multi-queue patches
was to allow the queue selection algorithm to be negotiated with the
frontend (see
http://lists.xen.org/archives/html/xen-devel/2013-06/msg02654.html).

Particularly,

quoted

if the frontend is Windows then netback will need to use a Toeplitz
hash to steer traffic since this is stipulated by Microsoft's RSS
(Receive Side Scaling) interfaces. So, IMO netback should always
implement a select queue method, otherwise any (theoretical)
algorithm change in __netdev_pick_tx() would be immediately imposed
on frontends, possibly causing them to misbehave.

I do not think you are obligated to use Toeplitz or whatever scheme
the other side wants, especially if the user on the xen-netback side
asked for XPS or similar to be used.

If the frontend can only cope with one steering algorithm then how's
that going to work? Flows would come in on the 'wrong' queue as far as
the frontend is concerned and then who knows what would happen? If the
frontend says it can only handle 'algorithm X' then the backend should
either guarantee it's going to use 'algorthm X' or it should use a
single queue.

We specify that frontends have to handle packets from any flow arriving
on any queue and and given the absence of any hashing negotiation we
should just use the default queue selection.

David