Re: [PATCH net-next] netfilter: conntrack: expose gc_scan_interval_max via sysctl

[Pablo Neira Ayuso]

Hi Prasanna,

On Thu, Mar 12, 2026 at 03:31:06PM -0700, Prasanna Panchamukhi wrote:
> On Thu, Mar 12, 2026 at 5:36 AM Florian Westphal <fw@xxxxxxxxx> wrote:
> >
> > Prasanna S Panchamukhi <panchamukhi@xxxxxxxxxx> wrote:
> > > 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@xxxxxxxxx/
> > https://lore.kernel.org/netfilter-devel/aRsuU57juCvsMBKE@xxxxxxxxx/
> >
> > 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.

Is there any reason why you decide not to use instead the existing
hardware offload infrastructure for this purpose?