> ZjQcmQRYFpfptBannerEnd > On Wed, Feb 25, 2026 at 01:31:50PM +0000, Srujana Challa wrote: > > > 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. > > > yes the device seems buggy in that configuration, in that it has this > requirement which does not seem to be in the spec. > > so tell me, what is the actual rss_max_key_size of that device? > We've confirmed our device works with clamping the key size. Our device's rss_max_key_size is 48 bytes. We will update the patch to use min(device rss_max_key_size, NETDEV_RSS_KEY_LEN) and drop the logic that disables RSS when "device rss_max_key_size > NETDEV_RSS_KEY_LEN" . And also drop the patch2. Will send a revised patch shortly.
Thanks! > > > > > > > > -- > > > MST > >
