[PATCH 1/2] eal: introduce x86 processor identification

[Bruce Richardson]

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.richardson at 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.marchand at 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