Re: [PATCH net-next v7 10/14] net: lan966x: add PCIe FDMA support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] net: lan966x: rx_bytes statistic undercounts received frame size
--

commit 33bf15bc7637a43a47c2a31af68430d11cdb1f96
Author: Daniel Machon <daniel.machon@microchip.com>

    net: lan966x: add PCIe FDMA support
    
    Add PCIe FDMA support for lan966x. The PCIe FDMA path uses contiguous
    DMA buffers mapped through the endpoint's ATU, with memcpy-based frame
    transfer instead of per-page DMA mappings.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> new file mode 100644
> index 0000000000000..5d6902459f200
> --- /dev/null
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
[ ... ]
> +static struct sk_buff *lan966x_fdma_pci_rx_get_frame(struct lan966x_rx *rx,
> +						     u64 src_port)
> +{
[ ... ]
> +	skb->protocol = eth_type_trans(skb, skb->dev);
> +
> +	if (lan966x->bridge_mask & BIT(src_port)) {
> +		skb->offload_fwd_mark = 1;
> +
> +		skb_reset_network_header(skb);
> +		if (!lan966x_hw_offload(lan966x, src_port, skb))
> +			skb->offload_fwd_mark = 0;
> +	}
> +
> +	skb->dev->stats.rx_bytes += skb->len;

[Severity: Medium]
Does this regression undercount the received frame size for the rx_bytes
statistic?

In lan966x_fdma_pci_rx_get_frame(), eth_type_trans() inherently pulls the
Ethernet header from the SKB, reducing skb->len. Additionally, if
lan966x_hw_offload() optionally calls skb_vlan_untag(), it further reduces
the length.

Adding this modified, smaller skb->len to the rx_bytes counter instead of
the original wire length causes the statistic to systematically undercount
received bytes by at least 14 bytes (the MAC header size) per packet, and
potentially more if VLAN tags are present.

Although this pattern may have been copied from the existing non-PCI path,
it is a newly introduced instance in this file. A check of the subsequent
patches in this series reveals the problem remains unfixed in the final state
of the series (commit f075590a2768b1e0f139412f8b14c4b61658552e).

Could the original length be recorded for the statistic before the headers
are pulled?

> +	skb->dev->stats.rx_packets++;
> +
> +	return skb;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c@microchip.com?part=10