Re: [PATCH v4 00/10] riscv: implement accelerated crc using zbc

[dangshiwei <1138222970gg@gmail.com>]

Hi Daniel,

I noticed that my recent patch [1] overlaps with your patch 01/10 -- both
modify rte_cpuflags.c and rte_cpuflags.h to add hwprobe-based Z
sub-extension detection.

The key differences are:

 * Scope: my patch adds infrastructure for all Z sub-extensions currently
   defined in Linux hwprobe.h; your patch 01/10 adds only ZBC as required
   by the CRC series.

 * Caching: my patch calls hwprobe once at EAL init via RTE_INIT and
   caches the result; your patch currently appears to call it on every
   invocation of rte_cpu_get_features().

 * FEAT_DEF semantics: my patch keeps the existing convention where the
   third argument is a bit index; your patch changes it to a mask value
   and updates rte_cpu_get_flag_enabled() accordingly. Mixing the two
   would produce silent incorrect results, so this needs to be resolved
   regardless of merge order.

 * Enum naming: I use RTE_CPUFLAG_RISCV_ZBC; you use
   RTE_CPUFLAG_RISCV_EXT_ZBC.

Regardless of which patch lands first, the other can be simplified:

 * If mine lands first, your patch 01/10 can drop the hwprobe
   infrastructure and keep only the meson build-time detection logic
   (RTE_RISCV_FEATURE_ZBC). Your CRC patches (02/10 onwards) would be
   unaffected in substance -- they would just reference
   RTE_CPUFLAG_RISCV_ZBC instead of RTE_CPUFLAG_RISCV_EXT_ZBC.

 * If yours lands first, I will rebase on top of it and align with your
   FEAT_DEF semantics and enum naming.

On naming: I prefer the flat style (RTE_CPUFLAG_RISCV_ZBC) since it is
consistent with the existing RTE_CPUFLAG_RISCV_ISA_* entries, but I will
follow whatever the maintainer decides.

I would be happy to coordinate on any of the above. Please let me know
your thoughts.

[1] https://patchwork.dpdk.org/patch/162581/

Best regards,
dangshiwei