Re: [patch net-next] tc: add BPF based action

[Alexei Starovoitov <ast@plumgrid.com>]

On Wed, Jan 7, 2015 at 11:26 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>>
>>On the other hand, I would understand if it's at some point in
>>time eBPF which would f.e. mangle the packet, but the API you
>>propose is clearly classic BPF. ;)
>
> Exactly. I would like to extend cls_bpf and act_bpf to handle eBPF right
> after. That is the point.

I say that connecting it with classic BPF is not a prerequisite
to use eBPF in there. Invocation place may be the same,
but the way to pass the program will be different.
For classic with just pass the whole program, whereas
for eBPF we'll be likely passing fd.
Theoretically we can pass eBPF as vanilla program
as well that doesn't have map access, but verifier check
will only be binary (accept or reject). Which is not user
friendly. Even rejection of classic BPF is hard to decipher.
Especially when only language for classic is assembler
and poor users have no easy way to know what was
wrong with the program. Therefore I like bpf syscall
as a main and only interface to load the programs
and pass prog_fd to places where they suppose to run.
Having syscall as center place to load programs
also helps with accounting, since root will be able
to do something like 'lsmod' to see all loaded programs.
Anyway, that's a conversion for later...

As Daniel pointed out I think some better articulation
on what classic bpf programs will do here is needed.
It seems they will work as pre-filter on an action?
Few examples would help to understand use cases...