All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Florian Westphal" <fw@strlen.de>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Network Development" <netdev@vger.kernel.org>,
	"Toke Høiland-Jørgensen" <toke@kernel.org>,
	netfilter-devel <netfilter-devel@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH nf-next] netfilter: nf_tables: add ebpf expression
Date: Wed, 31 Aug 2022 23:57:37 +0200	[thread overview]
Message-ID: <20220831215737.GE15107@breakpoint.cc> (raw)
In-Reply-To: <CAADnVQJGQmu02f5B=mc1xJvVWSmk_GNZj9WAUskekykmyo8FzA@mail.gmail.com>

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > This helps gradually moving towards move epbf for those that
> > still heavily rely on the classic forwarding path.
> 
> No one is using it.
> If it was, we would have seen at least one bug report over
> all these years. We've seen none.

Err, it IS used, else I would not have sent this patch.

> very reasonable early on and turned out to be useless with
> zero users.
> BPF_PROG_TYPE_SCHED_ACT and BPF_PROG_TYPE_LWT*
> are in this category.

I doubt it had 0 users.  Those users probably moved to something
better?

> As a minimum we shouldn't step on the same rakes.
> xt_ebpf would be the same dead code as xt_bpf.

Its just 160 LOC or so, I don't see it has a huge technical debt.

> > If you are open to BPF_PROG_TYPE_NETFILTER I can go that route
> > as well, raw bpf program attachment via NF_HOOK and the bpf dispatcher,
> > but it will take significantly longer to get there.
> >
> > It involves reviving
> > https://lore.kernel.org/netfilter-devel/20211014121046.29329-1-fw@strlen.de/
> 
> I missed it earlier. What is the end goal ?

Immediate goal: get rid of all indirect calls from NF_HOOK()
invocations. Its about 2% speedup in my tests (with connection
tracking+defrag enabled).

This series changes prototype of the callbacks to int foo(struct *),
so I think it would be possible to build on this and allow attaching raw
bpf progs/implement what is now a netfilter kernel module as a bpf
program.

I have not spent time on this so far though, so I don't know yet
how the "please attach prog id 12345 at FORWARD with prio 42" should
be done.

> Optimize nft run-time with on the fly generation of bpf byte code ?

This could be done too, so far this JITs nf_hook_slow() only.
The big question for nft run-time would be how and where to do the JIT
translation.

I think that "nft run time jit" would be step 3, after allowing
(re)implementation of netfilter modules via bpf programs.

  parent reply	other threads:[~2022-08-31 21:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31 10:16 [PATCH nf-next] netfilter: nf_tables: add ebpf expression Florian Westphal
2022-08-31 12:13 ` Toke Høiland-Jørgensen
2022-08-31 12:56   ` Florian Westphal
2022-08-31 13:41     ` Toke Høiland-Jørgensen
2022-08-31 13:57       ` Florian Westphal
2022-08-31 14:43         ` Toke Høiland-Jørgensen
2022-08-31 15:09           ` Pablo Neira Ayuso
2022-08-31 15:35             ` Florian Westphal
2022-08-31 20:38               ` Pablo Neira Ayuso
2022-08-31 15:26           ` Florian Westphal
2022-08-31 15:39             ` Alexei Starovoitov
2022-08-31 15:53               ` Florian Westphal
2022-08-31 17:26                 ` Alexei Starovoitov
2022-08-31 21:49                   ` Daniel Borkmann
2022-09-01  5:18                     ` Eyal Birger
2022-09-02 16:53                       ` Alexei Starovoitov
2022-09-05 17:50                         ` Eyal Birger
2022-09-01 10:14                     ` Florian Westphal
2022-09-02 17:06                       ` Alexei Starovoitov
2022-09-02 17:52                         ` Florian Westphal
2022-08-31 21:57                   ` Florian Westphal [this message]
2022-09-06  6:57                     ` Nicolas Dichtel
2022-09-07  3:04                       ` Alexei Starovoitov
2022-09-07 15:52                         ` Nicolas Dichtel
2022-09-01  8:08                   ` Jan Engelhardt
2022-08-31 20:44             ` Toke Høiland-Jørgensen
2022-08-31 13:44     ` 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=20220831215737.GE15107@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=toke@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.