Suricata

I filed a bug with the kernel bugzilla. I don't have solid reproducible input at the moment, but I don't see any reason why the new hashing to include vlan and flow-labels can't be symmetric as well.

https://bugzilla.kernel.org/show_bug.cgi?id=120441

If I'm not mistaken, we can rely on the NIC to do the balancing:

$ ethtool -n ens2f0 rx-flow-hash tcp4
TCP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]

$ ethtool -n ens2f0 rx-flow-hash tcp6
TCP over IPV6 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]

$ ethtool -n ens2f0 rx-flow-hash udp4
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]

$ ethtool -n ens2f0 rx-flow-hash udp6
UDP over IPV6 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]

Then instead of 'cluster_flow' in the yaml set 'cluster_qm'.

It seems my thinking about RSS is wrong. As far I understand now, the RSS hashing is not symmetric either. It makes sense if you consider that the promisc capture case is a bit of an anomaly: normally the RX of a NIC would not see both sides of a flow. See also http://www.ntop.org/pf_ring/going-beyond-rss-receive-side-scaling/

For xl710, section 7.1.9.3 of xl710-10-40-controller-datasheet.pdf announced it is possible to get a symetrical hash. From conversation I had at netdev 1.1 with Intel people it was possible to have it.

David Miller has provided a fix that we're currently testing. It should go into stable kernels as well once it's ready, as the change seems not intrusive. That should fix the issue.

However, it seems that generally using multiple RSS queues is harmful. Most NIC's will not do symmetric hashing on the NIC leading to both sides of the conversation possibly being sent to different queues. Timing issue can lead to packet ordering problems. The solution here is to set the number of queues to 1 or force the NIC to use symmetric hashing if possible.

Patch provided by David Miller: http://marc.info/?l=linux-netdev&m=146740374418529&w=2

Patch is in net-next tree http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=eb70db8756717b90c01ccc765fdefc4dd969fc74

Kernel 4.7rc7 contains the fix http://lwn.net/Articles/694055/

Patch has been queued for 4.4 and 4.6 stable kernel.

Kernels 4.4 and 4.6 are now patched -
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.16
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.6.5

It should be in Ubuntu 16.04's kernel soon https://launchpad.net/ubuntu/+source/linux/4.4.0-34.53

Ubuntu 16.04 now has this fixed kernel: https://launchpad.net/ubuntu/+source/linux/4.4.0-36.55