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? -- MST
