From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Arturo Borrero Gonzalez <arturo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft 0/3] ruleset optimization infrastructure
Date: Thu, 23 Dec 2021 03:10:04 +0100 [thread overview]
Message-ID: <YcPafECXZu4q60YD@salvia> (raw)
In-Reply-To: <d878f630-adff-1522-c953-ec845d72a89c@netfilter.org>
Hi Arturo,
On Thu, Dec 16, 2021 at 12:54:02PM +0100, Arturo Borrero Gonzalez wrote:
> On 12/15/21 20:56, Pablo Neira Ayuso wrote:
> > Hi,
> >
> > This patchset adds a new -o/--optimize option to enable ruleset
> > optimization.
> >
>
> Thanks for working on this. From what I see in the community, this feature
> will be of high value to some folks: users often struggle with doing this
> kind of optimizations by hand.
>
> > The ruleset optimization first loads the ruleset in "dry run" mode to
> > validate that the original ruleset is correct. Then, on a second pass it
> > performs the ruleset optimization before adding the rules into the
> > kernel.
> >
>
> Could you please describe how to work with this if all I want is to check
> how an optimized version of my ruleset would look like, but not load it into
> the kernel?
>
> The use case would be: I just need a diff between my ruleset.nft file and
> whatever the optimized version would be, without performing any actual
> change.
This is feasible. I could probably add a flags field instead of simple
boolean to the API so it is possible to specify an option such as:
# nft -o offline -f ruleset.nft
which would print the ruleset listing without loading it.
> Of course this can be added later on if not supported in this patch.
>
> > This infrastructure collects the statements that are used in rules. Then,
> > it builds a matrix of rules vs. statements. Then, it looks for common
> > statements in consecutive rules that are candidate to be merged. Finally,
> > it merges rules.
>
> clever!
>
> Is this infra extensible enough to support scanning non-adjacent rules in
> the future?
This requires another step to group rules with the same statements
whenever possible, such routine would need to make sure that the rule
verdict is the same and that no stateful statements (eg. limit) is
used.
> ie, being able to transform:
>
> * ip daddr 1.1.1.1 counter accept
> * tcp dport 80 accept
> * ip daddr 2.2.2.2 counter accept
>
> into:
>
> * ip daddr { 1.1.1.1, 2.2.2.2 } counter accept
> * tcp dport 80 accept
or even this:
* ip daddr . tcp dport { 1.1.1.1 . 0-65535, 2.2.2.2 . 0-65535, 0.0.0.0/0 . 80 } counter accept
but this requires a Linux kernel >= 5.6.
There are a few more transformations that come to my mind, such as
packing several snat/dnat rules into a map.
I'll be posting v2 of this patchset with many fixes and tests soon.
prev parent reply other threads:[~2021-12-23 2:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-15 19:56 [PATCH nft 0/3] ruleset optimization infrastructure Pablo Neira Ayuso
2021-12-15 19:56 ` [PATCH nft 1/3] src: add " Pablo Neira Ayuso
2021-12-15 19:56 ` [PATCH nft 2/3] optimize: merge rules with same selectors into a concatenation Pablo Neira Ayuso
2021-12-15 19:56 ` [PATCH nft 3/3] optimize: merge same selector with different verdict into verdict map Pablo Neira Ayuso
2021-12-16 11:54 ` [PATCH nft 0/3] ruleset optimization infrastructure Arturo Borrero Gonzalez
2021-12-23 2:10 ` Pablo Neira Ayuso [this message]
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=YcPafECXZu4q60YD@salvia \
--to=pablo@netfilter.org \
--cc=arturo@netfilter.org \
--cc=netfilter-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox