Re: [PATCH] aggressive early_drop and reserved conntrack entries

[Patrick Schaaf <bof@bof.de>]

Hi Jozsef,

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

best regards
  Patrick