[PATCH] aggressive early_drop and reserved conntrack entries
bof at bof.de
Thu Dec 9 12:29:13 CET 2004
> > > - 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?
Well, the way I see it, the primary task, under pressure, is still to
run ASSURED connections as good as possible. Burning more CPU in
early_drop for each new potential connection (at possibly high rate,
when under a real DoS attempt), will take significant time from routing
ASSURED connection's packets.
More information about the netfilter-devel