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

[Breno Leitao <leitao@debian.org>]

On Tue, Sep 15, 2026 at 12:45:00PM -0400, Zack Gomez wrote:
> On Mon, Sep 14, 2026 at 01:47:39AM -0700, Breno Leitao wrote:
>
> Seems to work as advertised: with the link healthy the target sends
> exactly the configured rate and nothing is parked. 

Good to hear it.

> > I think the rate limiting should live on the netconsole side, not
> > netpoll.
> 
> I'd still argue the netpoll change is required: there should not be
> a path to OOMing the box. The rate limit is opt-in, and even once
> set it OOMs the same way if the limit is above what the link is
> draining at that moment, which above is 8k/s under the pause and
> 200k/s without it. The two rows at 20k/s are the same configuration
> on a good day and a bad day.
> 
> I read the two as solving different problems. Yours is consumer
> side: it limits how much damage one machine can do to a listener.
> The netpoll cap is producer side: it keeps the sender from damaging
> itself. Both seem worth having.

Yes, I agree.

> > If we do end up also rate limiting at the netpoll side, I'd like to
> > see a WARN_ON_ONCE() here, since it shouldn't be the main ratelimit
> > path, but rather something to flag that something is off.
> 
> No strong opinion on that; I'll defer to the maintainers. The drop
> is counted either way: netconsole sees NET_XMIT_DROP in
> xmit_drop_count and exposes it as transmit_errors.

I am not worried about netconsole here, it copes with the drop fine.

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.

	static inline void team_netpoll_send_skb(struct team_port *port,
						struct sk_buff *skb)
	{
		netpoll_send_skb(port->np, skb);
	}

One way or another, I am in favor of adding it, but, with more
extra information about this drop.

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); 


Thanks,
--breno