Re: [PATCH net 1/2] lib/dim: fix 32-bit overflow in dim_calc_stats() rates

[Leon Romanovsky <leon@kernel.org>]

On Sun, Sep 27, 2026 at 10:47:42AM +0530, Shashank Mohan Jain wrote:
> dim_calc_stats() computes the per-millisecond rates as
> 
> 	DIV_ROUND_UP(nbytes * USEC_PER_MSEC, delta_us)
> 
> where nbytes is a u32 and USEC_PER_MSEC is 1000L. On 64-bit the product
> is done in 64-bit long arithmetic, but on 32-bit architectures long is
> 32 bits wide and the product wraps as soon as a measurement window
> carries more than 4294967 bytes (about 4.3 MB). The same applies to the
> packet and completion counts, although those need more than 4.29
> million packets or completions per window.
> 
> A DIM window spans DIM_NEVENTS (64) events. Drivers count events per
> interrupt or per NAPI poll, so under sustained load a window can easily
> carry more than 4.3 MB: 64 full NAPI polls of 64 MTU-sized frames are
> already 6.2 MB, and drivers such as mtk_eth_soc count one event per
> interrupt while NAPI keeps polling with the interrupt masked. On 32-bit
> users of the library (for example mtk_eth_soc on MT7621, bcmgenet and
> bcmsysport on 32-bit ARM, or virtio_net in a 32-bit guest) bpms then
> becomes the product modulo 2^32 divided by the window length, and
> net_dim_stats_compare() makes its BETTER/WORSE decisions on a value
> that has little to do with the real throughput.
> 
> For example, a 1 Gbit/s link at line rate that moves 5 MB in a 40 ms
> window gives bpms = 125000 on 64-bit but 17626 on 32-bit, and 5 million
> packets in 2 s gives ppms = 353 instead of 2500.
> 
> Widen the products to 64 bits and divide with DIV_ROUND_UP_ULL(). The
> results are unchanged on 64-bit.

How does this 32-bit overflow differ from the overflow that can also occur on
64-bit systems in `nbytes * USEC_PER_MSEC`?

Thanks