netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: netfilter-devel@vger.kernel.org
Cc: phil@nwl.cc, fw@strlen.de
Subject: [PATCH nft 0/4] split parse and evaluation phase to simplify cache logic
Date: Wed,  5 Jun 2019 18:46:48 +0200	[thread overview]
Message-ID: <20190605164652.20199-1-pablo@netfilter.org> (raw)

Hi,

There are a myriad of cache_update() calls all over the evaluation phase
that are required because the parser invokes the evaluation per command.

This complicates the cache logic, since nft may have to invalid a
partial cache to upgrade to a full cache from one command to another.
This forces nft to go back re-evaluate the existing batch that is being
processed, this overly complicates things because the number of
scenarios that trigger cache updates explode. This will get even more
complicated once we do proper cache generation and ERESTART support is
added - which is still missing.

This patchset aims to simplify cache logic by performing one single
cache_update() before the evaluation phase, the idea is to iterate over
the existing commands that come from the parser to do a cache_evaluate()
call that calculates what cache nft needs to dump from the kernel
(either partial or full, actually we have more degress of completeness,
not just these two only). Then, with the proper cache in place, the
evaluation happens.

This patchset revisits the existing design to address this problem:

1) Dynamically allocate input_descriptor object, this allows error
   reporting from the evaluation phase to access file location that
   was only available from the parser phase.

2) Evaluate the ruleset once the parser is complete. So we have two
   independent phases.

3) The mixture of parsing + evaluation was introduced to display all
   errors, either from the parsing or the evaluation phases.

4) Make a single cache_update() call based on the new cache_evaluate()
   function that calculates the kernel dump that needs to be done
   before entering the evaluation phase.

Thanks.

Pablo Neira Ayuso (4):
  src: dynamic input_descriptor allocation
  src: perform evaluation after parsing
  src: Display parser and evaluate errors in one shot
  src: single cache_update() call to build cache before evaluation

 include/nftables.h |   1 +
 include/parser.h   |   4 +-
 include/rule.h     |   1 +
 src/Makefile.am    |   1 +
 src/cache.c        | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/erec.c         |  35 +--------------
 src/evaluate.c     |  76 +--------------------------------
 src/libnftables.c  |  57 +++++++++++++++++++------
 src/mnl.c          |   8 +---
 src/parser_bison.y |  28 ++----------
 src/parser_json.c  |   9 ----
 src/rule.c         |  18 +-------
 src/scanner.l      |  63 ++++++++++++++++++---------
 13 files changed, 222 insertions(+), 202 deletions(-)
 create mode 100644 src/cache.c

-- 
2.11.0


             reply	other threads:[~2019-06-05 16:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 16:46 Pablo Neira Ayuso [this message]
2019-06-05 16:46 ` [PATCH nft 1/4] src: dynamic input_descriptor allocation Pablo Neira Ayuso
2019-06-05 16:46 ` [PATCH nft 2/4] src: perform evaluation after parsing Pablo Neira Ayuso
2019-06-05 16:46 ` [PATCH nft 3/4] src: Display parser and evaluate errors in one shot Pablo Neira Ayuso
2019-06-05 16:46 ` [PATCH nft 4/4] src: single cache_update() call to build cache before evaluation Pablo Neira Ayuso
2019-06-05 19:34   ` Phil Sutter
2019-06-06  9:25 ` [PATCH nft 0/4] split parse and evaluation phase to simplify cache logic 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=20190605164652.20199-1-pablo@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /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 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).