|
|
Post by ropai on Jun 13, 2022 10:04:41 GMT
Dear Community,
I am trying to model some PLDM type 2 state sensors (Enumeration type) in redfish. There is no RDE support in the MC.
Does redfish have some general recommendation to model the state sensors ?
Example - there is a CPU throttle state sensor which could take possible values of 1,2 and 3.
thanks for the support
Rohit PAI
|
|
|
|
Post by mraineri on Jun 13, 2022 13:23:35 GMT
Something like a "state" would be better modeled as an enumeration in Redfish. "Sensor" is a bit overloaded (especially when coming from an IPMI background), and Redfish really limits the sensor model to encompass numeric readings. For your use case, something similar to what we show for a property like "Health" is more appropriate where the values of the property are limited to well-known strings. So, you would need to translate the values 1, 2, and 3 to human readable strings.
|
|
|
|
Post by ropai on Jun 13, 2022 16:13:37 GMT
Just to provide more context, The CPU sensor provides below information in the form of PLDM type 2 state sensor From pldm spec > Performance The performance of any type of entity. 1 – Normal The entity is operating at a full functional level at full speed. 2 – Throttled The entity is operating at a full functional level at reduced speed. 3 – Degraded The entity is operating at a degraded functional level. Similarly there are other state sensors from the same specification www.dmtf.org/sites/default/files/standards/documents/DSP0249_1.0.0.pdfSince these values are coming from standard pldm spec, should we push them under OEM schema or can we try for some standard Redfish schema definitions ? thanks |
|
|
|
Post by mraineri on Jun 13, 2022 16:38:21 GMT
At this time we do not have a standard location in the data model to directly convey throttle information. I can see some of this affecting the "Health" property of a resource (maybe it's important to set the health to "Warning" under any sort of throttling condition for a particular product).
However, I can see this as something we should discuss further. It might be important to have one or more properties to directly tie to throttling status.
|
|
|
|
Post by ropai on Jun 17, 2022 15:55:11 GMT
So we could define a new property called 'PerformanceState' which could be of type Enum and may have following different values.
Performance The performance of any type of entity.
1 – Normal : The entity is operating at a full functional level at full speed.
2 – Throttled : The entity is operating at a full functional level at reduced speed.
3 – Degraded : The entity is operating at a degraded functional level.
CPU1
\-- PerformanceState : Throttled
The above property can be added to the Processor schema. What is your suggestion ?
A CPU resource could have 8 cores and each core will have a throttle state. So may be it would have be represented as collection type.
The other way I am thinking would be to model a generic state sensor schema (either new property addition to existing sensor schema or new schema all together)
the state sensor could have properties like
- state value - The enumeration value
- state type - What type value the sensor represents
- state context
- etc
Then we could have these state sensor instances linked under the resource for which they belong.
Example
CPU
\--- StateSensor1
\--- type : performance
\--- value : Throttled
\--- context : general
|
|
|
|
Post by mraineri on Jun 17, 2022 18:07:14 GMT
I think a property like "PerformanceState" would make sense to be part of the Processor schema. There's nothing in the standard for this today, so it would need to be an OEM property until we can agree on the property. One thing specifically about throttle state is that enum list is very likely to be much larger depending on the CPU architecture, so we'll need input from different CPU vendors to ensure the semantics are consistent. Specifically for multi-core processors, each Processor resource can have its own "SubProcessors" collection, and each core on the CPU is modeled as a Processor within that collection with its own "PerformanceState" property.
Using generic "Sensor" modeling I don't think would be a good option; we've been avoiding calling states like this "sensors" since they really are just single property values with no additional metadata around the reading (no units, ranges, thresholds, etc).
|
|
