From: Jason Wang <jasowang@redhat.com>
To: Eugenio Perez Martin <eperezma@redhat.com>
Cc: Rob Miller <rob.miller@broadcom.com>,
Virtio-Dev <virtio-dev@lists.oasis-open.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Michael Tsirkin <mst@redhat.com>,
Juan Quintela <quintela@redhat.com>
Subject: Re: [virtio-dev] Dirty Page Tracking (DPT)
Date: Wed, 8 Apr 2020 06:10:39 -0400 (EDT) [thread overview]
Message-ID: <1650583197.21149342.1586340639830.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAJaqyWfW5z=3_exw9q5J=1axXan7qUndTE=kuNQp42Jup2j2xA@mail.gmail.com>
----- Original Message -----
> On Tue, Apr 7, 2020 at 12:28 PM Rob Miller <rob.miller@broadcom.com> wrote:
> >
> > Does this mean that SW takes over the datapath during LM?
>
> "Takes over" sounds to me like solving the problem using failover to
> switch to a software interface to do the packet forwarding during
> migration [1]. In this solution, only the used ring needs to be spied
> or intercepted to communicate qemu the memory regions modified.
>
> Not sure if this is what you had in mind.
>
> [1] https://www.dpdk.org/wp-content/uploads/sites/35/2019/10/VirtioNet.pdf
Yes, so my understanding is, there's two way for doing software
assisted live migration:
1) Switch to a full software datapath. I think this is what you meant
here, this work but may get more performance degradation.
2) Used ring relay, this means qemu will only take over the used ring,
this means when migration start, qemu will teach hardware to use
another (mediated) used ring, then qemu can inspect it and log the
dirty page from there, and relay the content to the used ring used
by guest. This can have better performance.
DPDK choose to use method 2). You may refer
https://www.dpdk.org/wp-content/uploads/sites/35/2018/12/XiaoWang-DPDK-US-Summit-SW-assisted-VDPA-for-LM-v2.pdf
>
> > If so, is there any infrastructure to "gracefully" do a hand-off from HW
> > mode (pci device is managing the rings) to SW mode, in that when switching
> > from HW->SW, HW is stalled & quiesced, then the SW takes from where HW
> > left off?
Yes, for both methods, it requires a stop & start the device.
And it also means the device should support the recovery of virtqueue
state. E.g it supports a last_avail_idx set by driver, then when the
device is started, it can try to read avail ring index start at
last_avail_idx. This is why vDPA bus support set_vq_state().
Thanks
> >
> > Rob Miller
> > rob.miller@broadcom.com
> > (919)721-3339
> >
> >
> > On Tue, Apr 7, 2020 at 5:53 AM Eugenio Perez Martin <eperezma@redhat.com>
> > wrote:
> >>
> >> Hi!
> >>
> >> So, from the previous mails, it seems that monitoring the used ring
> >> (and the packed descriptors) is a good first step in that direction,
> >> as DPDK did. This way, the device does not need to worry about the
> >> dirty page tracking using a bitmap and the PCI writes limitation, and
> >> we can evaluate later the proposed alternatives:
> >> * Alternate used descriptors in packed.
> >> * vDPA interface for vDPA devices in a convenient format.
> >>
> >> Any thoughts? Do you think that we should start with another way?
> >>
> >> Thanks!
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2020-04-08 10:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-06 15:40 [virtio-dev] Dirty Page Tracking (DPT) Rob Miller
2020-03-09 7:38 ` Michael S. Tsirkin
2020-03-09 8:50 ` Jason Wang
2020-03-09 10:13 ` Michael S. Tsirkin
2020-03-10 3:22 ` Jason Wang
2020-03-10 6:24 ` Michael S. Tsirkin
2020-03-10 6:39 ` Jason Wang
2020-03-18 15:13 ` Rob Miller
2020-03-19 3:35 ` Jason Wang
2020-03-19 11:17 ` Paolo Bonzini
2020-04-07 9:52 ` Eugenio Perez Martin
2020-04-07 10:27 ` Rob Miller
2020-04-07 16:31 ` Eugenio Perez Martin
2020-04-08 10:10 ` Jason Wang [this message]
2020-04-07 10:40 ` Rob Miller
2020-04-08 10:00 ` Jason Wang
2020-04-09 21:06 ` Michael S. Tsirkin
2020-04-10 2:40 ` Jason Wang
2020-04-13 12:15 ` Eugenio Perez Martin
2020-04-13 13:30 ` Rob Miller
2020-04-13 13:49 ` Jason Wang
2020-04-13 13:49 ` Jason Wang
2020-04-13 13:55 ` Jason Wang
2020-04-16 10:55 ` Eugenio Perez Martin
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=1650583197.21149342.1586340639830.JavaMail.zimbra@redhat.com \
--to=jasowang@redhat.com \
--cc=eperezma@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=quintela@redhat.com \
--cc=rob.miller@broadcom.com \
--cc=virtio-dev@lists.oasis-open.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.