On 2/2/24 15:37, Eelco Chaudron wrote:
On 2 Feb 2024, at 15:16, Aaron Conole wrote:
<SNIP>
+ OVS_USDT_PROBE(revalidate, flow_result, reason, udpif, ukey);
I have been experimenting with several upcall tracking techniques
that would make it easier to correlate upcalls with their subsequent
related events.
To achieve that, we need (among other things) some easy-to-compare
unique value in the events. For revalidation events, I think a good
candidate would be "ukey->ufid" and so does the script in this patch.
However, requiring all external tools to know the layout of "struct
udpif_key" in order to get that value makes things quite complicated
for CORE tools (e.g: retis).
With all this, would you consider adding the ufid to probe payload directly?
Dont see why we can not, but if we need anything else it would quickly
explode in too much arguments. I guess CORE needs a good solution for
userspace.
I think having the ufid and udpif makes sense for now. Actually, maybe
for the long term we can do something as an appctl command which will
dump the relevant datastructures. That way a tool like this, which
needs the pid anyway, can generate an appctl command against the daemon
and get the exact right header layout.
WDYT?
I think we discussed this in the past, but I can’t remember what the arguments
against this approach were. Adrian, can you remember?
We explored a generic approach using pahole to extract the layout of the running
daemon, generate a BTF file and use with libbpf to do _actual_ CORE, but at the
time pahole was missing some support for dwz-compressed files (such as the ones
in debug packages).
The process would then be:
- 1. (build time) Generate a header (also using pahole?) that we can use to
compile against
- 2. (build time) Build an ebpf program
- 3. (run-time) Get the OVS debuginfo (using debuginfod?)
- 4. (run-time) Build a BTF file from the debuginfo
- 5. (run-time) Pass that BTF file to libbpf and let it do CORE relocation as
normal
I'll check again if pahole limitations still persist.
--
Adrián Moreno
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
