Re: Tun congestion/BQL

[Jason Wang <jasowang@redhat.com>]

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.
>