nfqueue hashing on TCP/UDP port

[Jake Owen <jake.owen@superloop.com>]

Hello!

tl;dr Is there a technical reason why nfqueue balance as implemented
does not use TCP/UDP ports as well as source/destination IP addresses?

We've been having trouble with the queue hashing algorithm used by
iptable's `--queue-balance` for traffic generated on-box (e.g. by a
squid proxy) where a large percentage of traffic would be TCP, source
IP of the proxy, and one google/microsoft/apple destination IP. This
is made worse if the random seed causes two or more of these high
traffic services to hash to the same queue. We are working on
preserving the original client IP as the source IP to provide
sufficient randomness to balance accurately, but in the meantime have
wondered if balancing by port was not implemented because it was
deemed unnecessary, or because of some technical reason which escapes
me.

I've been able to write a kernel patch which hashes based on protocol,
IP and port for the CentOS 7 kernel we have in production which
_appears_ to be stable. Is there an existing test harness I can use to
validate this implementation? I'm willing to propose a solution for
the latest 5.x kernel if other people think that this is a valid
solution/use case.

Kind Regards,
Jake Owen