On Fri, Oct 13, 2023 at 09:30:50PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > Instead of copying struct nft_set_elem into struct nft_trans_elem, store > > the pointer to the opaque set element object in the transaction. Adapt > > set backend API (and set backend implementations) to take the pointer to > > opaque set element representation whenever required. > > > > This patch deconstifies .remove() and .activate() set backend API since these > > modify the set element opaque object. And it also constify nft_set_elem_ext() > > since this provides access to the nft_set_ext struct without updating the > > object. > > > > According to pahole on x86_64, this patch shrinks struct nft_trans_elem > > size from 216 to 24 bytes. > > > > This patch also reduces stack memory consumption by removing the > > template struct nft_set_elem object which consumes 200 bytes of stack > > memory according to pahole. Use the opaque set element object instead > > from the set iterator API, catchall elements and the get element > > command paths to benefit from this memory consumption reduction. > > Is there a request for this? Or is the memory consumption a concern > on your end? This takes element transaction from kmalloc-512 pool to kmalloc-128, elements use a lot of this temporary objects. > > Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> > > --- > > I tagged this as RFC because it based on nf.git, but targeted at > > nf-next.git, because of missing dependencies, I have kept in here for a > > while in my local pile waiting for the dependencies to land, but I > > prefer to post it now for review. So it cannot be considered for > > integration into the nf-next.git tree yet because of these details. > > > > This patch depends on ("netfilter: nf_tables: do not remove elements if > > set backend implements .abort") which will take time to propagate to > > nf-next. This also slightly clashes with a other existing pending > > patches for nf-next floating in the mailing list, but that should be > > easy to fix with a rebase. > > > > I started with an initial patch to make the const updates, but it is > > triggering more churning than expected (since follow up patch will again > > update the same line when changing from struct nft_set_elem to void). > > I believe this patch should be relatively easy to review, but maybe > > that is just my bias. > > > > Main issue is (and it was still before patch) is that this opaque > > object from the nf_tables frontend is void *, which makes it harder for > > the compiler to catch stupid mistakes such as passing elem instead of > > elem.priv or even &trans->elem, that is, type checking is defeated so > > careful inspection is needed. Instrumention and existing tests also help > > catch issues of course. > > The void * is bad, and I dislike that this gets spread. > Could you add a "struct nft_set_elem_priv" that serves > as a proxy object? > > All the priv elements would include it as first member, > so we can pass that around instead of void *? This is a great idea, I am preparing a v2.