Re: [Nftables RFC] High level library proposal

[Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>]

Hi Jesper,

>> >- either via proposing low level functions requesting the cache as you
>> >propose (and we probably should)
> I'm a little worried about your idea of implementing a cache.
> It reminds me of the current libliptc (IPtables Cache) library, which
> caused a lot of annoying issues in the past.
> I know, you said we can use the notification system to keep the cache
> up-to-date, but just have a bad feeling about introducing a cache
> layer...

It should be indeed much easier and reliable to maintain a cache with 
nftables api.
But you are right: not all usage might require this. That's why I 
thought about NFT_FLAG_FOLLOW_* flags
One could limit the "caching" towards only application 
rules/chain/tables (if any), and other one would keep track of everything.

>> >- and/or when using nft_execute_statement() it would check if it already
>> >exist - or not, if it's a delete statement -
>> >by itself, hiding the details to the dev and raising a success relevantly.
> So, your are saying that a nft_execute_statement() that creates a rule
> sound return a "false" indication if the rule already exists?
> I would really prefer a real "test/query" operation, but I guess we
> should extend the kernel API to support this, so we don't need a cache
> infrastructure for this.

I don't know if such existence test should be part of kernel API rather 
than in user land since when manipulating
you need anyway a dump of the rule set.

But about nft_execute_statement(), it's not really a false indication: 
you want to inject a rule which already exist, so it's fine.
Or we could handle it so it return an error like -EALREADY if it's 
preferable.

Br,

Tomasz