All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Network Development <netdev@vger.kernel.org>,
	Willem de Bruijn <willemb@google.com>,
	virtualization@lists.linux-foundation.org,
	David Miller <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH net-next v2 2/5] virtio-net: transmit napi
Date: Thu, 20 Apr 2017 12:02:45 -0400	[thread overview]
Message-ID: <CAF=yD-KzHo1jVugrZKq_CmyrsqCR1zmM4Jo12OjacreKm74P8w__35832.2072578177$1493077087$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <9f57a790-9157-db4d-621d-cf359c8f0718@redhat.com>

>>   static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
>>   {
>>         struct virtio_net_hdr_mrg_rxbuf *hdr;
>> @@ -1130,9 +1172,11 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
>> struct net_device *dev)
>>         int err;
>>         struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
>>         bool kick = !skb->xmit_more;
>> +       bool use_napi = sq->napi.weight;
>>         /* Free up any pending old buffers before queueing new ones. */
>> -       free_old_xmit_skbs(sq);
>> +       if (!use_napi)
>> +               free_old_xmit_skbs(sq);
>
>
> I'm not sure this is best or even correct. Consider we clean xmit packets
> speculatively in virtnet_poll_tx(), we need call free_old_xmit_skbs()
> unconditionally. This can also help to reduce the possible of napi
> rescheduling in virtnet_poll_tx().

Because of the use of trylock there. Absolutely, thanks! Perhaps I should
only use trylock in the opportunistic clean path from the rx softirq and
full locking in the tx softirq.

I previously observed that cleaning here would, counterintuitively,
reduce efficiency. It reverted the improvements of cleaning transmit
completions from the receive softirq. Going through my data, I did
not observe this regression anymore on the latest patchset.

Let me test again, with and without the new
virtqueue_enable_cb_delayed patch. Perhaps that made a
difference.

  parent reply	other threads:[~2017-04-20 16:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18 20:21 [PATCH net-next v2 0/5] virtio-net tx napi Willem de Bruijn
2017-04-18 20:21 ` [PATCH net-next v2 1/5] virtio-net: napi helper functions Willem de Bruijn
2017-04-18 20:21 ` Willem de Bruijn
2017-04-18 20:21 ` [PATCH net-next v2 2/5] virtio-net: transmit napi Willem de Bruijn
2017-04-18 20:21 ` Willem de Bruijn
2017-04-20  6:12   ` Jason Wang
2017-04-20  6:12   ` Jason Wang
2017-04-20 16:02     ` Willem de Bruijn
2017-04-21 18:10       ` Willem de Bruijn
2017-04-21 18:10       ` Willem de Bruijn
2017-04-20 16:02     ` Willem de Bruijn [this message]
2017-04-20  6:27   ` Jason Wang
2017-04-20 13:58     ` Willem de Bruijn
2017-04-20 13:58     ` Willem de Bruijn
2017-04-21  3:53       ` Jason Wang
2017-04-21 14:50         ` Willem de Bruijn
2017-04-24 16:40           ` Michael S. Tsirkin
2017-04-24 17:05             ` Willem de Bruijn
2017-04-24 17:14               ` Michael S. Tsirkin
2017-04-24 17:51                 ` Willem de Bruijn
2017-04-24 17:51                 ` Willem de Bruijn
2017-04-24 17:05             ` Willem de Bruijn
2017-04-25  8:39             ` Jason Wang
2017-04-21 14:50         ` Willem de Bruijn
2017-04-18 20:21 ` [PATCH net-next v2 3/5] virtio-net: move free_old_xmit_skbs Willem de Bruijn
2017-04-18 20:21 ` Willem de Bruijn
2017-04-18 20:21 ` [PATCH net-next v2 4/5] virtio-net: clean tx descriptors from rx napi Willem de Bruijn
2017-04-18 20:21 ` Willem de Bruijn
2017-04-18 20:21 ` [PATCH net-next v2 5/5] virtio-net: keep tx interrupts disabled unless kick Willem de Bruijn
2017-04-18 20:21 ` Willem de Bruijn
2017-04-20  6:17   ` Jason Wang
2017-04-20 14:03     ` Willem de Bruijn
2017-04-21 23:13       ` Willem de Bruijn
2017-04-21 23:13       ` Willem de Bruijn
2017-04-20 14:03     ` Willem de Bruijn

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='CAF=yD-KzHo1jVugrZKq_CmyrsqCR1zmM4Jo12OjacreKm74P8w__35832.2072578177$1493077087$gmane$org@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willemb@google.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.