netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: jamal <hadi@cyberus.ca>
Cc: netdev@oss.sgi.com
Subject: Re: [fw@deneb.enyo.de: Route cache performance under stress]
Date: Sun, 06 Apr 2003 14:08:51 +0200	[thread overview]
Message-ID: <87n0j3ltf0.fsf@deneb.enyo.de> (raw)
In-Reply-To: <20030405180607.P68419@shell.cyberus.ca> (jamal's message of "Sat, 5 Apr 2003 18:48:42 -0500 (EST)")

jamal <hadi@cyberus.ca> writes:

> I meant whoever said that 400pps would cause a DOS. I didnt see the dst
> cache test being described in the source, so i assume it is someone else
> other than people who wrote the tool.

Ah, I see.  I'm sorry for the confusion.

> I skimmed through it and got their message. Yes, i understand the
> implications ;->

Good! 8-)

>> > Is this supposed to cure something?
>>
>> Garbage collection is much more aggressive and the chains attached to
>> the bucket are kept much shorter, so less CPU time is spent processing
>> them.
>
> You may find that aggressive gc is one of your problems infact.

I don't think so.  During a DoS attack with spoofed source addresses,
the dst cache quickly fills up, and the overwhelming majority of the
entries is useless (they won't be used again).  The slabinfo line
looks like this:

ip_dst_cache      116477 131080    192 6554 6554    1

There are only 8192 hash buckets on this system, and if we assume that
the entries are uniformly distributed over the buckets (which is not
necessarily true), the code in ip_route_input() has to look at 14 or
15 cache entries before the miss is detected.  I can hardly see how
this is efficient.

> I dont see the correlation of syn attacks and the dst cache in your
> description. Can you collect some profiles?

On the machine above, the dst cache has 2**17 entries.  Imagine what
happens if all these entries are chained to the same bucket, and the
chain has to be traversed for each packet.

> I know thats what the paper says - but this is exactly what i have
> problems with: In the little study we did, its not the collisions that
> kill us rather the fact we are being forced into the slow path the
> majority of times. Please collect the profiles and send me the tool as
> well.

Okay, I'm going to do this (if I can figure out how to read the
profiling data).

> Our data was collected on a real ISP which hosts a lot of web
> servers and was being constantly DOSed. I dont think you can get
> more real world than that.

Did you look at a router, or at a host?

  reply	other threads:[~2003-04-06 12:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-05 16:50 [fw@deneb.enyo.de: Route cache performance under stress] bert hubert
2003-04-05 19:02 ` jamal
2003-04-05 22:55   ` Florian Weimer
2003-04-05 23:48     ` jamal
2003-04-06 12:08       ` Florian Weimer [this message]
2003-04-06 15:14         ` jamal
2003-04-06 16:42           ` Florian Weimer
2003-04-06 17:20             ` Robert Olsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87n0j3ltf0.fsf@deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).