Naming DBus paths of CPU objects

[Ren, Zhikui]

I am working on some CPU related properties. Please upload to Gerrit if you have some POC patch ready.

Thanks,
Zhikui

-----Original Message-----
From: openbmc <openbmc-bounces+zhikui.ren=intel.com at lists.ozlabs.org> On Behalf Of i.kononenko
Sent: Tuesday, September 22, 2020 3:35 AM
To: Ed Tanous <ed at tanous.net>
Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Re: Naming DBus paths of CPU objects

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