On Mon, Jun 23, 2025 at 11:07 AM Jason Wang jasowang@redhat.com wrote:
On Mon, Jun 23, 2025 at 1:40 AM Yuri Benditovich yuri.benditovich@daynix.com wrote:
Yuri, can you help to clarify this?
I see here several questions:
- Whether it is ok for the device not to indicate support for XXX_EX hash type?
- I think, yes (strictly speaking, it was better to test that before
submitting the patches ) 2. Is it possible that the guest will enable some XXX_EX hash type if the device does not indicate that it is supported?
- No (I think this is part of the spec)
There's another question, is the device allowed to fallback to VIRTIO_NET_HASH_TYPE_IPv6 if it fails to parse extensions?
MSFT expectations for that are at https://learn.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashi... If I read them correctly, the answer is "no" BTW, my personal opinion is that placing all these things with hash calculations into kernel instead of ebpf does not make too much sense.
- What to do if we migrate between systems with different
capabilities of hash support/reporting/whatever
- IMO, at this moment such case should be excluded and only mechanism
we have for that is the compatible machine version
- in some future the change of device capabilities can be communicated
to the driver and _probably_ the driver might be able to communicate the change of device capabilities to the OS
Are you suggesting implementing all hash types? Note that Akihiko raises the issue that in the actual implementation there should be a limitation of the maximum number of options. If such a limitation is different between src and dst, the difference could be noticed by the guest.
- Does it make sense to have fine configuration of hash types mask
via command-line?
- IMO, no. This would require the user to have too much knowledge
about RSS internals
Please let me know if I missed something.
Thanks