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 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).