Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	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>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [virtio-dev] Dirty Page Tracking (DPT)
Date: Fri, 10 Apr 2020 10:40:00 +0800	[thread overview]
Message-ID: <cf4a59a4-ee86-1d9e-147e-e30e586e2320@redhat.com> (raw)
In-Reply-To: <20200409170152-mutt-send-email-mst@kernel.org>


On 2020/4/10 上午5:06, Michael S. Tsirkin wrote:
> On Tue, Apr 07, 2020 at 11:52:46AM +0200, Eugenio Perez Martin 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!
> I am concerned that with software in data path, we'll hit RX queue
> underruns, won't we?


Do you mean it will lose some performance? If yes, I think so.


> Two ways to avoid underruns:
> - dirty page tracking
> - page faults


It looks to me this will lead even worse performance than software path? 
There will be lots of page faults during RX.

Another direction is to track dirty pages via IOMMU. E.g recent Intel 
IOMMU has EA and D bit which could be used for tracking pages wrote by 
devices but not CPU.


>
> I'm working on a proposal for page faults now.


I guess it's better to have a transport independent method.


> If someone wants
> to work on dirty tracking in addition, that's also an option.


I remember Rob mention some challenges of implementing dirty bitmap, I 
wonder something like queue based interface would be better (similar to 
Peter did for KVM)?

Thanks


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2020-04-10  2:40 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
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 [this message]
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=cf4a59a4-ee86-1d9e-147e-e30e586e2320@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox