From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Jason Wang <jasowang@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
netdev@vger.kernel.org
Subject: Re: Tun congestion/BQL
Date: Wed, 10 Apr 2019 15:42:56 +0200 [thread overview]
Message-ID: <87ftqqugbj.fsf@toke.dk> (raw)
In-Reply-To: <8c64c80d-165c-076b-fca3-5374edc87853@redhat.com>
Jason Wang <jasowang@redhat.com> writes:
> On 2019/4/10 下午9:01, David Woodhouse wrote:
>> On Wed, 2019-04-10 at 15:01 +0300, David Woodhouse wrote:
>>> --- a/drivers/net/tun.c
>>> +++ b/drivers/net/tun.c
>>> @@ -1125,7 +1128,9 @@ static netdev_tx_t tun_net_xmit(struct sk_buff
>>> *skb, struct net_device *dev)
>>> if (tfile->flags & TUN_FASYNC)
>>> kill_fasync(&tfile->fasync, SIGIO, POLL_IN);
>>> tfile->socket.sk->sk_data_ready(tfile->socket.sk);
>>>
>>> + if (!ptr_ring_empty(&tfile->tx_ring))
>>> + netif_stop_queue(tun->dev);
>>> rcu_read_unlock();
>>> return NETDEV_TX_OK;
>>>
>>>
>> Hm, that should be using ptr_ring_full() shouldn't it? So...
>>
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1121,6 +1121,9 @@ static netdev_tx_t tun_net_xmit(struct s
>> if (ptr_ring_produce(&tfile->tx_ring, skb))
>> goto drop;
>>
>> + if (ptr_ring_full(&tfile->tx_ring))
>> + netif_stop_queue(tun->dev);
>> +
>> /* Notify and wake up reader process */
>> if (tfile->flags & TUN_FASYNC)
>> kill_fasync(&tfile->fasync, SIGIO, POLL_IN);
>> @@ -2229,6 +2232,7 @@ static ssize_t tun_do_read(struct tun_st
>> consume_skb(skb);
>> }
>>
>> + netif_wake_queue(tun->dev);
>> return ret;
>> }
>>
>>
>> That doesn't seem to make much difference at all; it's still dropping a
>> lot of packets because ptr_ring_produce() is returning non-zero.
>
>
> I think you need try to stop the queue just in this case? Ideally we may
> want to stop the queue when the queue is about to full, but we don't
> have such helper currently.
Ideally we want to react when the queue starts building rather than when
it starts getting full; by pushing back on upper layers (or, if
forwarding, dropping packets to signal congestion).
In practice, this means tuning the TX ring to the *minimum* size it can
be without starving (this is basically what BQL does for Ethernet), and
keeping packets queued in the qdisc layer instead, where it can be
managed...
-Toke
next prev parent reply other threads:[~2019-04-10 13:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 12:01 Tun congestion/BQL David Woodhouse
2019-04-10 13:01 ` David Woodhouse
2019-04-10 13:25 ` Jason Wang
2019-04-10 13:42 ` Toke Høiland-Jørgensen [this message]
2019-04-10 14:33 ` David Woodhouse
2019-04-10 15:01 ` Toke Høiland-Jørgensen
2019-04-10 15:32 ` David Woodhouse
2019-04-11 7:22 ` Jason Wang
2019-04-11 9:25 ` David Woodhouse
2019-04-12 4:26 ` Jason Wang
2019-04-12 5:45 ` David Woodhouse
2019-04-11 7:17 ` Jason Wang
2019-04-11 8:56 ` David Woodhouse
2019-04-11 9:04 ` Jason Wang
2019-04-11 9:16 ` David Woodhouse
2019-04-12 4:23 ` Jason Wang
2019-04-11 7:01 ` 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=87ftqqugbj.fsf@toke.dk \
--to=toke@redhat.com \
--cc=dwmw2@infradead.org \
--cc=jasowang@redhat.com \
--cc=netdev@vger.kernel.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.