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

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.

quoted

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.

quoted

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