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, 25 Jan 2021 16:59:24 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0


On 2021/1/24 下午4:24, Yuri Benditovich wrote:
Hi Jason,

I've prepared a POC of graceful switch to 'vhost off' if respective
features are acked by the guest.
Such a way we do not need to silently clear RSS and hash report
features in case of 'vhost on'.
Can you please review it and provide your feedback?

I think the only open question is what to do with cases of vhost-user
and vhost-vdpa.

https://github.com/qemu/qemu/pull/105
This pull request is for reviews only.

Thanks in advance


Will review it sometime this week.

Thanks








On Mon, Jan 18, 2021 at 5:16 AM Jason Wang <jasowang@redhat.com> wrote:

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]