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
