On 10/4/22 7:15 PM, Stanislav Fomichev wrote:
On Tue, Oct 4, 2022 at 6:24 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
On Tue, 4 Oct 2022 18:02:56 -0700 Stanislav Fomichev wrote:
+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?
I'd think so, worst case the driver can put xdp_md into a struct
and container_of() to get to its own stack with whatever fields
it needs.
Ack, seems like something worth exploring then.
The only issue I see with that is that we'd probably have to extend
the loading api to pass target xdp device so we can pre-generate
per-device bytecode for those kfuncs?
There is an existing attr->prog_ifindex for dev offload purpose. May be we can
re-purpose/re-use some of the offload API. How this kfunc can be presented also
needs some thoughts, could be a new ndo_xxx.... not sure.
And this potentially will block attaching the same program
> to different drivers/devices?
Or, Martin, did you maybe have something better in mind?
If the kfunc/helper is inline, then it will have to be per device. Unless the
bpf prog chooses not to inline which could be an option but I am also not sure
how often the user wants to 'attach' a loaded xdp prog to a different device.
To some extend, the CO-RE hints-loading-code will have to be per device also, no?
Why I asked the kfunc/helper approach is because, from the set, it seems the
hints has already been available at the driver. The specific knowledge that the
xdp prog missing is how to get the hints from the rx_desc/rx_queue. The
straight forward way to me is to make them (rx_desc/rx_queue) available to xdp
prog and have kfunc/helper to extract the hints from them only if the xdp prog
needs it. The xdp prog can selectively get what hints it needs and then
optionally store them into the meta area in any layout.
NETIF_F_XDP_HINTS_BIT probably won't be needed and one less thing to worry in
production.
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?
If there is a program on Tx then it'd be trivial - just do the
info <-> descriptor translation in the opposite direction than Rx.
+1
TBH I'm not sure how it'd be done in the current approach, either.
Yeah, I think we need more selftest to show how things work.
Yeah, I don't think it magically works in any case. I'm just trying to
understand whether it's something we care to support out of the box or
can punt to the bpf programs themselves and say "if you care about
forwarding metadata, somehow agree on the format yourself".
Now I questioned the BTF way and mentioned the Tx-side program in
a single thread, I better stop talking...
Forget about btf, hail to the new king - kfunc :-D
