qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Yajun Wu <yajunw@nvidia.com>
Cc: qemu-devel@nongnu.org, parav@nvidia.com
Subject: Re: [PATCH v3 0/2] vhost-user: Support vhost_dev_start
Date: Fri, 4 Nov 2022 03:11:40 -0400	[thread overview]
Message-ID: <20221104025833-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20221017064452.1226514-1-yajunw@nvidia.com>

On Mon, Oct 17, 2022 at 02:44:50PM +0800, Yajun Wu wrote:
> The motivation of adding vhost-user vhost_dev_start support is to
> improve backend configuration speed and reduce live migration VM
> downtime.
> 
> Today VQ configuration is issued one by one. For virtio net with
> multi-queue support, backend needs to update RSS (Receive side
> scaling) on every rx queue enable. Updating RSS is time-consuming
> (typical time like 7ms).
> 
> Implement already defined vhost status and message in the vhost
> specification [1].
> (a) VHOST_USER_PROTOCOL_F_STATUS
> (b) VHOST_USER_SET_STATUS
> (c) VHOST_USER_GET_STATUS
> 
> Send message VHOST_USER_SET_STATUS with VIRTIO_CONFIG_S_DRIVER_OK for
> device start and reset(0) for device stop.
> 
> On reception of the DRIVER_OK message, backend can apply the needed setting
> only once (instead of incremental) and also utilize parallelism on enabling
> queues.
> 
> This improves QEMU's live migration downtime with vhost user backend
> implementation by great margin, specially for the large number of VQs of 64
> from 800 msec to 250 msec.
> 
> Another change is to move the device start routines after finishing all the
> necessary device and VQ configuration, further aligning to the virtio
> specification for "device initialization sequence".
> 
> [1] https://qemu-project.gitlab.io/qemu/interop/vhost-user.html#introduction


This patchset seems to trip up ubsan.
https://gitlab.com/mitsirkin/qemu/-/pipelines/684763327/failures


specifially:

passes before this patchset:
https://gitlab.com/mitsirkin/qemu/-/jobs/3269302594

fails with this patchset:
https://gitlab.com/mitsirkin/qemu/-/pipelines/684763327/failures

(there's one patch on top but it seems unrelated)


Seems hard to debug, only reproduced under gitlab though Stefan reports
reproducing this locally.
I'm thinking of dropping this patchset for now, deferring to next
release - thoughts?



> v3:
> - rebase
> 
> v2:
> - add setting status bit VIRTIO_CONFIG_S_FEATURES_OK
> - avoid adding status bits already set
> 
> Yajun Wu (2):
>   vhost: Change the sequence of device start
>   vhost-user: Support vhost_dev_start
> 
>  hw/block/vhost-user-blk.c | 18 ++++++----
>  hw/net/vhost_net.c        | 12 +++----
>  hw/virtio/vhost-user.c    | 74 ++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 90 insertions(+), 14 deletions(-)
> 
> -- 
> 2.27.0



  parent reply	other threads:[~2022-11-04  7:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29  2:25 [PATCH 0/2] vhost-user: Support vhost_dev_start Yajun Wu
2022-06-29  2:25 ` [PATCH 1/2] vhost: Change the sequence of device start Yajun Wu
2022-06-29  2:25 ` [PATCH 2/2] vhost-user: Support vhost_dev_start Yajun Wu
2022-07-12 10:54 ` [PATCH v2 0/2] " Yajun Wu
2022-07-12 10:55   ` [PATCH v2 1/2] vhost: Change the sequence of device start Yajun Wu
2022-07-12 10:55   ` [PATCH v2 2/2] vhost-user: Support vhost_dev_start Yajun Wu
2022-07-26 14:56   ` [PATCH v2 0/2] " Michael S. Tsirkin
2022-09-05  4:58     ` Yajun Wu
2022-10-12 10:10       ` Yajun Wu
2022-10-17  6:44 ` [PATCH v3 " Yajun Wu
2022-10-17  6:44   ` [PATCH v3 1/2] vhost: Change the sequence of device start Yajun Wu
2022-11-05 16:43     ` Michael S. Tsirkin
2022-10-17  6:44   ` [PATCH v3 2/2] vhost-user: Support vhost_dev_start Yajun Wu
2022-11-04  7:11   ` Michael S. Tsirkin [this message]
2022-11-04  7:58     ` [PATCH v3 0/2] " Michael S. Tsirkin
2022-11-07  4:08 ` [PATCH v4 " Yajun Wu
2022-11-07  4:08   ` [PATCH v4 1/2] vhost: Change the sequence of device start Yajun Wu
2022-11-07  4:08   ` [PATCH v4 2/2] vhost-user: Support vhost_dev_start Yajun Wu

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=20221104025833-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=parav@nvidia.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yajunw@nvidia.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).