From: Alexei Starovoitov <ast@plumgrid.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: Daniel Borkmann <dborkman@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Ingo Molnar <mingo@kernel.org>, Will Drewry <wad@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
"H. Peter Anvin" <hpa@zytor.com>, Jesse Gross <jesse@nicira.com>,
Thomas Gleixner <tglx@linutronix.de>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Tom Zanussi <tom.zanussi@linux.intel.com>,
Jovi Zhangwei <jovi.zhangwei@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Pekka Enberg <penberg@iki.fi>,
Arjan van de Ven <arjan@infradead.org>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v4 net-next 1/3] Extended BPF interpreter and converter
Date: Tue, 4 Mar 2014 09:53:01 -0800 [thread overview]
Message-ID: <CAMEtUuxHgcroQBPLFa9U=df6KznwkjARin8a3RfH4MdbB2rc7g@mail.gmail.com> (raw)
In-Reply-To: <20140304142824.GA1083@localhost.localdomain>
On Tue, Mar 4, 2014 at 6:28 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> If all issues raised by Daniel are addresed:
>
> Acked-by: Hagen Paul Pfeifer <hagen@jauu.net>
Thanks!
> But ...
>
>>Future work:
>>
>>0. seccomp
>>
>>1. add extended BPF JIT for x86_64
>>
>>2. add inband old/new demux and extended BPF verifier, so that new programs
>> can be loaded through old sk_attach_filter() and sk_unattached_filter_create()
>> interfaces
>>
>>3. tracing filters systemtap-like with extended BPF
>>
>>4. OVS with extended BPF
>>
>>5. nftables with extended BPF
>
> ... this is shit (not your fault). (Jitted) BPF envolved into a direction
> which is just not the right way to do it. You try to fix things, bypass
> architectural shortcomings of BPF, perf issues because and so on.
>
> The right direction is to write a new general purpose in-kernel interpreter
> from scratch. Capability layers should provide an compatible API for BPF and
> seccomp. You have the knowledge to do exactly this, you nearly already did
> this - you should start this undertake!
this insn set evolved over few years.
Initially we had nft-like high level state machine, but it wasn't fast,
then kprobe-like pure x86_64 which was fast, but very hard to analyze
from safety point of view. Then reduced x86-64 insn set and finally ebpf.
I think any brand new instruction set will have steep learning curve,
just because
it's all new. ebpf tries to reuse as much as possible. opcode encoding
is the same,
instruction size is fixed at 8 bytes and so on. Yeah, these
restrictions make few
things not 100% optimal, but imo common look and feel is more important.
What ebpf has already should be enough to do all of the above 'future work'.
Built-in JIT-ability of ebpf is the key to performance.
Ability to call some kernel functions from ebpf make it ultimately extensible.
socket filters and seccomp don't use this feature yet, but tracing filters will.
Regards,
Alexei
>
> --
> Hagen Paul Pfeifer
next prev parent reply other threads:[~2014-03-04 17:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 5:18 [PATCH v4 net-next 0/3] Extended BPF, converter, seccomp, doc Alexei Starovoitov
2014-03-04 5:18 ` [PATCH v4 net-next 1/3] Extended BPF interpreter and converter Alexei Starovoitov
2014-03-04 9:59 ` Daniel Borkmann
2014-03-04 17:09 ` Alexei Starovoitov
2014-03-04 18:23 ` Daniel Borkmann
2014-03-04 14:28 ` Hagen Paul Pfeifer
2014-03-04 17:53 ` Alexei Starovoitov [this message]
2014-03-04 18:31 ` Daniel Borkmann
2014-03-04 5:18 ` [PATCH v4 net-next 2/3] RFC: convert seccomp to use extended BPF Alexei Starovoitov
2014-03-04 5:18 ` [PATCH v4 net-next 3/3] Extended BPF documentation Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMEtUuxHgcroQBPLFa9U=df6KznwkjARin8a3RfH4MdbB2rc7g@mail.gmail.com' \
--to=ast@plumgrid.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=hagen@jauu.net \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=jesse@nicira.com \
--cc=jovi.zhangwei@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=penberg@iki.fi \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tom.zanussi@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).