On 10/05, Toke H�iland-J�rgensen wrote:
Stanislav Fomichev <sdf@xxxxxxxxxx> writes:
> On Tue, Oct 4, 2022 at 5:59 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>>
>> On Tue, 4 Oct 2022 17:25:51 -0700 Martin KaFai Lau wrote:
>> > A intentionally wild question, what does it take for the driver
to return the
>> > hints. Is the rx_desc and rx_queue enough? When the xdp prog is
calling a
>> > kfunc/bpf-helper, like 'hwtstamp = bpf_xdp_get_hwtstamp()', can
the driver
>> > replace it with some inline bpf code (like how the inline code is
generated for
>> > the map_lookup helper). The xdp prog can then store the hwstamp
in the meta
>> > area in any layout it wants.
>>
>> Since you mentioned it... FWIW that was always my preference rather
than
>> the BTF magic :) The jited image would have to be per-driver like we
>> do for BPF offload but that's easy to do from the technical
>> perspective (I doubt many deployments bind the same prog to multiple
>> HW devices)..
>
> +1, sounds like a good alternative (got your reply while typing)
> I'm not too versed in the rx_desc/rx_queue area, but seems like worst
> case that bpf_xdp_get_hwtstamp can probably receive a xdp_md ctx and
> parse it out from the pre-populated metadata?
>
> Btw, do we also need to think about the redirect case? What happens
> when I redirect one frame from a device A with one metadata format to
> a device B with another?
Yes, we absolutely do! In fact, to me this (redirects) is the main
reason why we need the ID in the packet in the first place: when running
on (say) a veth, an XDP program needs to be able to deal with packets
from multiple physical NICs.
As far as API is concerned, my hope was that we could solve this with a
CO-RE like approach where the program author just writes something like:
hw_tstamp = bpf_get_xdp_hint("hw_tstamp", u64);
and bpf_get_xdp_hint() is really a macro (or a special kind of
relocation?) and libbpf would do the following on load:
- query the kernel BTF for all possible xdp_hint structs
- figure out which of them have an 'u64 hw_tstamp' member
- generate the necessary conditionals / jump table to disambiguate on
the BTF_ID in the packet
Now, if this is better done by a kfunc I'm not terribly opposed to that
either, but I'm not sure it's actually better/easier to do in the kernel
than in libbpf at load time?
Replied in the other thread, but to reiterate here: then btf_id in the
metadata has to stay and we either pre-generate those bpf_get_xdp_hint()
at libbpf or at kfunc load time level as you mention.
But the program essentially has to handle all possible hints' btf ids
thrown
at it by the system. Not sure about the performance in this case :-/
Maybe that's something that can be hidden behind "I might receive forwarded
packets and I know how to handle all metadata format" flag? By default,
we'll pre-generate parsing only for that specific device?
