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  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]
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.

Powered by blists - more mailing lists