RE: [PATCH v2 1/3] power: add uncore API to power library

["Kearney, Tadhg" <tadhg.kearney@intel.com>]

> -----Original Message-----
> From: Richardson, Bruce <bruce.richardson@intel.com>
*snip*
> > > +dpdk_conf.set('RTE_MAX_NUMA_DIE', 1)
> > > +dpdk_conf.set('RTE_MAX_UNCORE_FREQS', 32)
> >
> > Check if these flags should be added to other platforms.
> >
> 
> I think we need some explanation as to what these values are for, and how
> they should be set for various platforms.

Kernel does support sysfs uncore interface, as in below: 
"To control uncore frequency, a sysfs interface is provided in the directory: /sys/devices/system/cpu/intel_uncore_frequency/.
There is one directory for each package and die combination as the scope of uncore scaling control is per die in multiple die/package SoCs or per package for single die per package SoCs. The name represents the scope of control. For example: 'package_00_die_00' is for package id 0 and die 0." 

The macros 'RTE_MAX_NUMA_DIE' and 'RTE_MAX_UNCORE_FREQS' were first introduced as we needed to impose limits on cpu die number and how many uncore frequencies would be allowed for a system.

> Are they always these values, or

No, they differ from system to system.

> should they be determined programmatically at build time?

Retrieving information about die and number of uncore frequencies is not possible as we do not have a direct interface in Linux which would give this information.

With all this, better to remove these macros altogether from config path and instead figure out number of dies during run time, by iterating through package and die files from the sysfs file  'package_*_die_*',
  for systems that support sysfs uncore path. We would then give error with systems that do not contain sysfs uncore path.

Regards, Tadhg