On Tue, 2020-08-18 at 11:19 -0700, Alexei Starovoitov wrote:
> On Tue, Aug 18, 2020 at 8:49 AM Jakub Sitnicki wrote:
> > : rcu_read_lock();
> > : run_array =
> > rcu_dereference(net->bpf.run_array[NETNS_BPF_SK_LOOKUP]);
> > 0.01 :
On Fri, Aug 21, 2020 at 12:18 AM CEST, Alexei Starovoitov wrote:
> On Thu, Aug 20, 2020 at 3:29 AM Jakub Sitnicki wrote:
>> On Tue, Aug 18, 2020 at 08:19 PM CEST, Alexei Starovoitov wrote:
[...]
>> > Long term we should probably stop doing *_kern style of ctx passing
>> > into bpf progs.
>> > We
On Thu, Aug 20, 2020 at 3:29 AM Jakub Sitnicki wrote:
>
> On Tue, Aug 18, 2020 at 08:19 PM CEST, Alexei Starovoitov wrote:
> > On Tue, Aug 18, 2020 at 8:49 AM Jakub Sitnicki wrote:
> >> : rcu_read_lock();
> >> : run_array =
> >> rcu_der
From: Jakub Sitnicki
> Sent: 20 August 2020 11:30
> Subject: Re: BPF sk_lookup v5 - TCP SYN and UDP 0-len flood benchmarks
>
> On Tue, Aug 18, 2020 at 08:19 PM CEST, Alexei Starovoitov wrote:
> > On Tue, Aug 18, 2020 at 8:49 AM Jak
On Tue, Aug 18, 2020 at 08:19 PM CEST, Alexei Starovoitov wrote:
> On Tue, Aug 18, 2020 at 8:49 AM Jakub Sitnicki wrote:
>> : rcu_read_lock();
>> : run_array =
>> rcu_dereference(net->bpf.run_array[NETNS_BPF_SK_LOOKUP]);
>> 0.01 :
On Tue, Aug 18, 2020 at 8:49 AM Jakub Sitnicki wrote:
> : rcu_read_lock();
> : run_array =
> rcu_dereference(net->bpf.run_array[NETNS_BPF_SK_LOOKUP]);
> 0.01 : 817f8624: mov0xd68(%r12),%rsi
> :
I got around to re-running flood benchmarks. Mainly to confirm that
introduction of static key had the desired effect - users not attaching
BPF sk_lookup programs won't notice a performance hit in Linux v5.9.
But also to check for any unexpected bottlenecks when BPF sk_lookup
program is attached,
