Symmetrical RSS hashing using Toeplitz hash.

2016-09-18 21:00:30 +0100

Modern OSes and NICs use hashing based on src/dst port and protocol tuples to identify "flows" so that they can be put on different CPU or NIC queue. Doing so improves cache locality and this performance and is what Microsoft (and others), are calling RSS a.k.a receive side scaling/steering.

While playing with some Rust code to parse Suricata EVE Json log events I was thinking about calculating and keeping per flow list of events (**looks like Suricata flow id fields are not very unique, however this is changing). Then I found this nice article explaining the RSS Toeplitz hash function and a modification from the default that is being used now to allow for symmetric hashing: Symmetric RSS Symmetrical hashing means that ideally both directions of the traffic of certain flow would end up on the same NIC queue and thus the same CPU, so we can get better performance due to the better cache locality and potentially less locking required.

Here is also some DragonFlyBSD and FreeBSD code implementing Toeplitz:

• http://bxr.su/DragonFly/sys/net/toeplitz.c
• https://github.com/freebsd/freebsd/blob/master/sys/net/toeplitz.c

P.S.: I wonder why I see DragonFly code implement some sort of caching, while FreeBSD code does not.