phosphor-pid-control: dbus tuning interface
Ed Tanous
ed at tanous.net
Thu Jul 9 16:20:52 AEST 2020
On Wed, Jul 8, 2020 at 11:03 AM Jason Ling <jasonling at google.com> wrote:
>>
>>
>> This capability already exists if you're using phosphor-pid-control
>>
>> with entity manager
>>
>> ..
>>
>> Entity manager essentially will trigger a reconfigure of
>> phosphor-pid-control on every change, so new parameters can be tested.
>
>
> I see. Let me make sure my mental model is correct.
> You can modify PID configuration parameters published by entity-manager via dbus (is this a separate dbus path/interface than the pid-configuration interface?).
Yes, to the first part, no to the second. Because entity manager
configurations can change over time, at runtime, the dbus config
interface is expected to change, so entity manager is simply
simulating as if you had unplugged the hardware, then replugged in a
nearly identical device, with the parameters changed.
> Entity-manager detects the property change/method call and then updates its pid-configuration on dbus.
> phosphor-pid-control is listening on a signal/event and then essentially restarts itself and picks up the new configuration?
You have that exactly right.
>
>>
>> I'm guessing you didn't know that existed, and clearly Patrick didn't
>> either. So the next question is, where did you go to look for this
>> kind of thing (ie, where should we document this)? There might not be
>> a perfect place, but hopefully we can make this more clear in the
>> future when people have these needs.
>
>
> I sure didn't, thanks for pointing this out. As far as documentation improvements:
> How to configure phosphor-pid-control should probably mention something about the capability of configuring phosphor-pid-control via dbus.
The reason we didn't put it there is that phosphor-pid-control isn't
really the one doing the configuration change, it's entity manager,
but I suspect we could add a pointer to "If you're trying to modify
parameters at runtime, look at this doc in entity manager/main docs
repo". Now that I type that, it might be worth an architecture doc
in the main docs repo as well. There's a lot of machinery going on
under the hood there that was under-documented (my fault for that).
> As far as dbus pid-tuning goes, I suppose there should be some mention of it in https://github.com/openbmc/phosphor-pid-control/blob/master/tuning.md .. I guess something along the lines of "...dbus configuration changes will be reflected in the operation of phosphor-pid-control.".
> Intentionally left a bit vague because it doesn't HAVE to be entity-manager providing this configuration interface. It could be some other service that reads a config.json and publishes this information to dbus...
> Which brings me to my next question
> "Is the PID configuration interface formally defined as part of phosphor-dbus-interfaces?"
That is an excellent point, and is probably a miss on our part. I
imagine that would be a good place to start in getting them
documented.
>
>
> Thanks for the brain-dump Ed, it's making me rethink my approach. Adding yet another tuning interface has a clear potential to bloat and over complicate phosphor-pid-control. It seems like even if a system was using phosphor-hwmon for sensor telemetry monitoring, you could still use entity-manager just to publish and modify PID configurations.
>
Today, phosphor-hwmon doesn't have compatibility with the Entity
Manager config data structures. When we looked last, it was a pretty
major effort to support it, as it somewhat conflicts with the way it
was built originally. Nothing against phosphor-hwmon, it does what it
was built to do, but runtime modification wasn't really it.
More information about the openbmc
mailing list