On Fri, Sep 22, 2023 at 12:40 PM Bruce Richardson <bruce.richard...@intel.com> wrote: > > On Fri, Sep 22, 2023 at 11:37:20AM +0200, David Marchand wrote: > > In some really specific cases, it may be needed to get a detailed > > information on the processor running a DPDK application for drivers to > > achieve better performance, or for matters that concern only them. > > > > Those information are highly arch-specific and require a specific API. > > > > Introduce a set of functions to get brand, family and model of a x86 > > processor. > > Those functions do not make sense on other arches and a > > driver must first check rte_cpu_is_x86() before anything else. > > > > Signed-off-by: David Marchand <david.march...@redhat.com> > > --- > > Couple of thoughts, having had a few minutes to process this. > > * Rather than rte_cpu_is_x86() API, we could go a general API called > rte_cpu_arch() which returns either a string, or an enum value. Within > that, rather than #ifdefs, the actual return value could just be a define > placed by meson in the rte_build_config.h file. The list of families > according to meson are [1] - we'd just need to merge the 32 and 64-bit > variants into one in the meson file.
Your proposal (in next mail) lgtm. > > * Similarly rather than having is_intel or is_amd functions, we could > generalize to a "manufacturer" API, which could be applicable for other > architectures too. Like a rte_cpu_x86_manufacturer() ? which returns an enum too I suppose. -- David Marchand
