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

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 25 September 2023 12.16
> 
> 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@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@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

Please stop to think about this!

Nobody cares who manufactured the CPU. E.g. is it Cavium or Marvell... some vendors might have multiple series of CPUs with different features, e.g. from companies they have bought up.

What you are looking for are some sort of "capabilities" APIs, so you can query what the CPU offers. In this context, the CPU is just a device, like any other device. E.g. the ethdev has a bunch of "capabilities" APIs, where you can query for specific features, maximum number of queues, descriptors, and a lot more.