From: Toshiaki Makita <toshiaki.makita1@gmail.com>
To: Tonghao Zhang <xiangxia.m.yue@gmail.com>, makita.toshiaki@lab.ntt.co.jp
Cc: jasowang@redhat.com, mst@redhat.com,
virtualization@lists.linux-foundation.org,
Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
Date: Mon, 23 Jul 2018 23:20:54 +0900 [thread overview]
Message-ID: <2b0efbf4-09e2-0ee9-091f-e2d9e10483a1@gmail.com> (raw)
In-Reply-To: <CAMDZJNVPi8DMScyF2KW0mLAYe0p8uUVVY55Oo9Hk6SJJTMZYKg@mail.gmail.com>
On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
> On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>
>> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>
>>> Factor out generic busy polling logic and will be
>>> used for in tx path in the next patch. And with the patch,
>>> qemu can set differently the busyloop_timeout for rx queue.
>>>
>>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>> ---
>> ...
>>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
>>> + struct vhost_virtqueue *rvq,
>>> + struct vhost_virtqueue *tvq,
>>> + bool rx)
>>> +{
>>> + struct socket *sock = rvq->private_data;
>>> +
>>> + if (rx) {
>>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
>>> + vhost_poll_queue(&tvq->poll);
>>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
>>> + vhost_disable_notify(&net->dev, tvq);
>>> + vhost_poll_queue(&tvq->poll);
>>> + }
>>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
>>> + vhost_poll_queue(&rvq->poll);
>>
>> Now we wait for vq_avail for rx as well, I think you cannot skip
>> vhost_enable_notify() on tx. Probably you might want to do:
> I think vhost_enable_notify is needed.
>
>> } else if (sock && sk_has_rx_data(sock->sk)) {
>> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
>> vhost_poll_queue(&rvq->poll);
>> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
>> vhost_disable_notify(&net->dev, rvq);
>> vhost_poll_queue(&rvq->poll);
>> }
>> }
> As Jason review as before, we only want rx kick when packet is pending at
> socket but we're out of available buffers. So we just enable notify,
> but not poll it ?
>
> } else if ((sock && sk_has_rx_data(sock->sk)) &&
> !vhost_vq_avail_empty(&net->dev, rvq)) {
> vhost_poll_queue(&rvq->poll);
> else {
> vhost_enable_notify(&net->dev, rvq);
> }
When vhost_enable_notify() returns true the avail becomes non-empty
while we are enabling notify. We may delay the rx process if we don't
check the return value of vhost_enable_notify().
>> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
> I cant find why it is better, if necessary, we can do it.
The reason is pretty simple... we are busypolling the socket so we don't
need rx wakeups during it?
next prev parent reply other threads:[~2018-07-23 15:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-21 18:03 [PATCH net-next v6 0/4] net: vhost: improve performance when enable busyloop xiangxia.m.yue
2018-07-21 18:03 ` [PATCH net-next v6 1/4] net: vhost: lock the vqs one by one xiangxia.m.yue
2018-07-22 15:26 ` Michael S. Tsirkin
2018-07-25 12:05 ` Tonghao Zhang
2018-07-30 2:54 ` Jason Wang
2018-07-21 18:04 ` [PATCH net-next v6 2/4] net: vhost: replace magic number of lock annotation xiangxia.m.yue
2018-07-21 18:04 ` [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll() xiangxia.m.yue
2018-07-23 9:57 ` Toshiaki Makita
2018-07-23 12:43 ` Tonghao Zhang
2018-07-23 14:20 ` Toshiaki Makita [this message]
2018-07-23 17:31 ` Tonghao Zhang
2018-07-24 2:53 ` Toshiaki Makita
2018-07-24 3:28 ` Tonghao Zhang
2018-07-24 3:41 ` Toshiaki Makita
2018-07-30 3:16 ` Jason Wang
2018-07-21 18:04 ` [PATCH net-next v6 4/4] net: vhost: add rx busy polling in tx path xiangxia.m.yue
2018-07-25 20:01 ` [PATCH net-next v6 0/4] net: vhost: improve performance when enable busyloop David Miller
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=2b0efbf4-09e2-0ee9-091f-e2d9e10483a1@gmail.com \
--to=toshiaki.makita1@gmail.com \
--cc=jasowang@redhat.com \
--cc=makita.toshiaki@lab.ntt.co.jp \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=xiangxia.m.yue@gmail.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).