[PATCH] aggressive early_drop and reserved conntrack entries
bof at bof.de
Thu Dec 9 09:52:50 CET 2004
> The included patch addresses the following issues:
> - When the conntrack table is full, we search only in a single hash
> bucket. We are in trouble anyway, so let's search harder for
> droppable entries: the patch extends the search to at most the third of
> all the buckets.
Hmm. It's correct that we are in trouble anyway, but will it help burning
much more CPU to get out of trouble?
Looking for alternatives, I note that early_drop will only consider
unreplied connections for reaping. In a normal setup, only a small
number of connections will be unreplied, AND each connection will
make at most one transition from unreplied to assured.
This suggest, to me, that we keep unreplied connections on a new,
additional list. They are put there at the HEAD upon creation,
they are removed form the list when they make their transition
to assured. And early_drop becomes a simple, O(1) operation:
reap the connection which is at the TAIL of this new list.
Of course, it's a tradeoff between burning (lots of) CPU when under
pressure, vs. two list operations per connection for each and every
More information about the netfilter-devel