Date:	Mon, 15 Feb 2016 08:48:19 +0000
From:	Paul Durrant <Paul.Durrant@...rix.com>
To:	Tom Herbert <tom@...bertland.com>
CC:	David Miller <davem@...emloft.net>,
	"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: Tom Herbert [mailto:tom@...bertland.com]
> Sent: 14 February 2016 22:02
> To: Paul Durrant
> Cc: David Miller; netdev@...r.kernel.org; xen-devel@...ts.xenproject.org
> Subject: Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing
> 
> On Fri, Feb 12, 2016 at 5:59 PM, Paul Durrant <Paul.Durrant@...rix.com>
> wrote:
> >> -----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.
> 
> You are touching struct sk_buff for this. Changing such a core
> networking data structure just to satisfy a requirement of Windows
> seems like a long shot to me...

The patch to sk_buff is nothing to do with Toeplitz hashing. It's merely because I noticed that sk_buff was unable to store complete hash type information at the moment and that seems suboptimal. I've re-worded and resent that patch separately.

> 
> > 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.
> 
> Toeplitz is dog-slow to compute in software. Comparing your
> implementation to Jenkins hash (hash) it's about 12x slower (102 nsecs
> versus 8 nsecs for IPv4 on my system). Doing this for every packet
> seems like a non-starter to me. I suspect the majority use case for
> receive is simple uniform load balancing across the virtual queues in
> which case jhash will be perfectly fine. The case where it probably
> matters is if the Windows OS is trying to configure some non-uniform
> distribution (isolating a single flow for instance). To handle this
> case, you could implement a simple look up flow table to map a
> skb->hash to a Toeplitz hash, so that the Toeplitz hash only needs to
> be calculated one time for a flow (recomputed with some periodic
> timeout). This would be probabilistic though, so if really Windows
> requires the hash to be set correctly 100% of the time it won't work.
> 

I agree that Toeplitz is dog-slow to calculation in s/w. Keeping a cache of the N most recent flows and flushing it if the key changes (which is the only thing that's going to cause the hash to change) sounds like a good optimization. I'll certainly add that.

  Paul

> Tom
> 
> >
> >   Paul

Powered by blists - more mailing lists