Re: [PATCH v4 net-next 1/3] Extended BPF interpreter and converter

[Daniel Borkmann]

On 03/04/2014 06:53 PM, Alexei Starovoitov wrote:
> On Tue, Mar 4, 2014 at 6:28 AM, Hagen Paul Pfeifer <hagen@xxxxxxxx> wrote:
> > If all issues raised by Daniel are addresed:
> >
> > Acked-by: Hagen Paul Pfeifer <hagen@xxxxxxxx>
>
> 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

I think ebpf would have the potential to be *the* general purpose
in-kernel interpreter actually (if we undertake all this effort of
migration) as its already designed to be in a more generic context
than the traditional interpreter which is restricted to skb (or NULL).

> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/