On Wed, Feb 25, 2026 at 12:56:19PM +0000, Srujana Challa wrote:

quoted

quoted

quoted

quoted

quoted

quoted

quoted

So if device is powerful and supports a very big key size then...
we disable the feature? how does this make sense?

The intent isn’t to disable the feature on capable devices,
but to ensure the driver never advertises support for RSS
key sizes larger than what the net device can actually
handle. Even if a device reports a very

large key size, the driver is constrained by
NETDEV_RSS_KEY_LEN, since
netdev_rss_key_fill() enforces:

quoted

BUG_ON(len > sizeof(netdev_rss_key));

so cap it to NETDEV_RSS_KEY_LEN. Why is that a reason to clear
the

feature?

quoted

Our device mandates that hash_key_length must be identical to
rss_max_key_size to guarantee symmetric bidirectional flow hashing.
If rss_max_key_size is larger than VIRTIO_NET_RSS_MAX_KEY_SIZE,
clamping

the value is not feasible.

I don't know what to tell you. rss_max_key_size is just the max
device supports. driver should be free to use a smaller size.

My understanding is that this patch prevents the probe from failing
by disabling the feature instead.
Given the current implementation, the driver becomes unusable when
this condition is hit.

I understand that the driver is allowed to use a smaller RSS key than the

device’s advertised rss_max_key_size.

quoted

But, our hardware does not behave correctly in that configuration. For
symmetric bidirectional hashing, the device requires that the

hash_key_length match rss_max_key_size exactly.

quoted

If the driver uses a smaller key, the hardware produces inconsistent hash

values for forward vs reverse flows.

quoted

Because of this device requirement, we cannot cap the key to
NETDEV_RSS_KEY_LEN when the device advertises a larger

rss_max_key_size.

Would you not say it's a buggy device then?

No. The device works correctly when a smaller key is used. The limitation only affects
symmetric bidirectional hashing. For the other use cases capping the key size is fine.

--
MST