On Wed, Sep 24, 2025 at 4:10 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Wed, Sep 24, 2025 at 04:08:33PM +0800, Jason Wang wrote: > > On Wed, Sep 24, 2025 at 3:42 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > > > On Wed, Sep 24, 2025 at 03:33:08PM +0800, Jason Wang wrote: > > > > On Wed, Sep 24, 2025 at 3:18 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > > > > > > > On Tue, Sep 23, 2025 at 12:15:45AM +0200, Simon Schippers wrote: > > > > > > This patch series deals with TUN, TAP and vhost_net which drop incoming > > > > > > SKBs whenever their internal ptr_ring buffer is full. Instead, with this > > > > > > patch series, the associated netdev queue is stopped before this happens. > > > > > > This allows the connected qdisc to function correctly as reported by [1] > > > > > > and improves application-layer performance, see our paper [2]. Meanwhile > > > > > > the theoretical performance differs only slightly: > > > > > > > > > > > > > > > About this whole approach. > > > > > What if userspace is not consuming packets? > > > > > Won't the watchdog warnings appear? > > > > > Is it safe to allow userspace to block a tx queue > > > > > indefinitely? > > > > > > > > I think it's safe as it's a userspace device, there's no way to > > > > guarantee the userspace can process the packet in time (so no watchdog > > > > for TUN). > > > > > > > > Thanks > > > > > > Hmm. Anyway, I guess if we ever want to enable timeout for tun, > > > we can worry about it then. > > > > The problem is that the skb is freed until userspace calls recvmsg(), > > so it would be tricky to implement a watchdog. (Or if we can do, we > > can do BQL as well). > > I thought the watchdog generally watches queues not individual skbs? Yes, but only if ndo_tx_timeout is implemented. I mean it would be tricky if we want to implement ndo_tx_timeout since we can't choose a good timeout. Thanks