Re: [PATCH net] netpoll: bound the deferred transmit queue

On Wed, Sep 16, 2026 at 03:01:30AM -0700, Breno Leitao wrote:

My concern is some other netpoll users that do not check for return
value. Is this change going to affect them?

For instance, team doesn't even check the return value.

They only lose the accounting. bond, bridge, team, vlan, macvlan
and dsa reach netpoll_send_skb() only under netpoll_tx_running(),
when the upper device's xmit was itself entered from netpoll, so the
skb they hand down is always netconsole's, and it is consumed whether
sent, parked or dropped. The drop lands on the lower device's txq,
which is the queue that fills, so the bound holds for them too. What
none of them see is the drop itself, bond included: NET_XMIT_DROP
from the nested call is below NET_XMIT_MASK, so the outer
__netpoll_send_skb() reports a completed transmit and xmit_drop_count
never moves. The existing !npinfo / !netif_running() drops behave
the same way today, and netconsole never had a delivery promise to
lose (UDP, and netpoll_send_udp() already drops on pool exhaustion).

If a WARN is too heavy and it seems it might be, would a drop with
a reason be better than just dev_kfree_skb_irq() ?

      dev_kfree_skb_irq_reason(skb, SKB_DROP_REASON_FULL_RING);

Will do in v2, though it will rarely be seen:
dev_kfree_skb_irq_reason() defers the free to the completion queue,
and the next find_skb() on that CPU zaps it with __kfree_skb(), so
the reason seldom reaches the tracepoint. v2 therefore also does
dev_core_stats_tx_dropped_inc() on the device whose queue is full,
so the loss shows in its tx_dropped in the stacked case (tun pairs
the two the same way for its ring). I'd rather not WARN: the path
runs from the console being drained, and with a flood in progress
the splat is one more thing queued behind it.

Zack