From: Hans Schillstrom <hans.schillstrom@ericsson•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Rick Jones <rick.jones2@hp•com>, Andi Kleen <andi@firstfloor•org>,
Jesper Dangaard Brouer <jbrouer@redhat•com>,
Jesper Dangaard Brouer <brouer@redhat•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
Christoph Paasch <christoph.paasch@uclouvain•be>,
"David S. Miller" <davem@davemloft•net>,
Martin Topholm <mph@hoth•dk>, Florian Westphal <fw@strlen•de>,
Tom Herbert <therbert@google•com>
Subject: Re: [RFC PATCH 2/2] tcp: Early SYN limit and SYN cookie handling to mitigate SYN floods
Date: Thu, 31 May 2012 10:45:00 +0200 [thread overview]
Message-ID: <201205311045.03556.hans.schillstrom@ericsson.com> (raw)
In-Reply-To: <1338452917.2760.1309.camel@edumazet-glaptop>
On Thursday 31 May 2012 10:28:37 Eric Dumazet wrote:
> On Wed, 2012-05-30 at 14:20 -0700, Rick Jones wrote:
>
> > It may still be high, but a very quick netperf TCP_CC test over loopback
> > on a W3550 system running a 2.6.38 kernel shows:
> >
> > raj@tardy:~/netperf2_trunk/src$ ./netperf -t TCP_CC -l 60 -c -C
> > TCP Connect/Close TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> > localhost.localdomain () port 0 AF_INET
> > Local /Remote
> > Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem
> > Send Recv Size Size Time Rate local remote local remote
> > bytes bytes bytes bytes secs. per sec % % us/Tr us/Tr
> >
> > 16384 87380 1 1 60.00 21515.29 30.68 30.96 57.042 57.557
> > 16384 87380
> >
> > 57 microseconds per "transaction" which in this case is establishing and
> > tearing-down the connection, with nothing else (no data packets) makes
> > 19 microseconds for a SYN seem perhaps not all that beyond the realm of
> > possibility?
>
> Thats a different story, on loopback device (without stressing IP route
> cache by the way)
>
> Your netperf test is a full userspace transactions, and 5 frames per
> transaction. Two sockets creation/destruction, process scheduler
> activations, and not enter syncookie mode.
>
> In case of synflood/(syncookies on), we receive a packet and send one
> from softirq.
>
> One expensive thing might be the md5 to compute the SYNACK sequence.
>
> I suspect other things :
>
> 1) Of course we have to take into account the timer responsible for
> SYNACK retransmits of previously queued requests. Its cost depends on
> the listen backlog. When this timer runs, listen socket is locked.
>
> 2) IP route cache overflows.
> In case of SYNFLOOD, we should not store dst(s) in route cache but
> destroy them immediately.
>
I can see plenty "IPv4: dst cache overflow"
next prev parent reply other threads:[~2012-05-31 8:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-28 11:52 [RFC PATCH 0/2] Faster/parallel SYN handling to mitigate SYN floods Jesper Dangaard Brouer
2012-05-28 11:52 ` [RFC PATCH 1/2] tcp: extract syncookie part of tcp_v4_conn_request() Jesper Dangaard Brouer
2012-05-28 11:52 ` [RFC PATCH 2/2] tcp: Early SYN limit and SYN cookie handling to mitigate SYN floods Jesper Dangaard Brouer
2012-05-29 19:37 ` Andi Kleen
2012-05-29 20:18 ` David Miller
2012-05-30 6:41 ` Eric Dumazet
2012-05-30 7:45 ` Jesper Dangaard Brouer
2012-05-30 8:15 ` Eric Dumazet
2012-05-30 9:24 ` Jesper Dangaard Brouer
2012-05-30 9:46 ` Eric Dumazet
2012-05-30 8:03 ` Hans Schillstrom
2012-05-30 8:24 ` Eric Dumazet
2012-05-30 11:14 ` Hans Schillstrom
2012-05-30 21:20 ` Rick Jones
2012-05-31 8:28 ` Eric Dumazet
2012-05-31 8:45 ` Hans Schillstrom [this message]
2012-05-31 14:09 ` Eric Dumazet
2012-05-31 15:31 ` Hans Schillstrom
2012-05-31 17:16 ` Eric Dumazet
2012-05-28 16:14 ` [RFC PATCH 0/2] Faster/parallel SYN " Christoph Paasch
2012-05-29 20:17 ` Jesper Dangaard Brouer
2012-05-29 20:36 ` Christoph Paasch
2012-05-30 8:44 ` Jesper Dangaard Brouer
2012-05-30 8:50 ` Eric Dumazet
2012-05-30 8:53 ` Christoph Paasch
2012-05-30 22:40 ` Jesper Dangaard Brouer
2012-05-31 12:51 ` Jesper Dangaard Brouer
2012-05-31 12:58 ` Eric Dumazet
2012-05-31 13:04 ` Jesper Dangaard Brouer
2012-05-31 13:10 ` Eric Dumazet
2012-05-31 13:24 ` Jesper Dangaard Brouer
2012-05-30 4:45 ` Eric Dumazet
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=201205311045.03556.hans.schillstrom@ericsson.com \
--to=hans.schillstrom@ericsson$(echo .)com \
--cc=andi@firstfloor$(echo .)org \
--cc=brouer@redhat$(echo .)com \
--cc=christoph.paasch@uclouvain$(echo .)be \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=fw@strlen$(echo .)de \
--cc=jbrouer@redhat$(echo .)com \
--cc=mph@hoth$(echo .)dk \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rick.jones2@hp$(echo .)com \
--cc=therbert@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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