Naming DBus paths of CPU objects

[i.kononenko]

Ed, hello
Some time ago I opened discussion about naming of CPU dbus-objects and way to couple of its.
But, my bad, I was missing your answer. So sorry, I'd kindly ask to start discussion again

Bellow are my thoughts about this.

On 01.09.2020 02:39, Ed Tanous wrote:
> On Mon, Aug 31, 2020 at 10:55 AM i.kononenko <i.kononenko at yadro.com> wrote:
>>
>> Hi,
>>
>> I'm working on improving of the OpenBMC RedFISH API. In particular, the endpoint of the Processor.
>> To provide all the properties of the applied RedFISH schema, we need to get from
>> DBus everything related to the CPU object.
>> It can be CPU, Sensor CPU temp, Sensors Core CPU, etc.
> 
> 
> I'm a little confused.  The Processor schema doesn't have a Thermal
> property (did they add one?) so CPU temperatures and core temps would
> need to go under an equivalent Assembly or Chassis.  I think today for
> some platforms they're added under the baseboard, which isn't
> "correct" but is close enough.  Can you talk a little more about what
> you're wanting to accomplish in your improvements?  What would the end
> result look like?

Yes, the Processor schema doesn't have Thermal property, but let's looks to implementation of CPUSensors.
It's be more precise explanation of what I want to accomplish.

The CPUSensors takes the DBus configuration object which is defined at the EntityManager.
This object impls the `xyz.openbmc_project.Configuration.XeonCPU` and `xyz.openbmc_project.Inventory.Item`.
The last one adjust `Present` and `PrettyName` properties. So, known that at least, we can adjust Processor's 
schema fields "Status": "Healf" And "State". 

Moreover, the CPUSensors using data of `xyz.openbmc_project.Configuration.XeonCPU` retrieve the sensors target values from `hwmon`
and define cpu-core dbus objects, in particular. Each one cpu-core object also want have `Present` property. Having this information about
each Core of CPU we can adjust field "TotalEnabledCores".
Summary, if this objects will be couple then we can present the Processor state information at a first approximation.

At next time, when all specific CPU information will be taken from a 3d-party place (e.g. smbios-mdrv2) we would want adds this to the exists CPU item.
For that might been happen we must define way to couple all dbus-object about the same thing physical processor. 
(EM-configuration, CPUSensors-each-sensors, CPUSensor-healf-object, Smbios_mdrv2-manufacturer-data, e.g.)

I'd suggest to do this with object-mapper's associations. I have patch set and I can push it to gerrit,
if anybody interested of the purposes described above.

Thanks!

> 
>>
>>
>> However, some services have different names for the same physical processor.
>> In particular it is about `entity-manager`, `dbus-sensros`, `smbios-mdr_v2`.
>> `Smbios-mdr_v2` (just like `hwmon`) names the processor, indexing
>> it from 0; in `entity-manager` and `dbus-sensor` indexing starts from 1.
>>
>> I want to add dbus-associations between all Processor's object,
>> but for that I think we need to adopt a naming convention for the same DBus objects.
> 
> 
> Can you talk about why you need this?  Keep in mind, there are lots of
> systems that have processors on add in cards, or separate
> accelerators.  Making the statement "all" makes me think you're
> wanting to make a blanket association from system->processor, which
> I'm not sure we can do as a generalization without breaking those use
> cases (which admittedly aren't modeled very well today).  I would hope
> we don't need to rely on a common naming convention to do it.
> 
>>
>>
>> I like to index it from 0, just like doing that the `hwmon`, for example.
> 
> 
> I completely agree that we should standardize the naming convention
> where we can, the only problem here is that the overarching goal is
> that we match the silkscreen mask on the board, some of which zero
> index, some of which one index.  With that said, I know that a lot of
> the existing configs don't currently match the silkscreen.
> smbios-mdr_v2 to my understanding should be using 1 indexing.
> 
>>
>>
>> --
>> Best Regards!
>> Igor Kononenko

-- 
best,

Igor Kononenko