netdev - Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

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]

Date:   Thu, 16 Mar 2017 20:36:03 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     tom@...bertland.com
Cc:     stephen@...workplumber.org, nikolay@...ulusnetworks.com,
        netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        dsa@...ulusnetworks.com, jkbs@...hat.com, edumazet@...gle.com,
        pch@...bogen.com
Subject: Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash
 policy choice

From: Tom Herbert <tom@...bertland.com>
Date: Tue, 14 Mar 2017 19:30:47 -0700

> Agreed, but then why do we even need any complexity here by that
> argument? RSS is specifically defined to do 5-tuple hashing for TCP
> (and UDP), and 3-tuple. No one has ever complained that doing per flow
> RSS for TCP is bad thing AFAIK. We followed that same model for RPS,
> RFS, and XPS via state in the connection context. The skb_hash is
> often given to us for free, whereas in order to do a 3-tuple we have
> to actually do more work and do at least an extra jhash. I suppose the
> argument is probably that switches allow this configuration and
> somehow we want to have feature parity, but it would be very
> interesting to know if anyone is not doing per flow ECMP in real life
> and why...

Anyone doing any kind of hardware offload work requires the
possibility of getting feature parity on the software side.  It's the
only way to properly test and debug things.