Re: [PATCH net-next v3] net: mana: Extend RX CQE coalescing up to 8 packets

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:

Pre-existing issues:
- [High] The RX NAPI polling function completely ignores the NAPI `budget`,=
 potentially processing up to 4096 packets in a single poll iteration, whic=
h causes severe latency spikes and violates NAPI fairness rules.
--

--- Patch [1]: [PATCH net-next v3] net: mana: Extend RX CQE coalescing up t=
o 8 packets ---
commit dbd47242aa242a736726a34fdaa26e55adbdfab1
Author: Haiyang Zhang <[email protected]>

net: mana: Extend RX CQE coalescing up to 8 packets

To support up to 8 packets per CQE, update related CQE processing code and
structures. This updates ethtool handlers to set this feature and per queue
stats to show the coalesced CQE counters.

> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/=
ethernet/microsoft/mana/mana_en.c
> index 2519a98ad00b0..3c96e6fc3d81d 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c

[ ... ]

> @@ -2304,54 +2354,48 @@ static void mana_process_rx_cqe(struct mana_rxq *=
rxq, struct mana_cq *cq,
>  		return;
>  	}
> =20
> +	pkt_i =3D 0;
>  	for (i =3D 0; i < MANA_RXCOMP_OOB_NUM_PPI; i++) {
> -		old_buf =3D NULL;
> -		pktlen =3D oob->ppi[i].pkt_len;
> -		if (pktlen =3D=3D 0)
> -			break;
> -
> -		curr =3D rxq->buf_index;
> -		rxbuf_oob =3D &rxq->rx_oobs[curr];
> -		WARN_ON_ONCE(rxbuf_oob->wqe_inf.wqe_size_in_bu !=3D 1);
> -
> -		if (unlikely(pktlen > rxq->datasize)) {
> -			/* Increase it even if mana_rx_skb() isn't called. */
> -			rxq->rx_cq.work_done++;
> +		u32 pkt_hash;
> =20
> -			++ndev->stats.rx_dropped;
> -			netdev_warn_once(ndev,
> -				"Dropped oversized RX packet: len=3D%u, datasize=3D%u\n",
> -				pktlen, rxq->datasize);
> -
> -			/* Reuse the RX buffer since rxbuf_oob is unchanged. */
> +		if (coalesced_8) {
> +			/* 8-pkt mode: 2 packets per PPI entry */
> +			pktlen =3D oob->ppi[i].pkt_len0;
> +			pkt_hash =3D oob->ppi[i].pkt_hash0;
>  		} else {
> -
> -			mana_refill_rx_oob(dev, rxq, rxbuf_oob, pktlen,
> -					   &old_buf, &old_fp);
> -
> -			/* Unsuccessful refill will have old_buf =3D=3D NULL.
> -			 * In this case, mana_rx_skb() will drop the packet.
> -			 */
> -			mana_rx_skb(old_buf, old_fp, oob, rxq, i);
> +			pktlen =3D oob->ppi[i].pkt_len;
> +			pkt_hash =3D oob->ppi[i].pkt_hash;
>  		}
> +		if (pktlen =3D=3D 0)
> +			break;
> =20
> -		mana_move_wq_tail(rxq->gdma_rq,
> -				  rxbuf_oob->wqe_inf.wqe_size_in_bu);
> -
> -		mana_post_pkt_rxq(rxq);
> +		mana_process_one_rx_pkt(dev, rxq, oob, pktlen, pkt_hash);
> +		pkt_i++;
> =20
>  		if (!coalesced)
>  			break;
> +
> +		/* Process 2nd packet from the same PPI in 8-pkt mode */
> +		if (coalesced_8) {
> +			pktlen =3D oob->ppi[i].pkt_len1;
> +			pkt_hash =3D oob->ppi[i].pkt_hash1;
> +			if (pktlen =3D=3D 0)
> +				break;
> +
> +			mana_process_one_rx_pkt(dev, rxq, oob, pktlen,
> +						pkt_hash);
> +			pkt_i++;
> +		}
>  	}

[Severity: High]
This is a pre-existing issue, but does extending coalescing to 8 packets per
CQE severely worsen an existing NAPI budget violation?

Looking at the caller mana_poll_rx_cq(), it pulls up to 512 CQEs from the
hardware and processes them all in a loop without checking the NAPI budget:

    comp_read =3D mana_gd_poll_cq(cq->gdma_cq, comp,
                    min((cq->gdma_cq->queue_size /
                          COMP_ENTRY_SIZE) * 4,
                         CQE_POLLING_BUFFER));
    ...
    for (i =3D 0; i < comp_read; i++) {
        ...
        mana_process_rx_cqe(rxq, cq, &comp[i]);
    }

Then in mana_poll(), the driver bounds the returned work done to the NAPI
budget, hiding the over-processing from the core network stack:

    w =3D mana_cq_handler(cq, cq->gdma_cq);

    return min(w, budget);

Since mana_process_rx_cqe() does not check if the packets processed exceed
the budget and can now process up to 8 packets per CQE, a single poll
iteration could process up to 4096 packets (8 packets * 512 CQEs) while
ignoring the budget.

Can this cause softirq starvation, latency jitter, or RCU stalls on busy
networks by blocking the CPU for long periods?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260805185404.1052=
[email protected]?part=3D1