From: Florian Westphal <fw@strlen•de>
To: Nicolas Dichtel <nicolas.dichtel@6wind•com>
Cc: Florian Westphal <fw@strlen•de>,
davem@davemloft•net, pablo@netfilter•org, netdev@vger•kernel.org,
netfilter-devel@vger•kernel.org
Subject: Re: [PATCH net 2/2] conntrack: enable to tune gc parameters
Date: Fri, 14 Oct 2016 12:37:26 +0200 [thread overview]
Message-ID: <20161014103726.GA10404@breakpoint.cc> (raw)
In-Reply-To: <f1df137d-7278-f6fb-3237-1bd20afadb48@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind•com> wrote:
> Le 13/10/2016 à 22:43, Florian Westphal a écrit :
> > Nicolas Dichtel <nicolas.dichtel@6wind•com> wrote:
> >> Le 10/10/2016 à 16:04, Florian Westphal a écrit :
> >>> Nicolas Dichtel <nicolas.dichtel@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.
> I don't understand. GC_MAX_BUCKETS is the upper bound and I agree that it is
> needed. But why GC_MAX_BUCKETS_DIV (ie 1/64)?
> In other words, why this line:
> goal = min(nf_conntrack_htable_size / GC_MAX_BUCKETS_DIV, GC_MAX_BUCKETS);
> instead of:
> goal = GC_MAX_BUCKETS;
Sure, we can do that. But why is a fixed size better than a fraction?
E.g. with 8k buckets and simple goal = GC_MAX_BUCKETS we scan entire
table on every run, currently we only scan 128.
I wanted to keep too many destroy notifications from firing at once
but maybe i was too paranoid...
> > (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'.
> >
> Sure, but this is not a "real" solution, just a workaround.
> We need to find a way to deliver conntrack deletion events in a reasonable
> delay, whatever the traffic on the machine is.
Agree, but that depends on what 'reasonable' means and what kind of
uneeded cpu churn we're willing to add.
We can add a sysctl for this but we should use a low default to not do
too much unneeded work.
So what about your original patch, but only add
nf_conntrack_gc_interval
(and also add instant-resched in case entire budget was consumed)?
next prev parent reply other threads:[~2016-10-14 10:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 10:18 [PATCH net 0/2] conntrack update Nicolas Dichtel
2016-10-10 10:18 ` [PATCH net 1/2] conntrack: remove obsolete sysctl (nf_conntrack_events_retry_timeout) Nicolas Dichtel
2016-10-10 13:57 ` Florian Westphal
2016-10-17 15:39 ` Pablo Neira Ayuso
2016-10-10 10:18 ` [PATCH net 2/2] conntrack: enable to tune gc parameters Nicolas Dichtel
2016-10-10 14:04 ` Florian Westphal
2016-10-10 15:24 ` Nicolas Dichtel
2016-10-13 20:43 ` Florian Westphal
2016-10-14 10:12 ` Nicolas Dichtel
2016-10-14 10:37 ` Florian Westphal [this message]
2016-10-14 10:53 ` Pablo Neira Ayuso
2016-10-14 11:16 ` Florian Westphal
2016-10-18 8:30 ` [PATCH net] conntrack: perform a full scan in gc Nicolas Dichtel
2016-10-18 8:47 ` Florian Westphal
2016-10-18 10:06 ` Nicolas Dichtel
2016-10-18 12:37 ` [PATCH net] conntrack: restart gc immediately if GC_MAX_EVICTS is reached Nicolas Dichtel
2016-10-19 16:02 ` Florian Westphal
2016-10-19 16:14 ` Pablo Neira Ayuso
2016-10-20 8:50 ` [PATCH net] conntrack: perform a full scan in gc Nicolas Dichtel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161014103726.GA10404@breakpoint.cc \
--to=fw@strlen$(echo .)de \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=netfilter-devel@vger$(echo .)kernel.org \
--cc=nicolas.dichtel@6wind$(echo .)com \
--cc=pablo@netfilter$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox