qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v3 5/6] virtio-net: Added eBPF RSS to virtio-net.


From: Jason Wang
Subject: Re: [RFC PATCH v3 5/6] virtio-net: Added eBPF RSS to virtio-net.
Date: Mon, 18 Jan 2021 11:16:08 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0


On 2021/1/17 下午5:04, Yuri Benditovich wrote:
On Fri, Jan 15, 2021 at 9:20 AM Jason Wang<jasowang@redhat.com>  wrote:
On 2021/1/15 上午5:16, Andrew Melnychenko wrote:
From: Andrew<andrew@daynix.com>

When RSS is enabled the device tries to load the eBPF program
to select RX virtqueue in the TUN. If eBPF can be loaded
the RSS will function also with vhost (works with kernel 5.8 and later).
Software RSS is used as a fallback with vhost=off when eBPF can't be loaded
or when hash population requested by the guest.

Signed-off-by: Yuri Benditovich<yuri.benditovich@daynix.com>
Signed-off-by: Andrew Melnychenko<andrew@daynix.com>
---
   hw/net/vhost_net.c             |   2 +
   hw/net/virtio-net.c            | 125 +++++++++++++++++++++++++++++++--
   include/hw/virtio/virtio-net.h |   4 ++
   net/vhost-vdpa.c               |   2 +
   4 files changed, 129 insertions(+), 4 deletions(-)

diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index 24d555e764..16124f99c3 100644
--- a/hw/net/vhost_net.c
+++ b/hw/net/vhost_net.c
@@ -71,6 +71,8 @@ static const int user_feature_bits[] = {
       VIRTIO_NET_F_MTU,
       VIRTIO_F_IOMMU_PLATFORM,
       VIRTIO_F_RING_PACKED,
+    VIRTIO_NET_F_RSS,
+    VIRTIO_NET_F_HASH_REPORT,

       /* This bit implies RARP isn't sent by QEMU out of band */
       VIRTIO_NET_F_GUEST_ANNOUNCE,
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 09ceb02c9d..37016fc73a 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -691,6 +691,19 @@ static void virtio_net_set_queues(VirtIONet *n)

   static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue);

+static uint64_t fix_ebpf_vhost_features(uint64_t features)
+{
+    /* If vhost=on & CONFIG_EBPF doesn't set - disable RSS feature */
I still think we should not clear feature silently. This may break
migraiton if the feature is cleared on destination.
Do I understand it correctly that if we do not clear features silently
and implement a graceful drop to vhost=off when we can't do what we
need with vhost - then we do not need to add any migration blocker?


Yes. I think we won't go with migration blocker since we need support migration in the end.

Thanks







reply via email to

[Prev in Thread] Current Thread [Next in Thread]