netdev - RE: [PATCH net] xen-netback: bookkeep number of queues in our own module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD03BC30C@AMSPEX01CL01.citrite.net>
Date:	Mon, 23 Jun 2014 09:20:47 +0000
From:	Paul Durrant <Paul.Durrant@...rix.com>
To:	David Miller <davem@...emloft.net>
CC:	Wei Liu <wei.liu2@...rix.com>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
	Ian Campbell <Ian.Campbell@...rix.com>
Subject: RE: [PATCH net] xen-netback: bookkeep number of queues in our own
 module

> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: 23 June 2014 10:09
> To: Paul Durrant
> Cc: Wei Liu; xen-devel@...ts.xen.org; netdev@...r.kernel.org;
> boris.ostrovsky@...cle.com; Ian Campbell
> Subject: Re: [PATCH net] xen-netback: bookkeep number of queues in our
> own module
> 
> From: Paul Durrant <Paul.Durrant@...rix.com>
> Date: Mon, 23 Jun 2014 07:59:16 +0000
> 
> > 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,
> > 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.

  Paul
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html