Merge branch 'flow_key_hashing'
Tom Herbert says:
====================
net: Increase inputs to flow_keys hashing
This patch set adds new fields to the flow_keys structure and hashes
over these fields to get a better flow hash. In particular, these
patches now include hashing over the full IPv6 addresses in order
to defend against address spoofing that always results in the
same hash. The new input also includes the Ethertype, L4 protocol,
VLAN, flow label, GRE keyid, and MPLS entropy label.
In order to increase hash inputs, we switch to using jhash2
which operates an an array of u32's. jhash2 operates on multiples of
three words. The data in the hash is constructed for that, and there
are are two variants for IPv4 and Ipv6 addressing. For IPv4 addresses,
jhash is performed over six u32's and for IPv6 it is done over twelve.
flow_keys can store either IPv4 or IPv6 addresses (addr_proto field
is a selector). ipv6_addr_hash is no longer used to convert addresses
for setting in flow table. For legacy uses of flow keys outside of
flow_dissector the flow_get_u32_src and flow_get_u32_dst functions
have been added to get u32 representation representations of addresses
in flow_keys.
For flow lables we also eliminate the short circuit in flow_dissector
for non-zero flow label. The flow label is now considered additional
input to ports.
Testing: Ran netperf TCP_RR for 200 flows using IPv4 and IPv6 comparing
before the patches and with the patches. Did not detect any performance
degradation.
v2:
- Took out MPLS entropy label. Will add this later.
v3:
- Ensure hash start offset is a four byte boundary. Add BUG_BUILD_ON
to check for this.
- Fixes sparse error in GRE to get entropy from keyid.
v4:
- Rebase to Jiri changes to generalize flow dissection
- Support TIPC as its own address
- Bring back MPLS entropy label dissection
- Remove FLOW_DISSECTOR_KEY_IPV6_HASH_ADDRS
v5:
- Minor fixes from feedback
v6:
- Cleanup and sparse issue with flow label
- Change keyid to returned by flow_dissector to be __be32
====================
Signed-off-by: David S. Miller <davem@davemloft.net>