[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <708813d655494f2785fda3bb4f83e1d9@AMSPEX02CL03.citrite.net>
Date: Fri, 12 Feb 2016 16:59:01 +0000
From: Paul Durrant <Paul.Durrant@...rix.com>
To: David Miller <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>
Subject: RE: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing
> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: 12 February 2016 16:42
> To: Paul Durrant
> Cc: netdev@...r.kernel.org; xen-devel@...ts.xenproject.org
> Subject: Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing
>
> From: Paul Durrant <Paul.Durrant@...rix.com>
> Date: Fri, 12 Feb 2016 11:07:50 +0000
>
> > Windows *requires* use of Teoplitz so your position completely rules
> > out being able to support receive side scaling in Windows PV
> > frontends on Linux kernel backends, not only for Xen but for any
> > other hypervisor, which I think is totally unreasonable.
>
> We have strong reason to believe that Toeplitz has properties that
> make it very weak if not exploitable, therefore doing software RSS
> with Jenkins is superior.
I don't disagree, but there is really no choice of algorithm where a Windows frontend is concerned. My patches only add Toeplitz hashing into xen-netback according to the specification in xen's netif.h; the algorithm is not exposed for use by any other part of the kernel.
If it would help I can add a module parameter to xen-netback to control advertising the option of the hash to frontends so that it can be globally disabled if it is deployed on host where there are no Windows guests.
Paul
Powered by blists - more mailing lists