On Thu, Mar 12, 2026 at 5:36 AM Florian Westphal [off-list ref] wrote:

Prasanna S Panchamukhi [off-list ref] wrote:

quoted

The conntrack garbage collection worker uses an adaptive algorithm that
adjusts the scan interval based on the average timeout of tracked
entries.  The upper bound of this interval is hardcoded as
GC_SCAN_INTERVAL_MAX (60 seconds).

Expose the upper bound as a new sysctl,
net.netfilter.nf_conntrack_gc_scan_interval_max, so it can be tuned at
runtime without rebuilding the kernel.  The default remains 60 seconds
to preserve existing behavior.  The sysctl is global and read-only in
non-init network namespaces, consistent with nf_conntrack_max and
nf_conntrack_buckets.

This was proposed before, see:

https://lore.kernel.org/netfilter-devel/aO-id5W6Tr7frdHN@strlen.de/ (local)
https://lore.kernel.org/netfilter-devel/aRsuU57juCvsMBKE@strlen.de/ (local)

I did not hear back wrt. the horizon cache.

I'm not 100% opposed to this, but I do wonder if we really can't do
better than the current avg strategy.

Hi Florian,

Our primary goal is to cap the maximum time taken by the GC to clean
up expired entries. We rely on user-space notifications to clean up
these entries from the hardware, so ensuring a predictable upper bound
is important for our use case.

Regarding the adaptive strategy, we are using this sysctl to address
environments where the current average-based calculation delays the
cleanup of short-lived entries.

Thanks,
Prasanna