netdev - Re: [RFC PATCH v2 bpf-next 00/15] xdp

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 31 Oct 2019 09:32:51 +0900
From:   Toshiaki Makita <toshiaki.makita1@...il.com>
To:     David Miller <davem@...emloft.net>, toke@...hat.com
Cc:     john.fastabend@...il.com, ast@...nel.org, daniel@...earbox.net,
        kafai@...com, songliubraving@...com, yhs@...com,
        jakub.kicinski@...ronome.com, hawk@...nel.org, jhs@...atatu.com,
        xiyou.wangcong@...il.com, jiri@...nulli.us, pablo@...filter.org,
        kadlec@...filter.org, fw@...len.de, pshelar@....org,
        netdev@...r.kernel.org, bpf@...r.kernel.org, u9012063@...il.com,
        sdf@...ichev.me
Subject: Re: [RFC PATCH v2 bpf-next 00/15] xdp_flow: Flow offload to XDP

On 2019/10/28 4:17, David Miller wrote:
> From: Toke Høiland-Jørgensen <toke@...hat.com>
> Date: Sun, 27 Oct 2019 16:24:24 +0100
> 
>> The results in the paper also shows somewhat disappointing performance
>> for the eBPF implementation, but that is not too surprising given that
>> it's implemented as a TC eBPF hook, not an XDP program. I seem to recall
>> that this was also one of the things puzzling to me back when this was
>> presented...
> 
> Also, no attempt was made to dyanamically optimize the data structures
> and code generated in response to features actually used.
> 
> That's the big error.
> 
> The full OVS key is huge, OVS is really quite a monster.
> 
> But people don't use the entire key, nor do they use the totality of
> the data paths.
> 
> So just doing a 1-to-1 translation of the OVS datapath into BPF makes
> absolutely no sense whatsoever and it is guaranteed to have worse
> performance.

Agree that 1-to-1 translation would result in worse performance.
What I'm doing now is just supporting subset of keys, only very basic ones.
This does not accelerate all usages so dynamic program generation certainly
has value. What is difficult is that basically flow insertion is triggered
by datapath packet reception and it causes latency spike. Going through
bpf verifier on each new flow packet reception on datapath does not look
feasible so we need to come up with something to avoid this.

Toshiaki Makita