All of lore.kernel.org
 help / color / mirror / Atom feed
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"

  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.com \
    --cc=andi@firstfloor.org \
    --cc=brouer@redhat.com \
    --cc=christoph.paasch@uclouvain.be \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=fw@strlen.de \
    --cc=jbrouer@redhat.com \
    --cc=mph@hoth.dk \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    --cc=therbert@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.