From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: nftables add vs replace
Date: Tue, 21 Jan 2014 11:32:32 +0000 [thread overview]
Message-ID: <20140121113232.GA26403@macbook.localnet> (raw)
In-Reply-To: <20140121112700.GA21772@localhost>
On Tue, Jan 21, 2014 at 12:27:00PM +0100, Pablo Neira Ayuso wrote:
> On Tue, Jan 21, 2014 at 11:06:46AM +0000, Patrick McHardy wrote:
> > We currently only support "add table" and "add chain" with NLM_F_EXCL.
> > This means we can't replace entire tables without a lot of extra effort,
> > also its not possible to create tables/chains just in case they don't
> > already exist.
> >
> > To fix this, I'd propose to add two new commands, so we have the following:
> >
> > - add: add without NLM_F_EXCL
> > - create: add with NLM_F_EXCL
> > - replace: replace the entire thing
>
> I guess you have in mind to simplify current reloading via nft -f.
> Currently, we have to manually flush and delete chain/tables at this
> moment, which is a bit of PITA.
Correct. It would also make creation of the predefined tables a lot less
error prone.
> > This most likely will also require updates to the transaction handling
> > so we don't only process rules, but table, chain and set updates in a
> > transaction.
> >
> > Comments?
>
> It would be indeed nice if we handle table/chain updates in the same
> batch like the rules. I think we can find a way to keep the current
> .call hook there so we allow both table/chain updates via batch and
> via simple independent commands.
Yes, that should be possible. We'd also need it for sets. I guess the
semantics would be:
- NLM_F_REPLACE: apply the entire batch to the newly created objects, IOW
ignore everything that already exists in the table
- !NLM_F_REPLACE: apply the batch to existing or new objects
next prev parent reply other threads:[~2014-01-21 11:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 11:06 nftables add vs replace Patrick McHardy
2014-01-21 11:27 ` Pablo Neira Ayuso
2014-01-21 11:32 ` Patrick McHardy [this message]
2014-01-21 11:37 ` Arturo Borrero Gonzalez
2014-01-21 11:45 ` Patrick McHardy
2014-01-21 15:15 ` Phil Oester
2014-01-21 17:37 ` Patrick McHardy
2014-01-22 8:38 ` Pablo Neira Ayuso
2014-01-22 8:54 ` Patrick McHardy
2014-01-22 9:17 ` Pablo Neira Ayuso
2014-01-22 9:30 ` Patrick McHardy
2014-01-21 11:46 ` Tomasz Bursztyka
2014-01-21 11:49 ` Patrick McHardy
2014-01-21 12:08 ` Tomasz Bursztyka
2014-01-21 12:11 ` Patrick McHardy
2014-01-21 12:17 ` Tomasz Bursztyka
2014-01-21 12:25 ` Patrick McHardy
2014-01-21 12:49 ` Tomasz Bursztyka
2014-01-21 14:05 ` Arturo Borrero Gonzalez
2014-01-21 15:10 ` Patrick McHardy
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=20140121113232.GA26403@macbook.localnet \
--to=kaber@trash.net \
--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.