Mapping standard D-Bus sensors to ProcessorMetrics (and other specific schemas)

[Patrick Williams]

On Tue, Apr 27, 2021 at 01:52:51PM +0200, Ambrozewicz, Adrian wrote:
> W dniu 4/9/2021 o 14:05, Patrick Williams pisze:
> > On Wed, Apr 07, 2021 at 02:24:55PM +0200, Ambrozewicz, Adrian wrote:
> > 
> > I suspect this would be the more difficult direction to go down.  There
> > is already enough code that looks for sensors at specific paths that
> > you'd have to track down and fix up.  Also, there has been some concern
> > by some maintainers in other cases about having information in the paths
> > have meaning and prefering to reduce the reliance on that.
> > 
> 
> Please see message from Ed, as he's supposedly proposing to follow that 
> path. I don't have strong opinions on one or the other approach.

I suspect you are not signing up to change all the existing code.  I'll
look at Ed's reply though.

> I've read the design, however one thing is not clear for me. My current 
> understanding was that for each association there would need to exist 
> some D-bus object at given path somewhere. Would i need my CPU inventory 
> service to also expose separate objects for each core for my association 
> to be 'legal', or could we represent some virtual hierarchy with no 
> actual D-Bus object in the system?

Yes.  You would need an inventory object for each entity you want to
attach sensors or metrics to.  This doesn't seem like it should really
be an issue.  Other people have been working on adding CPU Cores already
and there is the xyz.openbmc_project.Inventory.Item.CpuCore defined.

> >> I've done some PoC implementation of ProcessorMetrics, which relies on
> >> new D-Bus interface with 'Mapping' property (eg. 'TemperatureCelsius' or
> >> 'CoreMetrics/12/UnhaltedCycles'). ProcessorMetrics node implementation
> >> queries D-Bus for all sensors associated with given CPU and populates
> >> properties if proper mapping was found.
> > 
> > I'm not really grasping what the contents of this mapping property are.
> > Generally we want to stay away from free-form strings having programatic
> > uses.  Maybe if you can define these mappings as enumerations?
> > 
> > What is the additional information you need besides the assocation from
> > a sensor to its inventory item?
> 
> In given example I would like my sensor to be source of information for 
> property defined by ProcessorMetrics schema. In the example I've used 
> property associated with given Core, thus CoreMetrics/12/UnhaltedCycles 
> maps directly to ProcessorMetrics sub-property. Enumerations could be 
> not enough as we have multiple informations to represent:
> - association with given processor (done by ProcessorMetrics)
> - association with given core (could that be handled by your proposed 
> design?)
> - linking to given property
> 
> Would the enumeration be used for the last element, while leaving 
> hierarchy problem to Associations?

"UnhaltedCycles" is not a sensor, just to be clear.  IPMI might have
called these kinds of things sensors but we do not.  Sensors for us
measure physical properties.  This is just a property (or maybe a
"metric") but it doesn't belong in the sensors namespace or modeled with
a Sensor.Value.

I don't know why the "linking to a given property" would be a dbus
representation.  Metric service should know which properties from dbus
map to some metric entity, right?  For a one-user piece of information,
I don't see a good reason to put this on dbus.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210511/9c2eeafa/attachment.sig>