[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACGkMEtCEwSB7XvCg7_8ebkcM8o2s8JB2Err2f153L-_i2KtxA@mail.gmail.com>
Date: Mon, 10 Mar 2025 12:01:00 +0800
From: Jason Wang <jasowang@...hat.com>
To: Akihiko Odaki <akihiko.odaki@...nix.com>
Cc: Jonathan Corbet <corbet@....net>, Willem de Bruijn <willemdebruijn.kernel@...il.com>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
"Michael S. Tsirkin" <mst@...hat.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Shuah Khan <shuah@...nel.org>, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, kvm@...r.kernel.org,
virtualization@...ts.linux-foundation.org, linux-kselftest@...r.kernel.org,
Yuri Benditovich <yuri.benditovich@...nix.com>, Andrew Melnychenko <andrew@...nix.com>,
Stephen Hemminger <stephen@...workplumber.org>, gur.stavi@...wei.com,
Lei Yang <leiyang@...hat.com>, Simon Horman <horms@...nel.org>
Subject: Re: [PATCH net-next v9 3/6] tun: Introduce virtio-net hash feature
On Mon, Mar 10, 2025 at 11:55 AM Jason Wang <jasowang@...hat.com> wrote:
>
> On Fri, Mar 7, 2025 at 7:01 PM Akihiko Odaki <akihiko.odaki@...nix.com> wrote:
> >
> > Hash reporting
> > ==============
> >
> > Allow the guest to reuse the hash value to make receive steering
> > consistent between the host and guest, and to save hash computation.
> >
> > RSS
> > ===
> >
> > RSS is a receive steering algorithm that can be negotiated to use with
> > virtio_net. Conventionally the hash calculation was done by the VMM.
> > However, computing the hash after the queue was chosen defeats the
> > purpose of RSS.
> >
> > Another approach is to use eBPF steering program. This approach has
> > another downside: it cannot report the calculated hash due to the
> > restrictive nature of eBPF steering program.
> >
> > Introduce the code to perform RSS to the kernel in order to overcome
> > thse challenges. An alternative solution is to extend the eBPF steering
> > program so that it will be able to report to the userspace, but I didn't
> > opt for it because extending the current mechanism of eBPF steering
> > program as is because it relies on legacy context rewriting, and
> > introducing kfunc-based eBPF will result in non-UAPI dependency while
> > the other relevant virtualization APIs such as KVM and vhost_net are
> > UAPIs.
> >
> > Signed-off-by: Akihiko Odaki <akihiko.odaki@...nix.com>
> > Tested-by: Lei Yang <leiyang@...hat.com>
> > ---
> > Documentation/networking/tuntap.rst | 7 ++
> > drivers/net/Kconfig | 1 +
> > drivers/net/tap.c | 68 ++++++++++++++-
> > drivers/net/tun.c | 98 +++++++++++++++++-----
> > drivers/net/tun_vnet.h | 159 ++++++++++++++++++++++++++++++++++--
> > include/linux/if_tap.h | 2 +
> > include/linux/skbuff.h | 3 +
> > include/uapi/linux/if_tun.h | 75 +++++++++++++++++
> > net/core/skbuff.c | 4 +
> > 9 files changed, 386 insertions(+), 31 deletions(-)
[...]
> > + *
> > + * The %TUN_VNET_HASH_REPORT flag set with this ioctl will be effective only
> > + * after calling the %TUNSETVNETHDRSZ ioctl with a number greater than or equal
> > + * to the size of &struct virtio_net_hdr_v1_hash.
>
> So you had a dependency check already for vnet hdr len. I'd still
> suggest to split this into rss and hash as they are separated
> features. Then we can use separate data structure for them instead of
> a container struct.
>
Besides this, I think we still need to add new bits to TUNGETIFF to
let userspace know about the new ability.
Thanks
Powered by blists - more mailing lists