Re: [PATCH] aggressive early_drop and reserved conntrack entries

[Patrick Schaaf <bof@bof.de>]

Hi,

> 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
connection.

best regards
  Patrick