Do we have alternative in Kepler to use a different method to measure CPU performance instead of using eBPF ?

[ramachandranravi]

We have been actively working with Telco partners on power optimization and power measuring requirements for their RAN and Core solutions in RHOCP. Kepler is recently introduced to one of our partner, although they liked what Kepler does and its capabilities they were reluctant using this in their environment due to their Infrastructure policies which doesn't allow any applications leveraging eBPF. So, are there any alternative solutions in road-map where power monitoring is possible without using eBPF for example., https://hubblo-org.github.io/scaphandre-documentation/explanations/how-scaph-computes-per-process-power-consumption.html?

[rootfs]

can you be more specific on why eBPF is not allowed?

[ramachandranravi]

We're yet to discuss and understand more specifics from the partner on why eBPF is a concern. But from the initial discussions we have had, it seems to be contradicting with their Cloud Infrastructure Requirements for 5GC applications that aim to prevent data leakage through eBPF. They stated "Extended Berkeley Packet Filters are tools or kernel programs that can intercept any action or data inside a workload. Avoid using extended Berkeley Packet Filters for storage writes, network interfaces, and used data to prevent data leakage". Hoping to provide more insights on this topic some time next week.

[rootfs]

"Avoid using extended Berkeley Packet Filters for storage writes, network interfaces, and used data to prevent data leakage"

Kepler eBPF does none of those :D

[ramachandranravi]

Thanks for your feedback, @rootfs
We'll share this info and snapshot of actual eBPF role with our partner and update here in case if they come up with any additional concerns or questions.

[rootfs]

I am comparing eBPF and /proc:

	Collect process stat using eBPF	Collect process stat from /proc
Security	Controllable: eBPF operates in kernel space and can be controlled with kernel policies.	Uncontrollable: as /proc provides broader access, once granted access, sensitive data may be exposed (eg. this security leak).
Performance	Efficient due to event-driven tracing, reducing overhead and minimizing system load.	Less efficient, requires frequent polling, which incurs overhead and can degrade performance.
Accuracy	High accuracy as it hooks directly into kernel sched_switch tracepoint, capturing real-time data.	Lower accuracy due to sampling intervals from polling, which may miss context switches between reads.

[ramachandranravi]

Useful insights. Thanks for sharing @rootfs