do we know if Windows plans to support more RSS hash functions for miniport drivers?
I’m not aware of current plans to add other hash functions. But I’m interested in any alternatives you might propose.
Keep in mind – even if we hypothetically added support for a new hash function to the next release of Windows Server, you’d still have customers running Windows Server 2019 for, approximately, 15 years. So those customers will all still want to know why RSS behaves oddly with your device.
Even if other algorithm is used to perform RSS, will windows complain about it
You could build a NIC that goes and does the “wrong” hash function on every packet. You’d still get spreading, and thus be able to scale out to more CPU cores to handle the load. That would possibly still be a performance improvement over no RSS at all, depending on workload and system configuration, etc.
What goes wrong is that, internally, the TCP stack is going to use the Toeplitz hash (with the hash key and indirection table that we share with the NIC) to bucket its internal datastructures. So if the NIC and the TCP stack don’t agree on which CPU should process each socket’s traffic, then a lot of packets will have to do costly cross-processor lookups to grab the socket datastructure from the wrong processor.
Honestly, I don’t know how bad that really is. Perhaps it’s only a 10% performance penalty, which would be more than offset by the ability to spread across 4 processors instead of just 1 processor. Measure it and see. (If you don’t have silicon, you can simulate the effect of using the wrong hash algorithm by doing Toepliz and using the wrong hash key. If you have a kernel debugger, you can even do that to an off-the-shelf NIC by intercepting and changing the OID on its way down.)
Windows itself won’t complain, per se, since Windows always expects some packets to arrive on the wrong CPU, in various edge cases. E.g., there’s always a race between an indirection table update OID going down, and the traffic coming up. There’s going to be some packets that get processed by some RSS-unaware filter driver that breaks the RSS hash or spreading. So Windows will always cope with “wrong” RSS/hashing – it’s just a question of how much performance you lose.
The HLK reserves the right to complain about incorrectly-performed RSS, though. We reserve the right to prevent your driver from getting certified for Windows Server, or for becoming an inbox driver if you can’t pass a (hypothetical) HLK test that validates your driver performs RSS to specification.