On 5/18/20 4:44 PM, David Ahern wrote:
On 5/18/20 3:08 AM, Toke Høiland-Jørgensen wrote:
I can see your point that fixing up the whole skb after the program has
run is not a good idea. But to me that just indicates that the hook is
in the wrong place: that it really should be in the driver, executed at
a point where the skb data structure is no longer necessary (similar to
how the ingress hook is before the skb is generated).
Have you created a cls_bpf program to modify skbs? Have you looked at
the helpers, the restrictions and the tight management of skb changes?
Have you followed the skb from create to device handoff through the
drivers? Have you looked at the history of encapsulations, gso handling,
offloads, ...? I have and it drove home that the skb path and xdp paths
are radically different. XDP is meant to be light and fast, and trying
to cram an skb down the xdp path is a dead end.
Agree, it's already challenging in itself to abstract the skb internals and
protocol specifics away for tc BPF programs while keeping them reasonably
fast (e.g. not destroying skb GSO specifics, etc). Good example is the whole
bpf_skb_adjust_room() flags mess. :/ The buffer would have to be an XDP
one straight from socket layer and stay that way as an xdp-buff down to the
driver, not the other way around where you'd pay the price of back'n'forth
conversion to xdp-buff and then passing it to the driver while handling/
fixing up all the skb details after the BPF prog was run. AF_XDP's xmit would
be more suited for something like that.
Thanks,
Daniel
