From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 0/3] vhost: accelerate metadata access through vmap()
Date: Fri, 14 Dec 2018 11:42:18 +0800 [thread overview]
Message-ID: <9459e227-a943-8553-732b-d7f5225a0f22@redhat.com> (raw)
In-Reply-To: <20181213102315-mutt-send-email-mst@kernel.org>
On 2018/12/13 下午11:27, Michael S. Tsirkin wrote:
> On Thu, Dec 13, 2018 at 06:10:19PM +0800, Jason Wang wrote:
>> Hi:
>>
>> This series tries to access virtqueue metadata through kernel virtual
>> address instead of copy_user() friends since they had too much
>> overheads like checks, spec barriers or even hardware feature
>> toggling.
> Userspace accesses through remapping tricks and next time there's a need
> for a new barrier we are left to figure it out by ourselves.
I don't get here, do you mean spec barriers? It's completely unnecessary
for vhost which is kernel thread. And even if you're right, vhost is not
the only place, there's lots of vmap() based accessing in kernel. Think
in another direction, this means we won't suffer form unnecessary
barriers for kthread like vhost in the future, we will manually pick the
one we really need (but it should have little possibility).
Please notice we only access metdata through remapping not the data
itself. This idea has been used for high speed userspace backend for
years, e.g packet socket or recent AF_XDP. The only difference is the
page was remap to from kernel to userspace.
> I don't
> like the idea I have to say. As a first step, why don't we switch to
> unsafe_put_user/unsafe_get_user etc?
Several reasons:
- They only have x86 variant, it won't have any difference for the rest
of architecture.
- unsafe_put_user/unsafe_get_user is not sufficient for accessing
structures (e.g accessing descriptor) or arrays (batching).
- Unless we can batch at least the accessing of two places in three of
avail, used and descriptor in one run. There will be no difference. E.g
we can batch updating used ring, but it won't make any difference in
this case.
> That would be more of an apples to apples comparison, would it not?
Apples to apples comparison only help if we are the No.1. But the fact
is we are not. If we want to compete with e.g dpdk or AF_XDP, vmap() is
the fastest method AFAIK.
Thanks
>
>
>> Test shows about 24% improvement on TX PPS. It should benefit other
>> cases as well.
>>
>> Please review
>>
>> Jason Wang (3):
>> vhost: generalize adding used elem
>> vhost: fine grain userspace memory accessors
>> vhost: access vq metadata through kernel virtual address
>>
>> drivers/vhost/vhost.c | 281 ++++++++++++++++++++++++++++++++++++++----
>> drivers/vhost/vhost.h | 11 ++
>> 2 files changed, 266 insertions(+), 26 deletions(-)
>>
>> --
>> 2.17.1
next prev parent reply other threads:[~2018-12-14 3:42 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 10:10 Jason Wang
2018-12-13 10:10 ` [PATCH net-next 1/3] vhost: generalize adding used elem Jason Wang
2018-12-13 19:41 ` Michael S. Tsirkin
2018-12-14 4:00 ` Jason Wang
2018-12-13 10:10 ` [PATCH net-next 2/3] vhost: fine grain userspace memory accessors Jason Wang
2018-12-13 10:10 ` [PATCH net-next 3/3] vhost: access vq metadata through kernel virtual address Jason Wang
2018-12-13 15:44 ` Michael S. Tsirkin
2018-12-13 21:18 ` Konrad Rzeszutek Wilk
2018-12-13 21:58 ` Michael S. Tsirkin
2018-12-14 3:57 ` Jason Wang
2018-12-14 12:36 ` Michael S. Tsirkin
2018-12-24 7:53 ` Jason Wang
2018-12-24 18:10 ` Michael S. Tsirkin
2018-12-25 10:05 ` Jason Wang
2018-12-25 12:50 ` Michael S. Tsirkin
2018-12-26 3:57 ` Jason Wang
2018-12-26 15:02 ` Michael S. Tsirkin
2018-12-27 9:39 ` Jason Wang
2018-12-30 18:30 ` Michael S. Tsirkin
2019-01-02 11:38 ` Jason Wang
2018-12-15 21:15 ` David Miller
2018-12-14 14:48 ` kbuild test robot
2018-12-13 15:27 ` [PATCH net-next 0/3] vhost: accelerate metadata access through vmap() Michael S. Tsirkin
2018-12-14 3:42 ` Jason Wang [this message]
2018-12-14 12:33 ` Michael S. Tsirkin
2018-12-14 15:31 ` Michael S. Tsirkin
2018-12-24 8:32 ` Jason Wang
2018-12-24 18:12 ` Michael S. Tsirkin
2018-12-25 10:09 ` Jason Wang
2018-12-25 12:52 ` Michael S. Tsirkin
2018-12-26 3:59 ` Jason Wang
2018-12-13 20:12 ` Michael S. Tsirkin
2018-12-14 4:29 ` Jason Wang
2018-12-14 12:52 ` Michael S. Tsirkin
2018-12-15 19:43 ` David Miller
2018-12-16 19:57 ` Michael S. Tsirkin
2018-12-24 8:44 ` Jason Wang
2018-12-24 19:09 ` Michael S. Tsirkin
2018-12-14 15:16 ` Michael S. Tsirkin
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=9459e227-a943-8553-732b-d7f5225a0f22@redhat.com \
--to=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.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
all inboxes | Powered by JetHome®