Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Laura Garcia <nevola@gmail.com>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Jozsef Kadlecsik <kadlec@netfilter.org>,
	Florian Westphal <fw@strlen.de>,
	Netfilter Development Mailing list 
	<netfilter-devel@vger.kernel.org>,
	coreteam@netfilter.org, netdev@vger.kernel.org,
	Martin Mares <mj@ucw.cz>, Dmitry Safonov <0x7f454c46@gmail.com>,
	Thomas Graf <tgraf@suug.ch>, Alexei Starovoitov <ast@kernel.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH nf-next 3/3] netfilter: Introduce egress hook
Date: Thu, 20 Aug 2020 12:37:01 +0200	[thread overview]
Message-ID: <20200820103701.on5rqxawqqc7kwdw@wunner.de> (raw)
In-Reply-To: <1a27351b-78a8-febc-45d7-6ee2e8ebda9e@iogearbox.net>

On Tue, Apr 28, 2020 at 10:11:19PM +0200, Daniel Borkmann wrote:
> > https://lore.kernel.org/netdev/bbdee6355234e730ef686f9321bd072bcf4bb232.1584523237.git.daniel@iogearbox.net/
> > 
> > In the ensuing discussion it turned out that the performance argument
> > may be addressed by a rearrangement of sch_handle_egress() and
> > nf_egress() invocations.  I could look into amending the series
> > accordingly and resubmitting, though I'm currently swamped with
> > other work.
> 
> The rework of these hooks is still on my todo list, too swamped with
> other stuff as well right now, but I'll see to have a prototype this
> net-next development cycle.

Daniel, I have it running now the way you want it (I think) and am
benchmarking several variants.  I'm now faced with the following
choice:

* One variant speeds up the default case with neither tc nor nft in use
  (2241 -> 2285 Mb/sec), but tc becomes a little slower (1929 -> 1927
  Mb/sec).

* Another variant still speeds up the default case but not by as much
  (2241 -> 2274 Mb/sec) and speeds up tc as well (1929 -> 1931 Mb/sec).

The difference is that the first variant uses an outer static_key which
patches in a function containing two inner static_keys for nft + tc.
The second variant uses an outer static_key and a single inner static_key
for nft (but no static_key for tc).

nft is slower in the second variant (2231 -> 2225 Mb/sec).

I'm leaning towards the first variant, but because it incurs a small
performance degradation if tc is used, I wanted to give you a heads-up.
If this is totally unacceptable for you, I'll post the second variant
instead.

I need a few more days to update the commit messages, perform further
testing and apply polish, so I plan to dump the patches to the list
next week.  Just thought I'd ask for your opinion, I'm aware this is
difficult to judge without seeing the code.

I'm using static_keys instead of fmodify_return (which you've suggested)
because I would like to avoid a dependency on BPF as it might not be an
option for space-constrained embedded machines and a BPF JIT isn't
available on as many arches as CONFIG_JUMP_LABEL.

Thanks,

Lukas

  reply	other threads:[~2020-08-20 10:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 11:59 [PATCH nf-next 0/3] Netfilter " Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 1/3] netfilter: Rename ingress hook include file Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 2/3] netfilter: Generalize ingress hook Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 3/3] netfilter: Introduce egress hook Lukas Wunner
2020-03-11 14:05   ` Daniel Borkmann
2020-03-11 15:54     ` Lukas Wunner
2020-03-12 22:40       ` Daniel Borkmann
2020-03-13 14:55     ` Pablo Neira Ayuso
2020-03-14  0:12       ` Daniel Borkmann
2020-03-15 13:28         ` Pablo Neira Ayuso
2020-04-23 14:44           ` Laura Garcia
2020-04-23 16:05             ` Lukas Wunner
2020-04-27 23:44               ` Pablo Neira Ayuso
2020-04-28 20:11               ` Daniel Borkmann
2020-08-20 10:37                 ` Lukas Wunner [this message]
2020-08-20 16:35                   ` Lukas Wunner
2020-03-18  0:21 ` [PATCH nf-next 0/3] Netfilter " Pablo Neira Ayuso

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=20200820103701.on5rqxawqqc7kwdw@wunner.de \
    --to=lukas@wunner.de \
    --cc=0x7f454c46@gmail.com \
    --cc=ast@kernel.org \
    --cc=coreteam@netfilter.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=kadlec@netfilter.org \
    --cc=mj@ucw.cz \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=nevola@gmail.com \
    --cc=pablo@netfilter.org \
    --cc=tgraf@suug.ch \
    --subject='Re: [PATCH nf-next 3/3] netfilter: Introduce egress hook' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).