netdev - Re: [PATCH net-next] flow_dissector: remove __flow_hash

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: <1438208128.20182.113.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Thu, 30 Jul 2015 00:15:28 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net-next] flow_dissector: remove
 __flow_hash_consistentify

On Wed, 2015-07-29 at 14:47 -0700, Tom Herbert wrote:

> Hi Eric,
> 
> So the scenario you're thinking is conntrack in the forwarding path,
> RPS enabled (RSS not relevant), no hash from device, no IPv6 flow
> labels or any other asymmetric inputs into the flow hash? I can look
> at that, but it does make me wonder if maybe conntrack should set RFS
> for both sides to avoid any issue with asymmetric hashes. With more
> IPv6 and flow labels (which we will enable by default), asymmetric
> hashes will likely become the norm.

Yes, but as long as the hash was done in software in our stack we could
use flow dissection and this swap() thing, regardless of the hashes
computed by the NIC or derived from IPv6 flow label.

RFS wont fly here, as DDOS traffic will need more cache misses.


--
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