> -----Original Message-----
> From: Richardson, Bruce <bruce.richard...@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
