Re: [patch net-next v4 1/2] tc: add BPF based action

[Daniel Borkmann <dborkman@redhat.com>]

On 01/14/2015 08:27 PM, Cong Wang wrote:
> On Wed, Jan 14, 2015 at 9:43 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> This action provides a possibility to exec custom BPF code.
>
> I still don't like it, sorry, not just for your patch, I never like
> cls_bpf either, in terms of the user interface and the duplicated
> functionalities: cls_bpf vs u32, act_bpf vs gact.
...
> Ideally we should be able to implement them with the same
> interface, transparent to users, I think probably because
> the nature of bpf implementation somewhat enforces such
> interface everywhere, it is clearly overrated.

Hmm, I guess you're talking about the interface from tc side, other
than that cls_bpf is also faster when JITed. I can only speak for
cls_bpf here, which is modelled the same way after xt_bpf and takes
low-level BPF opcodes directly or stored somewhere as a file. Not
overly pretty, that's true.

For somewhat higher but still low-level enough description, I've
added bpf_asm for that purpose so you can still have full control
and if that's still too much and you don't care about unsupported
BPF extensions, then the libpcap compiler is your friend. For example,
Willem has added [1] longer time ago which takes tcpdump-like
filters and spills out related opcodes for you, if you don't want
to use tcpdump -ddd directly.

The other possibility would be to have an own internal BPF filter
compiler inside of tc (w/o any external lib dependencies), a thought
lingering in my head for quite some time now. I guess I could scratch
some cycles off from my spare time and start hacking on it.

Other than that, for the eBPF part, there are efforts to upstream
backends to llvm and gcc, afaik, so their produced output could be
passed onwards to tc, similarly as in samples/bpf/ as one possibility
I could imagine.

   [1] http://git.netfilter.org/iptables/tree/utils/nfbpf_compile.c