qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Wei Wang" <wei.w.wang@intel.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Stefan Hajnoczi" <stefanha@gmail.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>
Subject: Re: [Qemu-devel] [virtio-dev] Vhost-pci RFC2.0
Date: Fri, 5 May 2017 17:18:54 +0800	[thread overview]
Message-ID: <3f76f518-c157-822e-17c6-17d81f6ac62a@redhat.com> (raw)
In-Reply-To: <590C1948.6010301@intel.com>



On 2017年05月05日 14:18, Wei Wang wrote:
> On 05/05/2017 12:05 PM, Jason Wang wrote:
>>
>>
>> On 2017年04月19日 14:38, Wang, Wei W wrote:
>>> Hi,
>>> We made some design changes to the original vhost-pci design, and 
>>> want to open
>>> a discussion about the latest design (labelled 2.0) and its 
>>> extension (2.1).
>>> 2.0 design: One VM shares the entire memory of another VM
>>> 2.1 design: One VM uses an intermediate memory shared with another 
>>> VM for
>>>                      packet transmission.
>>> For the convenience of discussion, I have some pictures presented at 
>>> this link:
>>> _https://github.com/wei-w-wang/vhost-pci-discussion/blob/master/vhost-pci-rfc2.0.pdf_ 
>>>
>>
>> Hi, is there any doc or pointer that describes the the design in 
>> detail? E.g patch 4 in v1 
>> https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg05163.html.
>>
>> Thanks
>
> That link is kind of obsolete.
>
> We currently only have high level introduction of the design:
>
> For the device part design, please check slide 12:
> http://www.linux-kvm.org/images/5/55/02x07A-Wei_Wang-Design_of-Vhost-pci.pdf 
>
> The vhost-pci protocol is changed to be an extension of vhost-user 
> protocol.
>
> For the driver part design, please check Fig. 2:
>
> https://github.com/wei-w-wang/vhost-pci-discussion/blob/master/vhost-pci-rfc2.0.pdf 
>

Thanks for the pointers. It would be nice to have a doc like patch 4 in 
v1, this could ease reviewers, otherwise we may guess and ask for them.

>
>
>>> Fig. 1 shows the common driver frame that we want use to build the 
>>> 2.0 and 2.1
>>> design. A TX/RX engine consists of a local ring and an exotic ring.
>>> Local ring:
>>> 1) allocated by the driver itself;
>>> 2) registered with the device (i.e. virtio_add_queue())
>>> Exotic ring:
>>> 1) ring memory comes from the outside (of the driver), and exposed 
>>> to the driver
>>>      via a BAR MMIO;
>>> 2) does not have a registration in the device, so no 
>>> ioeventfd/irqfd, configuration
>>> registers allocated in the device
>>> Fig. 2 shows how the driver frame is used to build the 2.0 design.
>>> 1) Asymmetric: vhost-pci-net <-> virtio-net
>>> 2) VM1 shares the entire memory of VM2, and the exotic rings are the 
>>> rings
>>>     from VM2.
>>> 3) Performance (in terms of copies between VMs):
>>>     TX: 0-copy (packets are put to VM2’s RX ring directly)
>>>     RX: 1-copy (the green arrow line in the VM1’s RX engine)
>>> Fig. 3 shows how the driver frame is used to build the 2.1 design.
>>> 1) Symmetric: vhost-pci-net <-> vhost-pci-net
>>> 2) Share an intermediate memory, allocated by VM1’s vhost-pci device,
>>> for data exchange, and the exotic rings are built on the shared memory
>>> 3) Performance:
>>>     TX: 1-copy
>>> RX: 1-copy
>>> Fig. 4 shows the inter-VM notification path for 2.0 (2.1 is similar).
>>> The four eventfds are allocated by virtio-net, and shared with 
>>> vhost-pci-net:
>>> Uses virtio-net’s TX/RX kickfd as the vhost-pci-net’s RX/TX callfd
>>> Uses virtio-net’s TX/RX callfd as the vhost-pci-net’s RX/TX kickfd
>>> Example of how it works:
>>> After packets are put into vhost-pci-net’s TX, the driver kicks TX, 
>>> which
>>> causes the an interrupt associated with fd3 to be injected to 
>>> virtio-net
>>> The draft code of the 2.0 design is ready, and can be found here:
>>> Qemu: _https://github.com/wei-w-wang/vhost-pci-device_
>>> Guest driver: _https://github.com/wei-w-wang/vhost-pci-driver_
>>> We tested the 2.0 implementation using the Spirent packet
>>> generator to transmit 64B packets, the results show that the
>>> throughput of vhost-pci reaches around 1.8Mpps, which is around
>>> two times larger than the legacy OVS+DPDK.
>>
>> Does this mean OVS+DPDK can only have ~0.9Mpps? A little bit surprise 
>> that the number looks rather low (I can get similar result if I use 
>> kernel bridge).
>>
>
> Yes, that's what we got on our machine (E5-2699 @2.2G). Do you have 
> numbers of OVS+DPDK?
>
> Best,
> Wei
>
>

I don't, I only have kernel data path numbers now. Just curious about 
the numbers.

Thanks

  reply	other threads:[~2017-05-05  9:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19  6:38 [Qemu-devel] Vhost-pci RFC2.0 Wang, Wei W
2017-04-19  7:31 ` Marc-André Lureau
2017-04-19  8:33   ` Wei Wang
2017-04-19  7:35 ` Jan Kiszka
2017-04-19  8:42   ` Wei Wang
2017-04-19  8:49     ` [Qemu-devel] [virtio-dev] " Jan Kiszka
2017-04-19  9:09       ` Wei Wang
2017-04-19  9:31         ` Jan Kiszka
2017-04-19 10:02           ` Wei Wang
2017-04-19 10:36             ` Jan Kiszka
2017-04-19 11:11               ` Wei Wang
2017-04-19 11:21                 ` Jan Kiszka
2017-04-19 14:33                   ` Wang, Wei W
2017-04-19 14:52                     ` Jan Kiszka
2017-04-20  6:51                       ` Wei Wang
2017-04-20  7:05                         ` Jan Kiszka
2017-04-20  8:58                           ` Wei Wang
2017-04-19  9:57 ` [Qemu-devel] [virtio-dev] " Stefan Hajnoczi
2017-04-19 10:42   ` Wei Wang
2017-04-19 15:24     ` Stefan Hajnoczi
2017-04-20  5:51       ` Wei Wang
2017-05-02 12:48         ` Stefan Hajnoczi
2017-05-03  6:02           ` Wei Wang
2017-05-05  4:05 ` Jason Wang
2017-05-05  6:18   ` Wei Wang
2017-05-05  9:18     ` Jason Wang [this message]
2017-05-08  1:39       ` Wei Wang

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=3f76f518-c157-822e-17c6-17d81f6ac62a@redhat.com \
    --to=jasowang@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=wei.w.wang@intel.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).