From: "Michael S. Tsirkin" <mst@redhat.com>
To: Srujana Challa <schalla@marvell.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"xuanzhuo@linux.alibaba.com" <xuanzhuo@linux.alibaba.com>,
"eperezma@redhat.com" <eperezma@redhat.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
Shiva Shankar Kommula <kshankar@marvell.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [EXTERNAL] Re: [PATCH net,v4,1/2] virtio_net: Improve RSS key size validation and use NETDEV_RSS_KEY_LEN
Date: Wed, 25 Feb 2026 08:21:16 -0500 [thread overview]
Message-ID: <20260225081735-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <BY1PR18MB6374C5EC263CB6812B197296A075A@BY1PR18MB6374.namprd18.prod.outlook.com>
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
next prev parent reply other threads:[~2026-02-25 13:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 6:58 [PATCH net,v4,1/2] virtio_net: Improve RSS key size validation and use NETDEV_RSS_KEY_LEN Srujana Challa
2026-02-24 6:58 ` [PATCH net-next,2/2] virtio_net: replace RSS key size max check with BUILD_BUG_ON Srujana Challa
2026-02-25 9:11 ` Xuan Zhuo
2026-02-25 9:24 ` Michael S. Tsirkin
2026-02-25 9:30 ` Xuan Zhuo
2026-02-25 9:33 ` Michael S. Tsirkin
2026-02-25 9:36 ` Xuan Zhuo
2026-02-25 9:47 ` Michael S. Tsirkin
2026-02-25 9:52 ` Xuan Zhuo
2026-02-25 10:01 ` Michael S. Tsirkin
2026-02-25 10:05 ` Michael S. Tsirkin
2026-02-25 12:13 ` [EXTERNAL] " Srujana Challa
2026-02-25 12:18 ` Michael S. Tsirkin
2026-02-25 12:29 ` Srujana Challa
2026-02-25 12:35 ` Michael S. Tsirkin
2026-02-25 14:50 ` David Laight
2026-02-25 14:52 ` Michael S. Tsirkin
2026-02-25 10:03 ` [PATCH net,v4,1/2] virtio_net: Improve RSS key size validation and use NETDEV_RSS_KEY_LEN Michael S. Tsirkin
2026-02-25 12:22 ` [EXTERNAL] " Srujana Challa
2026-02-25 12:24 ` Michael S. Tsirkin
2026-02-25 12:34 ` Srujana Challa
2026-02-25 12:37 ` Michael S. Tsirkin
2026-02-25 12:47 ` Srujana Challa
2026-02-25 12:52 ` Michael S. Tsirkin
2026-02-25 12:56 ` Srujana Challa
2026-02-25 13:21 ` Michael S. Tsirkin [this message]
2026-02-25 13:31 ` Srujana Challa
2026-02-25 13:57 ` Michael S. Tsirkin
2026-02-26 12:38 ` Srujana Challa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260225081735-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=kshankar@marvell.com \
--cc=kuba@kernel.org \
--cc=ndabilpuram@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=schalla@marvell.com \
--cc=stable@vger.kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.