Re: [v4,net-next,06/15] net: fec: add fec_enet_rx_queue_xdp() for XDP path

[Jakub Kicinski <kuba@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: fec: add fec_enet_rx_queue_xdp() for XDP path

This commit separates XDP path packet processing from protocol stack
packet processing by adding a new fec_enet_rx_queue_xdp() function.
The goal is to optimize XDP path logic and improve XDP performance.

> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index 0529dc91c981..86447a7cb963 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c

[ ... ]

> +static int fec_enet_rx_queue_xdp(struct fec_enet_private *fep, int queue,
> +				 int budget, struct bpf_prog *prog)
> +{

[ ... ]

> +		switch (act) {
> +		case XDP_PASS:
> +			rxq->stats[RX_XDP_PASS]++;
> +			/* The packet length includes FCS, but we don't want to
> +			 * include that when passing upstream as it messes up
> +			 * bridging applications.
> +			 */
> +			skb = fec_build_skb(fep, rxq, bdp, page, pkt_len);
> +			if (!skb) {
> +				fec_xdp_drop(rxq, &xdp, sync);
> +				trace_xdp_exception(ndev, prog, XDP_PASS);
> +			} else {
> +				napi_gro_receive(&fep->napi, skb);
> +			}
> +			break;

On platforms with FEC_QUIRK_SWAP_FRAME (like i.MX28), the old code path
would call swap_buffer() after XDP_PASS before building the skb. In the
old fec_enet_rx_queue(), the flow was:

    fec_enet_run_xdp() returns FEC_ENET_XDP_PASS
    -> if (ret != FEC_ENET_XDP_PASS) goto done; // continues
    -> if (need_swap) swap_buffer(data, pkt_len);
    -> fec_build_skb()

With this change, XDP_PASS goes directly to fec_build_skb() without
calling swap_buffer(). Does this break XDP_PASS on i.MX28 where the DMA
delivers data in wrong byte order? On such platforms, packets passed to
the network stack would have incorrect byte order, causing protocol
parsing failures.

The commit message says "XDP path does not support swap_buffer()" but the
previous code did support it for XDP_PASS - the swap happened after the
XDP program returned PASS but before the packet was handed to the stack.
-- 
pw-bot: cr