From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
To: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf v4] netfilter: conntrack: refine gc worker heuristics
Date: Fri, 4 Nov 2016 17:16:52 +0100 [thread overview]
Message-ID: <469da164-eaa5-8257-1099-cc9d7932fdff@6wind.com> (raw)
In-Reply-To: <1478274898-24605-1-git-send-email-fw@strlen.de>
Le 04/11/2016 à 16:54, Florian Westphal a écrit :
> Nicolas Dichtel says:
> After commit b87a2f9199ea ("netfilter: conntrack: add gc worker to
> remove timed-out entries"), netlink conntrack deletion events may be
> sent with a huge delay.
>
> Nicolas further points at this line:
>
> goal = min(nf_conntrack_htable_size / GC_MAX_BUCKETS_DIV, GC_MAX_BUCKETS);
>
> and indeed, this isn't optimal at all. Rationale here was to ensure that
> we don't block other work items for too long, even if
> nf_conntrack_htable_size is huge. But in order to have some guarantee
> about maximum time period where a scan of the full conntrack table
> completes we should always use a fixed slice size, so that once every
> N scans the full table has been examined at least once.
>
> We also need to balance this vs. the case where the system is either idle
> (i.e., conntrack table (almost) empty) or very busy (i.e. eviction happens
> from packet path).
>
> So, after some discussion with Nicolas:
>
> 1. want hard guarantee that we scan entire table at least once every X s
> -> need to scan fraction of table (get rid of upper bound)
>
> 2. don't want to eat cycles on idle or very busy system
> -> increase interval if we did not evict any entries
>
> 3. don't want to block other worker items for too long
> -> make fraction really small, and prefer small scan interval instead
>
> 4. Want reasonable short time where we detect timed-out entry when
> system went idle after a burst of traffic, while not doing scans
> all the time.
> -> Store next gc scan in worker, increasing delays when no eviction
> happened and shrinking delay when we see timed out entries.
>
> The old gc interval is turned into a max number, scans can now happen
> every jiffy if stale entries are present.
>
> Longest possible time period until an entry is evicted is now 2 minutes
> in worst case (entry expires right after it was deemed 'not expired').
>
> Reported-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Thank you,
Nicolas
next prev parent reply other threads:[~2016-11-04 16:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 15:54 [PATCH nf v4] netfilter: conntrack: refine gc worker heuristics Florian Westphal
2016-11-04 16:16 ` Nicolas Dichtel [this message]
2016-11-08 23:04 ` Pablo Neira Ayuso
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=469da164-eaa5-8257-1099-cc9d7932fdff@6wind.com \
--to=nicolas.dichtel@6wind.com \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.