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 <[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; > } > > + 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/[email protected]?part=1
