|SUCCESS| net/ixgbe: fix queue received bytes CRC adjustment

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163589

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-06

Commit: c03fcee9abbd ("ixgbe: remove CRC size from byte counters")
Author: Daniil Iskhakov <dish at amicon.ru>
Subject: [PATCH] net/ixgbe: fix queue received bytes CRC adjustment

This patch fixes an integer overflow in the CRC adjustment calculation
for the QBRC (queue bytes received counter) in the ixgbe driver when CRC
stripping is disabled.

> diff --git a/drivers/net/intel/ixgbe/ixgbe_ethdev.c b/drivers/net/intel/ixgbe/ixgbe_ethdev.c
> index 57d929cf2c..c17ce70810 100644
> --- a/drivers/net/intel/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/intel/ixgbe/ixgbe_ethdev.c
> @@ -3237,7 +3237,7 @@ ixgbe_read_stats_registers(struct ixgbe_hw *hw,
>  		hw_stats->qbrc[i] +=
>  		    ((uint64_t)IXGBE_READ_REG(hw, IXGBE_QBRC_H(i)) << 32);
>  		if (crc_strip == 0)
> -			hw_stats->qbrc[i] -= delta_qprc * RTE_ETHER_CRC_LEN;
> +			hw_stats->qbrc[i] -= (uint64_t)delta_qprc * RTE_ETHER_CRC_LEN;

The fix looks correct. The multiplication delta_qprc * RTE_ETHER_CRC_LEN
performs 32-bit arithmetic since delta_qprc is uint32_t. When delta_qprc
approaches UINT32_MAX (e.g., 4294967295 packets * 4 CRC bytes), the
result wraps in 32 bits before being subtracted from the 64-bit counter.
The cast ensures the multiplication happens in 64-bit arithmetic.

However, does ixgbe_read_stats_registers() have consistent integer
width handling throughout? Looking at the surrounding context:

In the same function, the code reads both low and high registers for
QBRC and combines them into a 64-bit value. The QPRC counter (packet
count) is 32-bit as you noted. The type of delta_qprc should be
verified - is it declared as uint32_t? If it's already uint64_t
elsewhere, this cast would be unnecessary (though harmless).

Also, are there other similar patterns in this function that might have
the same overflow issue? For instance, do any other counter adjustments
multiply 32-bit deltas by constants before subtracting from 64-bit
accumulators?

The patch correctly addresses the overflow issue identified by static
analysis.