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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f8b6c6fe-2eef-3539-395f-694cfbdcc8a5@gmail.com>
Date:   Tue, 12 May 2020 14:11:45 -0600
From:   David Ahern <dsahern@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org,
        prashantbhole.linux@...il.com, jasowang@...hat.com,
        brouer@...hat.com, toke@...hat.com, toshiaki.makita1@...il.com,
        john.fastabend@...il.com, ast@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, andriin@...com,
        David Ahern <dahern@...italocean.com>
Subject: Re: [PATCH v4 bpf-next 09/15] net: Support xdp in the Tx path for
 packets as an skb

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.