Re: [RFC nf-next] netfilter: nf_tables: remove element flush allocation

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi Florian,

On Thu, Jul 31, 2025 at 05:43:49PM +0200, Florian Westphal wrote:
[...]
> One way to resolve this is to allow sleeping allocations, but Pablo
> suggested to avoid the per-element-allocations altogether.
> 
> The main drawback vs the initial patch is that in order to support
> sleeping allocations, memory cost of each set element grows by one
> pointer whereas initial sleeping-allocations only did this for the
> rhashtable backend.
> 
> Not signed off as I don't see this as more elegant as v1 here:
> https://lore.kernel.org/netfilter-devel/20250704123024.59099-1-fw@strlen.de/

Not very elegant, maybe it is just incomplete.

> One advantage however is that NEWSETELEM could be converted to use
> the llist too instead of the dynamically-sized nelems array.

Yes.

> Then, the array could be removed again, it seems dubious to keep it
> just for the update case.

For updates, I think the element would need a scratch area to store
the new timeout/expiration until commit phase is reached. For several
updates on the same element in a batch.

> That in turn would allow to remove the compaction code again.

Yes.

> Both DEL/NEWSETELEM would be changed to first peek the transaction list
> tail to see if a compatible transaction exists and re-use that instead
> of allocating a new one.

Right. Would all this provide even more memory savings?

> Pablo, please let me know if you prefer this direction compared to v1.
> If so, I would also work on removing the trailing dynamically sized
> array from nft_trans_elem structure in a followup patch.

I don't remember when precisely, but time ago, you mentioned something
like "this transaction infrastructure creates myriad of temporary
objects". Your dynamic array infrastructure made it better.

Maybe it is time to integrate transaction infrastrcture more tightly
into the existing infrastructure, so there is not need to allocate so
many ancilliary objects for large sets?

There is a trade-off in all this.