Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> 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.
