From: Florian Westphal <fw@strlen.de>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Florian Westphal <fw@strlen.de>, bpf <bpf@vger.kernel.org>
Subject: Re: [RFC v2 6/9] netfilter: add bpf base hook program generator
Date: Fri, 7 Oct 2022 21:35:14 +0200 [thread overview]
Message-ID: <20221007193514.GA22318@breakpoint.cc> (raw)
In-Reply-To: <CAADnVQLSwX4gCK62KT_qEuPwagn4B9SMOBrLBcLh+2PFxypxqw@mail.gmail.com>
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > - if (!emit(p, BPF_EMIT_CALL(nf_hook_slow)))
> > + if (!emit(p, BPF_EMIT_CALL(nf_hook_slow_bpf)))
> >
> > ?
> >
> > If yes, I don't see how this will work for the case where I only have an
> > address, i.e.:
> >
> > if (!emit(p, BPF_EMIT_CALL(h->hook))) ....
> >
> > (Also, the address might be in a kernel module)
> >
> > > On x86-64 it will be a nop.
> > > On x86-32 it will do quite a bit of work.
> >
> > If this only a problem for 32bit arches, I could also make this
> > 'depends on CONFIG_64BIT'.
>
> If that's acceptable, sure.
Good, thanks!
> > But perhaps I am on the wrong track, I see existing code doing:
> > *insn++ = BPF_EMIT_CALL(__htab_map_lookup_elem);
>
> Yes, because we do:
> /* BPF_EMIT_CALL() assumptions in some of the map_gen_lookup
> * and other inlining handlers are currently limited to 64 bit
> * only.
> */
> if (prog->jit_requested && BITS_PER_LONG == 64 &&
Ah, thanks, makes sense.
> I think you already gate this feature with jit_requested?
> Otherwise it's going to be slow in the interpreter.
Right, use of bpf interpreter is silly for this.
> > 39: unspec tag 0000000000000000
> > xlated 416B jited 221B memlock 4096B
>
> Probably should do bpf_prog_calc_tag() too.
> And please give it some meaningful name.
Agree, will add this.
next prev parent reply other threads:[~2022-10-07 19:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 14:13 [RFC 0/9 v2] netfilter: bpf base hook program generator Florian Westphal
2022-10-05 14:13 ` [RFC v2 1/9] netfilter: nf_queue: carry index in hook state Florian Westphal
2022-10-05 14:13 ` [RFC v2 2/9] netfilter: nat: split nat hook iteration into a helper Florian Westphal
2022-10-05 14:13 ` [RFC v2 3/9] netfilter: remove hook index from nf_hook_slow arguments Florian Westphal
2022-10-05 14:13 ` [RFC v2 4/9] netfilter: make hook functions accept only one argument Florian Westphal
2022-10-05 14:13 ` [RFC v2 5/9] netfilter: reduce allowed hook count to 32 Florian Westphal
2022-10-05 14:13 ` [RFC v2 6/9] netfilter: add bpf base hook program generator Florian Westphal
2022-10-06 2:52 ` Alexei Starovoitov
2022-10-06 13:51 ` Florian Westphal
2022-10-07 11:45 ` Florian Westphal
2022-10-07 19:08 ` Alexei Starovoitov
2022-10-07 19:35 ` Florian Westphal [this message]
2022-10-05 14:13 ` [RFC v2 7/9] netfilter: core: do not rebuild bpf program on dying netns Florian Westphal
2022-10-05 14:13 ` [RFC v2 8/9] netfilter: netdev: switch to invocation via bpf Florian Westphal
2022-10-05 14:13 ` [RFC v2 9/9] netfilter: hook_jit: add prog cache Florian Westphal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221007193514.GA22318@breakpoint.cc \
--to=fw@strlen.de \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.