Re: [RFC] bpf: add bpf_link support for BPF_NETFILTER programs

[Florian Westphal <fw@strlen.de>]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> Yes. bpf_link is the right model.
> I'd also allow more than one BPF_NETFILTER prog at the hook.
> When Daniel respins his tc bpf_link set there will be a way to do that
> for tc and hopefully soon for xdp.
> For netfilter hook we can use the same approach.

For nf it should already support several programs, the
builtin limit in the nf core is currently 1024 hooks per
family/hook location.

> > I could add a new nfnetlink subtype for nf-bpf if bpf_link is not
> > appropriate as an alternative.
> 
> Let's start with bpf_link and figure out netlink path when appropriate.

Good, that works for me.

> I'd steer clear from new abi-s.
> Don't look at uapi __sk_buff model. It's not a great example to follow.
> Just pass kernel nf_hook_state into bpf prog and let program deal
> with changes to it via CORE.

The current prototype for nf hooks is

fun(void *private, struct sk_buff *skb, struct nf_hook_state *s)

Originally I had intended to place sk_buff in nf_hook_state, but its
quite some code churn for everyone else.

So I'm leaning towards something like
	struct nf_bpf_ctx {
		struct nf_hook_state *state;
		struct sk_buff *skb;
	};

that gets passed as argument.

> The prog will get a defition of 'struct nf_hook_state' from vmlinux.h
> or via private 'struct nf_hook_state___flavor' with few fields defined
> that prog wants to use. CORE will deal with offset adjustments.
> That's a lot less kernel code. No need for asm style ctx rewrites.
> Just see how much kernel code we already burned on *convert_ctx_access().
> We cannot remove this tech debt due to uapi.
> When you pass struct nf_hook_state directly none of it is needed.

Ok, thanks for pointing that out.  I did not realize
convert_ctx_access() conversions were frowned upon.

I will pass a known/exposed struct then.

I thought __sk_buff was required for direct packet access, I will look
at this again.