linux-kernel - Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

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]

Message-ID: <52FE4C0C.1090008@redhat.com>
Date:	Fri, 14 Feb 2014 18:02:04 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Alexei Starovoitov <ast@...mgrid.com>
CC:	Ingo Molnar <mingo@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Tom Zanussi <tom.zanussi@...ux.intel.com>,
	Jovi Zhangwei <jovi.zhangwei@...il.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Pekka Enberg <penberg@....fi>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
...
>> I'm very curious, do you also have any performance numbers, e.g. for
>> networking by taking JIT'ed/non-JIT'ed BPF filters and compare them against
>> JIT'ed/non-JIT'ed eBPF filters to see how many pps we gain or loose e.g.
>> for a scenario with a middle box running cls_bpf .. or some other macro/
>> micro benchmark just to get a picture where both stand in terms of
>> performance? Who knows, maybe it would outperform nftables engine as
>> well? ;-) How would that look on a 32bit arch with eBPF that is 64bit?
>
> I don't have jited/non-jited numbers, but I suspect for micro-benchmarks
> the gap should be big. I was shooting for near native performance after JIT.

Ohh, I meant it would be interesting to see a comparison of e.g. common libpcap
high-level filters that are in 32bit BPF + JIT (current code) vs 64bit BPF + JIT
(new code). I'm wondering how 32bit-only archs should be handled to not regress
in evaluation performance to the current code.

> So I took flow_dissector() function, tweaked it a bit and compiled into BPF.
> x86_64 skb_flow_dissect() same skb (all cached)          -  42 nsec per call
> x86_64 skb_flow_dissect() different skbs (cache misses)  - 141 nsec per call
> bpf_jit skb_flow_dissect() same skb (all cached)         -  51 nsec per call
> bpf_jit skb_flow_dissect() different skbs (cache misses) - 135 nsec per call
>
> C->BPF64->x86_64 is slower than C->x86_64 when all data is in cache,
> but presence of cache misses hide extra insns.
>
> For gre flow_dissector() looks into inner packet, but for vxlan it does not,
> since it needs to know udp port number. We can extend it with if (static_key)
> and walk the list of udp_offload_base->offload->port like we do in
> udp_gro_receive(),
> but for RPS we just need a hash. I think custom loadable
> flow_dissector() is the way to go.
> If we know that majority of the traffic on the given machine is vxlan to port N
> we can hard code this into BPF program. Don't need to walk outer packet either.
> Just pick ip/port from inner. It's doable with old BPF too.
>
> What we used to think as dynamic, with BPF can be hard coded.
>
> As soon as I have time I'm thinking to play with nftables. The idea is:
> rules are changed rarely, but a lot of traffic goes through them,
> so we can spend time optimizing them.
>
> Either user input or nft program can be converted to C, then LLVM invoked
> to optimize the whole thing, generate BPF and load it.
> Adding a rule will take time, but if execution of such ip/nftables
> will be faster
> the end user will benefit.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/