Sponsored by: Solarflare Communications, Inc.
Details
Details
- Reviewers
gnn - Commits
- rS280783: sfxge: set correct RSS hash type instead of opaque
Driver module build tested.
Hashtype is checked using debug printouts and simple traffic using netcat.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
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.
Comment Actions
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?
Comment Actions
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.