[PATCH nf-next] netfilter: flowtable: dedicated slab for flow entry

[PATCH nf-next] netfilter: flowtable: dedicated slab for flow entry

[Qingfang Deng]

The size of `struct flow_offload` has grown beyond 256 bytes on 64-bit
kernels (currently 280 bytes) because of the `flow_offload_tunnel`
member added recently. So kmalloc() allocates from the kmalloc-512 slab,
causing significant memory waste per entry.

Introduce a dedicated slab cache for flow entries to reduce memory
footprint. Results in a reduction from 512 bytes to 320 bytes per entry
on x86_64 kernels.

Signed-off-by: Qingfang Deng <dqfext@gmail.com>
---
 net/netfilter/nf_flow_table_core.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
index 06e8251a6644..e075dbf5b0ce 100644
--- a/net/netfilter/nf_flow_table_core.c
+++ b/net/netfilter/nf_flow_table_core.c
@@ -16,6 +16,7 @@
 
 static DEFINE_MUTEX(flowtable_lock);
 static LIST_HEAD(flowtables);
+static __read_mostly struct kmem_cache *flow_offload_cachep;
 
 static void
 flow_offload_fill_dir(struct flow_offload *flow,
@@ -56,7 +57,7 @@ struct flow_offload *flow_offload_alloc(struct nf_conn *ct)
 	if (unlikely(nf_ct_is_dying(ct)))
 		return NULL;
 
-	flow = kzalloc(sizeof(*flow), GFP_ATOMIC);
+	flow = kmem_cache_zalloc(flow_offload_cachep, GFP_ATOMIC);
 	if (!flow)
 		return NULL;
 
@@ -812,9 +813,15 @@ static int __init nf_flow_table_module_init(void)
 {
 	int ret;
 
+	flow_offload_cachep = kmem_cache_create("nf_flow_offload",
+						sizeof(struct flow_offload),
+						NULL, SLAB_HWCACHE_ALIGN);
+	if (!flow_offload_cachep)
+		return -ENOMEM;
+
 	ret = register_pernet_subsys(&nf_flow_table_net_ops);
 	if (ret < 0)
-		return ret;
+		goto out_pernet;
 
 	ret = nf_flow_table_offload_init();
 	if (ret)
@@ -830,6 +837,8 @@ static int __init nf_flow_table_module_init(void)
 	nf_flow_table_offload_exit();
 out_offload:
 	unregister_pernet_subsys(&nf_flow_table_net_ops);
+out_pernet:
+	kmem_cache_destroy(flow_offload_cachep);
 	return ret;
 }
 
@@ -837,6 +846,7 @@ static void __exit nf_flow_table_module_exit(void)
 {
 	nf_flow_table_offload_exit();
 	unregister_pernet_subsys(&nf_flow_table_net_ops);
+	kmem_cache_destroy(flow_offload_cachep);
 }
 
 module_init(nf_flow_table_module_init);
-- 
2.43.0

Re: [PATCH nf-next] netfilter: flowtable: dedicated slab for flow entry

[Florian Westphal]

Qingfang Deng <dqfext@gmail.com> wrote:
> The size of `struct flow_offload` has grown beyond 256 bytes on 64-bit
> kernels (currently 280 bytes) because of the `flow_offload_tunnel`
> member added recently. So kmalloc() allocates from the kmalloc-512 slab,
> causing significant memory waste per entry.
> 
> Introduce a dedicated slab cache for flow entries to reduce memory
> footprint. Results in a reduction from 512 bytes to 320 bytes per entry
> on x86_64 kernels.

Ok, but please use KMEM_CACHE(), we've had a bunch of patches
that removed kmem_cache_create() in several places, I would like
to avoid a followup patch.

Re: [PATCH nf-next] netfilter: flowtable: dedicated slab for flow entry

[Qingfang Deng]

On Thu, Jan 29, 2026 at 6:26 PM Florian Westphal <fw@strlen.de> wrote:
> Ok, but please use KMEM_CACHE(), we've had a bunch of patches
> that removed kmem_cache_create() in several places, I would like
> to avoid a followup patch.

But I'm creating a slab with a different name (`nf_flow_offload`) from
the struct name (`flow_offload`). Should I keep the `nf_` prefix?

Regards,
Qingfang

Re: [PATCH nf-next] netfilter: flowtable: dedicated slab for flow entry

[Florian Westphal]

Qingfang Deng <dqfext@gmail.com> wrote:
> On Thu, Jan 29, 2026 at 6:26 PM Florian Westphal <fw@strlen.de> wrote:
> > Ok, but please use KMEM_CACHE(), we've had a bunch of patches
> > that removed kmem_cache_create() in several places, I would like
> > to avoid a followup patch.
> 
> But I'm creating a slab with a different name (`nf_flow_offload`) from
> the struct name (`flow_offload`). Should I keep the `nf_` prefix?

Then add a comment that its intentional due to the name, else
we'll get a followup 'cleanup patch' to switch to KMEM_CACHE().