sfxge: set correct RSS hash type instead of opaque

[arybchik]

Summary

Sponsored by: Solarflare Communications, Inc.

Test Plan

Driver module build tested.
Hashtype is checked using debug printouts and simple traffic using netcat.

[adrian]

Hm, is there no 2-tuple and/or UDP hashing available?

[arybchik]

There is 4-tuple hash in the case of TCP over IPv4/IPv6.
There is 2-tuple hash in the case of UDP (and other protocols except TCP) over IPv4/IPv6.

[adrian]

Ok. This looks fine. I'll worry about RSS-ifying it at a later stage so it integrates like ixgbe and igb does.

Would you mind adding the UDP RSS hash type in a later commit?

What does the hardware do if it receives an IPv4 or IPv6 fragment? Does it do what intel/chelsio do and mark all frames of the fragment with a 2-tuple hash?

[arybchik]

Would you mind adding the UDP RSS hash type in a later commit?

Not sure that I understand. HW does not include UDP ports in RSS hash. RSS hash is provided for UDP and it covers IPs only.
The patch sets hash type to either M_HASHTYPE_RSS_IPV4 or M_HASHTYPE_RSS_IPV6 for UDP.
The hash type is set in two places in the patch, but the second is in home-made LRO for TCP only.

What does the hardware do if it receives an IPv4 or IPv6 fragment? Does it do what intel/chelsio do and mark all frames of the fragment with a 2-tuple hash?

I guess fragments is one of the reasons (or only the reason) why HW provides 2-tuple hash for UDP - to have the same hash for fragmented and not fragmented packets.

[arybchik]

Closed by commit rS280783 (authored by @arybchik).