From: Yuri Benditovich <yuri.benditovich@daynix.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Yan Vugenfirer <yan@daynix.com>,
qemu-devel@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH 3/3] virtio-net: graceful fallback to vhost=off for tap netdev
Date: Mon, 8 Feb 2021 21:59:38 +0200 [thread overview]
Message-ID: <CAOEp5Oco51MuLDEsxFrLtVpOWa1r7vrwLstAkJozfbt+AbVauQ@mail.gmail.com> (raw)
In-Reply-To: <1f0f901c-8ad0-60a4-383f-851fc0f093ff@redhat.com>
On Mon, Feb 8, 2021 at 6:11 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2021/2/5 上午4:29, Yuri Benditovich wrote:
> > Currently virtio-net silently clears features if they are
> > not supported by respective vhost. This may create migration
> > problems in future if vhost features on the source and destination
> > are different. Implement graceful fallback to no-vhost mode
> > when some acked features contradict with vhost. The decision is
> > taken on set_features call and the vhost will be disabled
> > till next reset (or migration).
> > Such fallback is currently enabled only for TAP netdev.
> >
> > Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
> > ---
> > hw/net/virtio-net.c | 58 ++++++++++++++++++++++++++++++++++++++-------
> > 1 file changed, 50 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 5150f295e8..b353060e63 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -515,6 +515,15 @@ static RxFilterInfo *virtio_net_query_rxfilter(NetClientState *nc)
> > return info;
> > }
> >
> > +static void virtio_net_allow_vhost(VirtIONet *n, bool allow)
> > +{
> > + int i;
> > + for (i = 0; i < n->max_queues; i++) {
> > + NetClientState *nc = qemu_get_subqueue(n->nic, i)->peer;
> > + nc->vhost_net_disabled = !allow;
> > + }
> > +}
> > +
> > static void virtio_net_reset(VirtIODevice *vdev)
> > {
> > VirtIONet *n = VIRTIO_NET(vdev);
> > @@ -552,6 +561,7 @@ static void virtio_net_reset(VirtIODevice *vdev)
> > assert(!virtio_net_get_subqueue(nc)->async_tx.elem);
> > }
> > }
> > + virtio_net_allow_vhost(n, true);
> > }
> >
> > static void peer_test_vnet_hdr(VirtIONet *n)
> > @@ -689,6 +699,15 @@ static void virtio_net_set_queues(VirtIONet *n)
> > }
> > }
> >
> > +static bool can_disable_vhost(VirtIONet *n)
> > +{
> > + NetClientState *peer = qemu_get_queue(n->nic)->peer;
> > + if (!get_vhost_net(peer)) {
> > + return false;
> > + }
> > + return !peer || peer->info->type == NET_CLIENT_DRIVER_TAP;
> > +}
> > +
> > static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue);
> >
> > static uint64_t virtio_net_get_features(VirtIODevice *vdev, uint64_t features,
> > @@ -725,14 +744,14 @@ static uint64_t virtio_net_get_features(VirtIODevice *vdev, uint64_t features,
> > return features;
> > }
> >
> > - virtio_clear_feature(&features, VIRTIO_NET_F_RSS);
> > - virtio_clear_feature(&features, VIRTIO_NET_F_HASH_REPORT);
> > - features = vhost_net_get_features(get_vhost_net(nc->peer), features);
> > - vdev->backend_features = features;
> > + vdev->backend_features = vhost_net_get_features(get_vhost_net(nc->peer), features);
> >
> > - if (n->mtu_bypass_backend &&
> > - (n->host_features & 1ULL << VIRTIO_NET_F_MTU)) {
> > - features |= (1ULL << VIRTIO_NET_F_MTU);
> > + if (!can_disable_vhost(n)) {
> > + features = vdev->backend_features;
> > + if (n->mtu_bypass_backend &&
> > + (n->host_features & 1ULL << VIRTIO_NET_F_MTU)) {
> > + features |= (1ULL << VIRTIO_NET_F_MTU);
> > + }
> > }
> >
> > return features;
> > @@ -872,10 +891,25 @@ static void failover_add_primary(VirtIONet *n, Error **errp)
> > error_propagate(errp, err);
> > }
> >
> > +static bool check_vhost_features(VirtIONet *n, uint64_t features)
> > +{
> > + NetClientState *nc = qemu_get_queue(n->nic);
> > + uint64_t filtered;
> > + if (n->rss_data.redirect) {
> > + return false;
> > + }
> > + filtered = vhost_net_get_features(get_vhost_net(nc->peer), features);
> > + if (filtered != features) {
> > + return false;
> > + }
> > + return true;
> > +}
> > +
> > static void virtio_net_set_features(VirtIODevice *vdev, uint64_t features)
> > {
> > VirtIONet *n = VIRTIO_NET(vdev);
> > Error *err = NULL;
> > + bool disable_vhost = false;
> > int i;
> >
> > if (n->mtu_bypass_backend &&
> > @@ -894,13 +928,21 @@ static void virtio_net_set_features(VirtIODevice *vdev, uint64_t features)
> > VIRTIO_F_VERSION_1),
> > virtio_has_feature(features,
> > VIRTIO_NET_F_HASH_REPORT));
> > -
> > n->rsc4_enabled = virtio_has_feature(features, VIRTIO_NET_F_RSC_EXT) &&
> > virtio_has_feature(features, VIRTIO_NET_F_GUEST_TSO4);
> > n->rsc6_enabled = virtio_has_feature(features, VIRTIO_NET_F_RSC_EXT) &&
> > virtio_has_feature(features, VIRTIO_NET_F_GUEST_TSO6);
> > n->rss_data.redirect = virtio_has_feature(features, VIRTIO_NET_F_RSS);
> >
> > + if (can_disable_vhost(n)) {
> > + disable_vhost = !check_vhost_features(n, features);
> > + }
> > + if (disable_vhost) {
> > + warn_report("Some of requested features aren't supported by vhost, "
> > + "vhost is turned off till next reset");
> > + virtio_net_allow_vhost(n, false);
> > + }
>
>
> This looks more complicated than I expected. See
> virtio_net_vhost_status() we had a fallback there:
>
> r = vhost_net_start(vdev, n->nic->ncs, queues);
> if (r < 0) {
> error_report("unable to start vhost net: %d: "
> "falling back on userspace virtio", -r);
> n->vhost_started = 0;
> }
>
> I wonder if we can simply depends on this (which is proved to be work
> for the past years) by not clearing dev->acked_features like:
>
> if (!can_disable_vhost(n)) {
> features = vhost_net_get_features(get_vhost_net(nc->peer), features);
> } else {
> vdev->backend_features = features;
> }
>
> Then we probably don't need other tricks.
Of course we can.
But I would prefer to make things more clear, i.e. make
get_vhost_net() always return a meaningful result, even (as an
example) in procedures called from set_feature() after the
vhost_disabled is set.
Otherwise people can rely on get_vhost_net() and call its methods
which potentially can do something that we do not expect.
In some places in the code (also in future) we'll need to check not
only get_vhost_net() but also is_vhost_disabled. IMO, not too elegant,
but possible.
Of course, being a decision maker, you can request to do it simpler
and do not maintain a consistent result of get_vhost_net().
But then please tell it explicitly.
>
> Thanks
>
>
> > +
> > if (n->has_vnet_hdr) {
> > n->curr_guest_offloads =
> > virtio_net_guest_offloads_by_features(features);
>
next prev parent reply other threads:[~2021-02-08 22:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 20:29 [PATCH 0/3] virtio-net: graceful drop of vhost for TAP Yuri Benditovich
2021-02-04 20:29 ` [PATCH 1/3] vhost-net: add VIRTIO_NET_F_HASH_REPORT to the list of kernel features Yuri Benditovich
2021-02-04 20:29 ` [PATCH 2/3] net: add ability to hide (disable) vhost_net Yuri Benditovich
2021-02-04 20:29 ` [PATCH 3/3] virtio-net: graceful fallback to vhost=off for tap netdev Yuri Benditovich
2021-02-05 13:38 ` Michael S. Tsirkin
2021-02-05 13:43 ` Michael S. Tsirkin
2021-02-08 3:15 ` Jason Wang
2021-02-08 19:46 ` Yuri Benditovich
2021-02-09 3:39 ` Jason Wang
2021-02-08 4:11 ` Jason Wang
2021-02-08 19:59 ` Yuri Benditovich [this message]
2021-02-09 3:45 ` Jason Wang
2021-02-09 14:34 ` [PATCH 0/3] virtio-net: graceful drop of vhost for TAP Michael S. Tsirkin
2021-02-09 14:51 ` Daniel P. Berrangé
2021-02-09 15:04 ` Michael S. Tsirkin
2021-02-09 15:18 ` Daniel P. Berrangé
2021-02-10 6:19 ` Jason Wang
2021-02-10 8:38 ` Michael S. Tsirkin
2021-02-18 3:02 ` Jason Wang
2021-02-18 9:35 ` Daniel P. Berrangé
2021-02-18 19:55 ` Yuri Benditovich
2021-02-19 9:35 ` Daniel P. Berrangé
2021-02-18 9:30 ` Daniel P. Berrangé
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=CAOEp5Oco51MuLDEsxFrLtVpOWa1r7vrwLstAkJozfbt+AbVauQ@mail.gmail.com \
--to=yuri.benditovich@daynix.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yan@daynix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).