On Fri, Nov 04, 2016 at 04:54:58PM +0100, Florian Westphal wrote:
> 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').
Applied, thanks a lot Florian.
Tunning this is the hard part of this new workqueue approach IMO, it
should be fine if we need more iterations to revisit this logic.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
