On Mon, Jun 23, 2025 at 1:40 AM Yuri Benditovich <yuri.benditovich@xxxxxxxxxx> wrote: > > > Yuri, can you help to clarify this? > > I see here several questions: > 1. 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? > 3. 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. > 4. 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
