All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	caleb.raitto@gmail.com, "Michael S. Tsirkin" <mst@redhat.com>,
	"Jon Olson (Google Drive)" <jonolson@google.com>,
	Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net-next] virtio_net: ethtool tx napi configuration
Date: Wed, 12 Sep 2018 11:35:26 +0800	[thread overview]
Message-ID: <ab603c53-f7f8-5e89-a7c6-0050a97abe7b@redhat.com> (raw)
In-Reply-To: <CAF=yD-L=N8Ak9wxzvzgL5zsRQnngfzxS++o11bauS=6dXHaewQ@mail.gmail.com>



On 2018年09月11日 09:14, Willem de Bruijn wrote:
>>>> I cook a fixup, and it looks works in my setup:
>>>>
>>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>>> index b320b6b14749..9181c3f2f832 100644
>>>> --- a/drivers/net/virtio_net.c
>>>> +++ b/drivers/net/virtio_net.c
>>>> @@ -2204,10 +2204,17 @@ static int virtnet_set_coalesce(struct
>>>> net_device *dev,
>>>>                    return -EINVAL;
>>>>
>>>>            if (napi_weight ^ vi->sq[0].napi.weight) {
>>>> -               if (dev->flags & IFF_UP)
>>>> -                       return -EBUSY;
>>>> -               for (i = 0; i < vi->max_queue_pairs; i++)
>>>> +               for (i = 0; i < vi->max_queue_pairs; i++) {
>>>> +                       struct netdev_queue *txq =
>>>> +                              netdev_get_tx_queue(vi->dev, i);
>>>> +
>>>> + virtnet_napi_tx_disable(&vi->sq[i].napi);
>>>> +                       __netif_tx_lock_bh(txq);
>>>>                            vi->sq[i].napi.weight = napi_weight;
>>>> +                       __netif_tx_unlock_bh(txq);
>>>> +                       virtnet_napi_tx_enable(vi, vi->sq[i].vq,
>>>> + &vi->sq[i].napi);
>>>> +               }
>>>>            }
>>>>
>>>>            return 0;
>>> Thanks! It passes my simple stress test, too. Which consists of two
>>> concurrent loops, one toggling the ethtool option, another running
>>> TCP_RR.
>>>
>>>> The only left case is the speculative tx polling in RX NAPI. I think we
>>>> don't need to care in this case since it was not a must for correctness.
>>> As long as the txq lock is held that will be a noop, anyway. The other
>>> concurrent action is skb_xmit_done. It looks correct to me, but need
>>> to think about it a bit. The tricky transition is coming out of napi without
>>> having >= 2 + MAX_SKB_FRAGS clean descriptors. If the queue is
>>> stopped it may deadlock transmission in no-napi mode.
>> Yes, maybe we can enable tx queue when napi weight is zero in
>> virtnet_poll_tx().
> Yes, that precaution should resolve that edge case.
>

I've done a stress test and it passes. The test contains:

- vm with 2 queues
- a bash script to enable and disable tx napi
- two netperf UDP_STREAM sessions to send small packets

Thanks

  reply	other threads:[~2018-09-12  8:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-09 22:44 [PATCH net-next] virtio_net: ethtool tx napi configuration Willem de Bruijn
2018-09-10  6:01 ` Jason Wang
2018-09-10 13:35   ` Willem de Bruijn
2018-09-11  0:45     ` Jason Wang
2018-09-11  1:14       ` Willem de Bruijn
2018-09-12  3:35         ` Jason Wang [this message]
2018-09-12 13:43           ` Willem de Bruijn
2018-09-13  9:05             ` Jason Wang
2018-09-12 17:42 ` Florian Fainelli
2018-09-12 18:07   ` Willem de Bruijn
2018-09-12 18:16     ` Florian Fainelli
2018-09-12 19:11       ` Willem de Bruijn
2018-09-12 23:27         ` Willem de Bruijn
2018-09-13  9:02           ` Jason Wang
2018-09-13 14:58             ` Willem de Bruijn
2018-09-14  3:27               ` Jason Wang
2018-09-14  3:40                 ` Willem de Bruijn
2018-09-14  3:53                   ` Jason Wang
2018-09-14  4:46                     ` Willem de Bruijn
2018-09-14  8:08                       ` Jason Wang
2018-09-27  8:50                       ` Jason Wang
2018-09-27 13:53                         ` Willem de Bruijn
2018-09-27 23:39                           ` Jason Wang
2018-09-13  9:04         ` Jason 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=ab603c53-f7f8-5e89-a7c6-0050a97abe7b@redhat.com \
    --to=jasowang@redhat.com \
    --cc=caleb.raitto@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jonolson@google.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@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 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.