Naming DBus paths of CPU objects

Naming DBus paths of CPU objects

[i.kononenko]

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.

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.

I like to index it from 0, just like doing that the `hwmon`, for example.

-- 
Best Regards!
Igor Kononenko

Re: Naming DBus paths of CPU objects

[Ed Tanous]

On Mon, Aug 31, 2020 at 10:55 AM i.kononenko <i.kononenko@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?

>
>
> 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

Re: 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@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

RE: 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@lists.ozlabs.org> On Behalf Of i.kononenko
Sent: Tuesday, September 22, 2020 3:35 AM
To: Ed Tanous <ed@tanous.net>
Cc: OpenBMC Maillist <openbmc@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@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

Re: Naming DBus paths of CPU objects

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

On Tue, Sep 22, 2020 at 01:35:26PM +0300, i.kononenko wrote:

> 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`

Is it possible we could start to get some of these interfaces defined in 
phosphor-dbus-interfaces?  There has been some work lately under
Inventory to contain some of the CPU and Thermal properties you
mentioned.

If something really is Xeon specific, I'd prefer we use com.intel.'s
namespace rather than xyz.openbmc_project.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Naming DBus paths of CPU objects

[i.kononenko]

Hi Team,

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.

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 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.

I like to index it from 0, just like doing that the `hwmon`, for example.

-- 
Best Regards!
Igor Kononenko