Re: [PATCH net-next v4 11/13] net: lan966x: add PCIe FDMA XDP support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] NAPI poll loop exits prematurely on SKB allocation failure or FDMA error, causing permanent RX queue stalls.
--

commit 2fc7864e7fb714463211e299fb04e9b91f05d012
Author: Daniel Machon <daniel.machon@microchip.com>

net: lan966x: add PCIe FDMA XDP support

This commit adds XDP support for the PCIe FDMA path. The implementation
operates on contiguous ATU-mapped buffers with memcpy-based XDP_TX, unlike
the platform path which uses page_pool.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> index 0568251a95d92..cf3d3afbcc8a4 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c

[ ... ]

> @@ -282,14 +392,26 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
>  		/* Order DONE read before DCB/frame reads below. */
>  		dma_rmb();
>  		counter++;
> -		switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> +		switch (lan966x_fdma_pci_rx_check_frame(rx,
> +							&src_port,
> +							&data,
> +							&data_len)) {
>  		case FDMA_PASS:
>  			break;
>  		case FDMA_ERROR:
>  			fdma_dcb_advance(fdma);
>  			goto allocate_new;

This existing code jumps to allocate_new when encountering an error. If there
are still frames pending in the hardware queue, could breaking out of the loop
early leave NAPI completed while the hardware has already generated an
interrupt for the remaining frames?

Since the driver's interrupt handler has likely already cleared the interrupt
status bit, and hardware might only set it on new frame completion, could
this lead to a permanent RX queue stall if the queue is completely full?

> +		case FDMA_TX:
> +			fdma_dcb_advance(fdma);
> +			continue;
> +		case FDMA_DROP:
> +			fdma_dcb_advance(fdma);
> +			continue;

Since these new XDP actions use continue, should FDMA_ERROR be updated
to drop the packet and continue as well, rather than aborting the poll loop?

>  		}
> -		skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
> +		skb = lan966x_fdma_pci_rx_get_frame(rx,
> +						    src_port,
> +						    data,
> +						    data_len);
>  		fdma_dcb_advance(fdma);
>  		if (!skb)
>  			goto allocate_new;

Similarly, if SKB allocation fails here, could jumping to allocate_new
abandon remaining pending frames and cause the same RX queue stall?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260508-lan966x-pci-fdma-v4-0-14e0c89d8d63@microchip.com?part=11