All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [nft PATCH 0/5] Reduce cache overhead a bit
Date: Wed, 1 Dec 2021 18:18:57 +0100	[thread overview]
Message-ID: <20211201171857.GI29413@orbyte.nwl.cc> (raw)
In-Reply-To: <YaenaMa1rcu5BX4U@salvia>

On Wed, Dec 01, 2021 at 05:48:40PM +0100, Pablo Neira Ayuso wrote:
> Hi Phil,
> 
> On Wed, Dec 01, 2021 at 04:02:53PM +0100, Phil Sutter wrote:
> > Comparing performance of various commands with equivalent iptables ones
> > I noticed that nftables fetches data from kernel it doesn't need in some
> > cases. For instance, listing one table was slowed down by a large other
> > table.
> > 
> > Since there is already code to filter data added to cache, make use of
> > that and craft GET requests to kernel a bit further so it returns only
> > what is needed.
> 
> Using netlink to filter from kernel space is the optimal solution.

I was basically copying from iptables-nft. :)

> > This series is not entirely complete, e.g. objects are still fetched as
> > before. It rather converts some low hanging fruits.
> 
> Only one thing: It would be good to test this on older kernels,
> because IIRC some of the GET requests during the development, I would
> suggest to give it a test with -stable kernels. Probably all of the
> needed GET commands are already present there.

Good point, thanks. I'll check and report.

> In the nftables 1.0.1 release process, I tested it with 4.9.x and
> tests where running fine, the error reports were coming from missing
> features.

If ENOENT wasn't reported as EINVAL, We could even fall back to plain
NLM_F_DUMP on older kernels. Maybe tackle that first and build upon
that?

Cheers, Phil

  reply	other threads:[~2021-12-01 17:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01 15:02 [nft PATCH 0/5] Reduce cache overhead a bit Phil Sutter
2021-12-01 15:02 ` [nft PATCH 1/5] cache: Filter tables on kernel side Phil Sutter
2021-12-01 15:02 ` [nft PATCH 2/5] cache: Filter rule list " Phil Sutter
2021-12-01 15:02 ` [nft PATCH 3/5] cache: Filter chain " Phil Sutter
2021-12-01 15:02 ` [nft PATCH 4/5] cache: Filter set list on server side Phil Sutter
2021-12-01 15:02 ` [nft PATCH 5/5] cache: Support filtering for a specific flowtable Phil Sutter
2021-12-01 16:48 ` [nft PATCH 0/5] Reduce cache overhead a bit Pablo Neira Ayuso
2021-12-01 17:18   ` Phil Sutter [this message]
2021-12-01 18:02     ` Phil Sutter
2021-12-01 18:20       ` 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=20211201171857.GI29413@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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.