netdev - Re: Tun congestion/BQL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Apr 2019 17:04:25 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     David Woodhouse <dwmw2@...radead.org>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        netdev@...r.kernel.org
Cc:     "Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: Tun congestion/BQL


On 2019/4/11 下午4:56, David Woodhouse wrote:
> On Thu, 2019-04-11 at 15:17 +0800, Jason Wang wrote:
>>>> 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).
>>> This is precisely what my first accidental if (!ptr_ring_empty())
>>> variant was doing, right? :)
>>
>> But I give a try on your ptr_ring_full() patch on VM, looks like it
>> works (single flow), no packets were dropped by TAP anymore. How many
>> flows did you use?
> Hm, I thought I was only using one. This is just a simple case of
> userspace opening /dev/net/tun, TUNSETIFF, and reading/writing.
>
> But if I was stopping the *wrong* queue that might explain things.


Btw, forget to mention, I modify your patch to use 
netif_stop/wake_subqueue() instead.

Thanks


>
> This is a persistent tun device.
>
>>>> 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...
>>> I was going to add BQL (as $SUBJECT may have caused you to infer) but
>>> trivially adding the netdev_sent_queue() in tun_net_xmit() and
>>> netdev_completed_queue() for xdp vs. skb in tun_do_read() was tripping
>>> the BUG in dql_completed().
>>
>> Something like https://lists.openwall.net/netdev/2012/11/12/6767 ?
> Fairly much.
>
> Except again I was being lazy for the proof-of-concept, ignoring 'txq'
> and just using netdev_sent_queue() etc.
>