On Mon, Sep 25, 2023 at 11:46:00AM +0200, David Marchand wrote: > 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. > I was actually thinking a more general "rte_cpu_manufacturer()" which returns string, and therefore could be implemented by all architectures. Could default to NULL or string "unknown" if not implemented.
/Bruce
