Re: [PATCH net-next 1/3] net: busy-poll: introduce sk_tx_busy_loop()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] TX completions processed during sk_tx_busy_loop() incorrectly inflate the LINUX_MIB_BUSYPOLLRXPACKETS metric.
--

commit 0f753148fd82b1cf0ba3816b5e615f5e3039ba1b
Author: Menglong Dong <dongml2@chinatelecom.cn>

net: busy-poll: introduce sk_tx_busy_loop()

This commit introduces sk_tx_busy_loop() for NIC drivers that support TX
NAPI. It allows scheduling the TX NAPI, if available, instead of the RX
queue NAPI during busy polling.

> diff --git a/net/core/dev.c b/net/core/dev.c
> --- a/net/core/dev.c
> +++ b/net/core/dev.c

[ ... ]

> @@ -6951,6 +6946,9 @@ static void __napi_busy_loop(unsigned int napi_id,
>  	if (!napi)
>  		return;
>  
> +	if ((flags & NAPI_F_TX_NAPI) && napi->tx_napi)
> +		napi = napi->tx_napi;
> +

[Severity: Medium]
Will the returned work from the TX NAPI incorrectly inflate the
LINUX_MIB_BUSYPOLLRXPACKETS metric?

Further down in __napi_busy_loop(), the returned work is unconditionally
added to the RX-specific busy poll metric:

count:
        if (work > 0)
                __NET_ADD_STATS(dev_net(napi->dev),
                                LINUX_MIB_BUSYPOLLRXPACKETS, work);

If sk_tx_busy_loop() causes us to use the TX NAPI, does this mean TX
completions are now accounted as RX busy poll packets, potentially polluting
system monitoring statistics during TX-heavy busy polling workloads?

>  	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
>  		preempt_disable();
>  	for (;;) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611071242.2485058-1-dongml2@chinatelecom.cn?part=1