> On Wed, Feb 25, 2026 at 12:56:19PM +0000, Srujana Challa wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > 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:
> > > > > > > BUG_ON(len > sizeof(netdev_rss_key));
> > > > > >
> > > > > > so cap it to NETDEV_RSS_KEY_LEN. Why is that a reason to clear
> > > > > > the
> > > > feature?
> > > > > 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.
> > 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.
> > If the driver uses a smaller key, the hardware produces inconsistent hash
> values for forward vs reverse flows.
> > 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
