Zero init xdp_hints_rx_time, which means xdp_hints_rx_time.btf_type_id
is zero if setup_btf_info() didn't find the struct name.
In print_meta_info_via_btf() we also exit if btf_id is zero, as
this isn't a valid BTF type id.
Thus, we don't need to explicitly handle "error" case of a btf_type_id
being zero, it will just naturally not match when userspace could not
find the struct name.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
The 'struct xdp_hints_rx_time' exist both in kernel-side (af_xdp_kern.c)
and userspace program af_xdp_user.c, but are very different.
The kernel-side is the actual XDP-hints memory layout used in metadata area.
The userspace side uses the same struct name, but contains BTF info
that allow us to access the struct members from kernel-side struct.
The BTF info is extracted on userspace startup, from the BPF-prog
ELF data BTF section.
Caching BTF lookups at startup is done, as target application
is a real-time application.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Add a large comments to the most central piece of code that
access the right offset into the metadata based on the BTF
info we have extracted.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
With the current xsk_btf__read() we are seeing a slowdown on the
first packet with timestamps. The theory is this is caused
by the allocation for the cached hashmap entry.
meta-time rx_ktime:870394156129518 time_now:870394156139039 diff:9521 ns
meta-time rx_ktime:870396208293894 time_now:870396208295098 diff:1204 ns
meta-time rx_ktime:870398256286553 time_now:870398256287772 diff:1219 ns
Create a new API that can access struct members more directly
via caching the xsk_btf_member offset + size in the C-code API user.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Based on:
Subj: libbpf: Helpers to access XDP hints based on BTF definitions
https://lore.kernel.org/all/20210803010331.39453-15-ederson.desouza@intel.com/
From: Ederson de Souza <ederson.desouza@intel.com>
Ederson says:
A new set of functions to help get the BTF definition of XDP hints
structure and get the information based on it.
`xsk_umem__btf_id` helps retrieve the BTF id of XDP metadata.
`xsk_btf__init` sets up a context based on the BTF, including a hashmap,
so that subsequent queries are faster.
`xsk_btf__read` returns a pointer to the position in the XDP metadata
containing a given field.
`xsk_btf__has_field` checks the presence of a field in the BTF.
`xsk_btf__free` frees up the context.
Besides those, a macro `XSK_BTF_READ_INTO` acts as a convenient helper
to read the field contents into a given variable.
Note that currently, the hashmap used to speed-up offset location into
the BTF doesn't use the field name as a string as key to the hashmap. It
directly uses the pointer value instead, as it is expected that most of
time, field names will be addressed by a shared constant string residing
on read-only memory, thus saving some time. If this assumption is not
entirely true, this optimisation needs to be rethought (or discarded
altogether).
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
