> From: Stephen Hemminger [mailto:[email protected]] > Sent: Sunday, 22 February 2026 19.03 > > On Sun, 22 Feb 2026 16:29:54 +0100 > Daniel Gregory <[email protected]> wrote: > > > The RISC-V Zbc extension adds instructions for carry-less > multiplication > > we can use to implement CRC in hardware. This patch set contains two > new > > implementations: > > > > - one in lib/hash/rte_crc_riscv64.h that uses a Barrett reduction to > > implement the four rte_hash_crc_* functions > > - one in lib/net/net_crc_zbc.c that uses repeated single-folds to > reduce > > the buffer until it is small enough for a Barrett reduction to > > implement rte_crc16_ccitt_zbc_handler and rte_crc32_eth_zbc_handler > > > > AI patch review summary: the overall approach looks good — the hwprobe > integration is clean and the Barrett reduction math appears correct. > A few issues need addressing before this can be merged: > > 1. [ERROR, patch 01] 1 << n used for all 26 HWCAP mask entries > > The feature table entries now store masks in a uint64_t field, but > all 26 existing RISCV_ISA_* entries still use plain '1 << n' (signed > int). This produces 32-bit values stored in a 64-bit field and > causes > undefined behaviour for n >= 31. All entries must use UINT64_C(1) << > n: > > FEAT_DEF(RISCV_ISA_A, REG_HWCAP, UINT64_C(1) << 0) > ... > FEAT_DEF(RISCV_ISA_Z, REG_HWCAP, UINT64_C(1) << 25)
Furthermore, RTE_BIT64(25) [1] is preferred over UINT64_C(1) << 25. [1]: https://elixir.bootlin.com/dpdk/v25.11/source/lib/eal/include/rte_bitops.h#L36 It seems the AI missed this preference.
