On Wed, Sep 24, 2025 at 04:30:45PM +0800, Jason Wang wrote: > On Wed, Sep 24, 2025 at 4:10 PM Michael S. Tsirkin <[email protected]> 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 <[email protected]> > > > 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 <[email protected]> > > > > > 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
userspace could supply that, thinkably. anyway, we can worry about that when we need that. -- MST
