From: "Tetsuya.Mukawa" <mukawa-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
To: "Ouyang,
Changchun"
<changchun.ouyang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"dev-VfR2kkLFssw@public.gmane.org"
<dev-VfR2kkLFssw@public.gmane.org>
Cc: Katsuya MATSUBARA <matsu-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>,
"nakajima.yoshihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org"
<nakajima.yoshihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>,
Hitoshi Masutani
<masutani.hitoshi-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
Subject: Re: [RFC] lib/librte_vhost: qemu vhost-user support into DPDK vhost library
Date: Wed, 27 Aug 2014 14:27:42 +0900 [thread overview]
Message-ID: <53FD6C4E.5040907@igel.co.jp> (raw)
In-Reply-To: <F52918179C57134FAEC9EA62FA2F96251183B731-E2R4CRU6q/6iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi Changchun,
(2014/08/27 14:01), Ouyang, Changchun wrote:
> Agree with you, the performance should be same as the data path (RX/TX) is not affected,
> The difference between implementation only exists in the virtio device creation and destroy stage.
Yes, I agree. Also There may be the difference, if a virtio-net driver
on a guest isn't poll mode like a virtio-net device driver in the
kernel. In the case, existing vhost implementation uses the eventfd
kernel module, and vhost-user implementation uses eventfd to kick the
driver. So I guess there will be the difference.
Anyway, about device creation and destruction, the difference will come
from transmission speed between unix domain socket and CUSE. I am not
sure which is faster.
Thanks,
Tetsuya
>
> Regards,
> Changchun
>
>> -----Original Message-----
>> From: Tetsuya.Mukawa [mailto:mukawa-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org]
>> Sent: Wednesday, August 27, 2014 12:39 PM
>> To: Ouyang, Changchun; dev-VfR2kkLFssw@public.gmane.org
>> Cc: Xie, Huawei; Katsuya MATSUBARA; nakajima.yoshihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org;
>> Hitoshi Masutani
>> Subject: Re: [dpdk-dev] [RFC] lib/librte_vhost: qemu vhost-user support into
>> DPDK vhost library
>>
>>
>> (2014/08/27 9:43), Ouyang, Changchun wrote:
>>> Do we have performance comparison between both implementation?
>> Hi Changchun,
>>
>> If DPDK applications are running on both guest and host side, the
>> performance should be almost same, because while transmitting data virt
>> queues are accessed by virtio-net PMD and libvhost. In libvhost, the existing
>> vhost implementation and a vhost-user implementation will shares or uses
>> same code to access virt queues. So I guess the performance will be almost
>> same.
>>
>> Thanks,
>> Tetsuya
>>
>>
>>> Thanks
>>> Changchun
>>>
>>>
>>> -----Original Message-----
>>> From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Xie, Huawei
>>> Sent: Tuesday, August 26, 2014 7:06 PM
>>> To: dev-VfR2kkLFssw@public.gmane.org
>>> Subject: Re: [dpdk-dev] [RFC] lib/librte_vhost: qemu vhost-user
>>> support into DPDK vhost library
>>>
>>> Hi all:
>>> We are implementing qemu official vhost-user interface into DPDK vhost
>> library, so there would be two coexisting implementations for user space
>> vhost backend.
>>> Pro and cons in my mind:
>>> Existing solution:
>>> Pros: works with qemu version before 2.1; Cons: depends on eventfd
>> proxy kernel module and extra maintenance effort Qemu vhost-user:
>>> Pros: qemu official us-vhost interface; Cons: only available after
>> qemu 2.1
>>> BR.
>>> huawei
next prev parent reply other threads:[~2014-08-27 5:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 11:05 [RFC] lib/librte_vhost: qemu vhost-user support into DPDK vhost library Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F27BC38-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-08-27 0:43 ` Ouyang, Changchun
[not found] ` <F52918179C57134FAEC9EA62FA2F96251183B590-E2R4CRU6q/6iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-08-27 4:39 ` Tetsuya.Mukawa
[not found] ` <53FD60FD.5090903-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2014-08-27 5:01 ` Ouyang, Changchun
[not found] ` <F52918179C57134FAEC9EA62FA2F96251183B731-E2R4CRU6q/6iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-08-27 5:27 ` Tetsuya.Mukawa [this message]
[not found] ` <53FD6C4E.5040907-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2014-08-27 5:56 ` Xie, Huawei
[not found] ` <C37D651A908B024F974696C65296B57B0F27C711-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-08-27 6:07 ` Tetsuya.Mukawa
2014-08-27 5:58 ` Tetsuya.Mukawa
2014-08-27 6:00 ` Ouyang, Changchun
[not found] ` <F52918179C57134FAEC9EA62FA2F96251183B7EE-E2R4CRU6q/6iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-08-27 6:09 ` Tetsuya.Mukawa
2014-09-13 5:27 ` Linhaifeng
[not found] ` <5413D5DA.9030607-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2014-09-16 1:36 ` Xie, Huawei
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=53FD6C4E.5040907@igel.co.jp \
--to=mukawa-alsx/un32fvpdbfq/vqriq@public.gmane.org \
--cc=changchun.ouyang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
--cc=masutani.hitoshi-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
--cc=matsu-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org \
--cc=nakajima.yoshihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.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.