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

[sashiko-bot@kernel.org]

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, which causes severe latency spikes and violates NAPI fairness rules.
--

--- Patch [1]: [PATCH net-next v3] net: mana: Extend RX CQE coalescing up to 8 packets ---
commit dbd47242aa242a736726a34fdaa26e55adbdfab1
Author: Haiyang Zhang <haiyangz@microsoft.com>

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;
>  	}
>  
> +	pkt_i = 0;
>  	for (i = 0; i < MANA_RXCOMP_OOB_NUM_PPI; i++) {
> -		old_buf = NULL;
> -		pktlen = oob->ppi[i].pkt_len;
> -		if (pktlen == 0)
> -			break;
> -
> -		curr = rxq->buf_index;
> -		rxbuf_oob = &rxq->rx_oobs[curr];
> -		WARN_ON_ONCE(rxbuf_oob->wqe_inf.wqe_size_in_bu != 1);
> -
> -		if (unlikely(pktlen > rxq->datasize)) {
> -			/* Increase it even if mana_rx_skb() isn't called. */
> -			rxq->rx_cq.work_done++;
> +		u32 pkt_hash;
>  
> -			++ndev->stats.rx_dropped;
> -			netdev_warn_once(ndev,
> -				"Dropped oversized RX packet: len=%u, datasize=%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 = oob->ppi[i].pkt_len0;
> +			pkt_hash = 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 == NULL.
> -			 * In this case, mana_rx_skb() will drop the packet.
> -			 */
> -			mana_rx_skb(old_buf, old_fp, oob, rxq, i);
> +			pktlen = oob->ppi[i].pkt_len;
> +			pkt_hash = oob->ppi[i].pkt_hash;
>  		}
> +		if (pktlen == 0)
> +			break;
>  
> -		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++;
>  
>  		if (!coalesced)
>  			break;
> +
> +		/* Process 2nd packet from the same PPI in 8-pkt mode */
> +		if (coalesced_8) {
> +			pktlen = oob->ppi[i].pkt_len1;
> +			pkt_hash = oob->ppi[i].pkt_hash1;
> +			if (pktlen == 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 = mana_gd_poll_cq(cq->gdma_cq, comp,
                    min((cq->gdma_cq->queue_size /
                          COMP_ENTRY_SIZE) * 4,
                         CQE_POLLING_BUFFER));
    ...
    for (i = 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 = 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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805185404.1052177-1-haiyangz@linux.microsoft.com?part=1