[PATCH] aggressive early_drop and reserved conntrack entries

Jozsef Kadlecsik kadlec at blackhole.kfki.hu
Thu Dec 9 11:34:16 CET 2004


On Thu, 9 Dec 2004, Patrick Schaaf wrote:

> > - 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?

How could we lessen the trouble we are in? By refusing to add the new
connection to the table after failing to find an unreplied connection
in one bucket, or searching more with the price of spinning the CPU a
little further?

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

Plus another struct list_head element in struct ip_conntrack.

But I like it! Hmm, expect some new code soon...

Best regards,
E-mail  : kadlec at blackhole.kfki.hu, kadlec at sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

More information about the netfilter-devel mailing list