DPL: disable cpu_usage_fraction for proxies

[ktf]

DPL: disable cpu_usage_fraction for proxies

[github-actions[bot]]

REQUEST FOR PRODUCTION RELEASES: To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available async-2023-pbpb-apass async-2023-pp-apass1 async-2022-pp-apass6 async-2022-pp-apass4 async-mc async-data

[alibuild]

Error while checking build/O2/fullCI for c1c8ce9a5bd4b0df46def50546c8ee4ba49956a3 at 2024-04-03 06:45:

## sw/BUILD/O2-latest/log
c++: error: unrecognized command-line option '--rtlib=compiler-rt'
c++: error: unrecognized command-line option '--rtlib=compiler-rt'

Full log here.

[davidrohr]

@ktf : I had a closer look, and I really don't like using the name for such things. Particularly, since the name is user-defined for the proxies. This will:

• not work if the user uses capital letter in the "Proxy" name.
• not work if the user creates a proxy that is not called proxy.
• accidentally affect devices that have "proxy" in their name.

I think we should use some kind of flag / label mechanism for such purposes. I know that DPL already supports labels somehow. Could we make it such, that the ExternalFairMQDevice proxy sets a label "input-proxy", and we check for that label?

Alternatively, as a simple solution we could add a bitmask to DeviceSpec, ExternalFairMQDeviceProxy could set a bit when the spec is created, and then this can be checked instead of DeviceSpec.name.

Whatever you prefer, but I'd prefer to go directly with a proper solution, not with such a hack.

That said, in DPL there are many places where we do string comparison with the devicespec name, which I don't like. Perhaps we should generally transition that to a flag/label mechanism. I'll open a JIRA for this.

[ktf]

We actually have labels which we could use, which we can require to fully match. I am happy to go that way, instead, but we need to agree on what the label is ("input-proxy"?).

[davidrohr]

For me it is fine to use "input-proxy". Although, I have to say, I would actually prefer to have a bitmask for dpl-internal properties / labels, like "dpl-internal", "input-proxy", "output-proxy", "dummy-sink", "ccdb-backend", to avoid the string compares needed for matching the labels. Then we can switch also the existing string compares we have for these cases to just checking the bitmask. I would use labels for user-defined stuff. But this is just my opinion...

[ktf]

yes, we can use the bitmask/ enum at the DeviceSpec level, however at the dataprocessorspec level i would prefer to use the labels in order to avoid some extra json handling for the enums (dataprocessorspecs need to be json serialised).

[ktf]

On a second look, on this specific case, we do not need the enum. The check is done on init and what it does is to enable / disable the metric, so there is no string comparison while in Running. I will expose a bitmask with the proxy / whatever information in the DataProcessingContext, but it does not need to be done in this particular PR.

[alibuild]

Error while checking build/O2/fullCI for 56aa6f555f5f0a59c2fd665e9ee0f173f452fae0 at 2024-04-24 13:59:

## sw/BUILD/O2-latest/log
c++: error: unrecognized command-line option '--rtlib=compiler-rt'
c++: error: unrecognized command-line option '--rtlib=compiler-rt'

Full log here.