Re: [PATCH v4 bpf-next 09/15] net: Support xdp in the Tx path for packets as an skb

[David Ahern <dsahern@gmail.com>]

On 4/29/20 6:17 PM, David Ahern wrote:
>> Overall, for the regular stack, I expect the performance of XDP egress
>> to be
>> worse than e.g. tc egress, for example, when TSO is disabled but not GSO
>> then
>> you parse the same packet multiple times given post-GSO whereas with tc
>> egress
>> it would operate just fine on a GSO skb. Plus all the limitations
>> generic XDP
>> has with skb_cloned(skb), skb_is_nonlinear(skb), etc, where we need to
>> linearize
>> so calling it 'XDP egress' might lead to false assumptions. Did you do a
>> comparison
>> on that as well?
> 

After another round of staring at the code and running various tests, I
will concede the skb path for a few reasons:

1. all appropriate hooks for running an XDP egress program on skbs are
very close to the same point where the tc hook is,

2. the changes needed to handle xdp programs on skbs combined with the
performance impacts those changes bring (e.g., cloned skb, nonlinear skb
disabling GSO, etc), and

3. xdp programs and cls-bpf programs can share data (ie., maps) and
program can be similar enough that the overhead of 2 programs with
separate attach points is reasonable (e.g., I was able to adapt a
firewall so that it works for both paths and the only difference is
setting data and data_end based on context).

What that means is that an xdp_egress program would only apply to
xdp_frames redirected from another interface.