[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Feb 2016 18:13:40 +0200
From: Or Gerlitz <gerlitz.or@...il.com>
To: Tom Herbert <tom@...bertland.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Linux Netdev List <netdev@...r.kernel.org>,
Alexander Duyck <alexander.duyck@...il.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Daniel Borkmann <borkmann@...earbox.net>,
Marek Majkowski <marek@...udflare.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Florian Westphal <fw@...len.de>,
Paolo Abeni <pabeni@...hat.com>,
John Fastabend <john.r.fastabend@...el.com>,
Amir Vadai <amirva@...il.com>
Subject: Re: Optimizing instruction-cache, more packets at each stage
On Thu, Jan 21, 2016 at 1:27 AM, Tom Herbert <tom@...bertland.com> wrote:
> Unfortunately, the hardware hash from devices hasn't really lived up
> to its potential. The original intent of getting the hash from device
> was to be able to do packet steering (RPS and RFS) without touching
> the header. But this never was implemented. eth_type_trans touches
> headers and GRO is best when done before steering. Given the
> weaknesses of Toeplitz we talked about recently and that fact that
> Jenkins is really fast to compute, I am starting to think maybe we
> should always do a software hash and not rely on HW for it...
Could you provide some details on the weaknesses of Toeplitz?
FYI, the admin is able to configure non-default keys for Toeplitz
through ethtool.
Or.
Powered by blists - more mailing lists