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.
