Nicolas Dichtel <nicolas.dich...@6wind.com> wrote:
> Le 10/10/2016 à 16:04, Florian Westphal a écrit :
> > Nicolas Dichtel <nicolas.dich...@6wind.com> wrote:
> >> After commit b87a2f9199ea ("netfilter: conntrack: add gc worker to remove
> >> timed-out entries"), netlink conntrack deletion events may be sent with a
> >> huge delay. It could be interesting to let the user tweak gc parameters
> >> depending on its use case.
> >
> > Hmm, care to elaborate?
> >
> > I am not against doing this but I'd like to hear/read your use case.
> >
> > The expectation is that in almot all cases eviction will happen from
> > packet path. The gc worker is jusdt there for case where a busy system
> > goes idle.
> It was precisely that case. After a period of activity, the event is sent a
> long
> time after the timeout. If the router does not manage a lot of flows, why not
> trying to parse more entries instead of the default 1/64 of the table?
> In fact, I don't understand why using GC_MAX_BUCKETS_DIV instead of using
> always
> GC_MAX_BUCKETS whatever the size of the table is.
I wanted to make sure that we have a known upper bound on the number of
buckets we process so that we do not block other pending kworker items
for too long.
(Or cause too many useless scans)
Another idea worth trying might be to get rid of the max cap and
instead break early in case too many jiffies expired.
I don't want to add sysctl knobs for this unless absolutely needed; its already
possible to 'force' eviction cycle by running 'conntrack -L'.
