netdev - Re: [RFC PATCH 0/2] Faster/parallel SYN handling to mitigate SYN floods

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1338470653.7747.178.camel@localhost>
Date:	Thu, 31 May 2012 15:24:13 +0200
From:	Jesper Dangaard Brouer <jbrouer@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	christoph.paasch@...ouvain.be, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Martin Topholm <mph@...h.dk>, Florian Westphal <fw@...len.de>,
	Hans Schillstrom <hans.schillstrom@...csson.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC PATCH 0/2] Faster/parallel SYN handling to mitigate SYN
 floods

On Thu, 2012-05-31 at 15:10 +0200, Eric Dumazet wrote:
> On Thu, 2012-05-31 at 14:58 +0200, Eric Dumazet wrote:
> 
> > 
> > How many different IP addresses are used by your generator ?
> > 
> > Or maybe you disabled IP route cache ?
> 
> With no route cache problems, I sustain 4 us per SYN packet, if all load
> serviced by one cpu only.

Yes that is also my experience, in this SYN-flood scenario one CPU does
a lot better.  My old home brew AMD quad-core CPU also outperform, the
big testlab machine dual socket quad-core Nehalem.

The route cache problem, should not be too big with my SYN cookie
solution.  I think... as tcp_v4_send_synack() handles alloc of a dst
route cache, but also releases it immediately afterwards.

How do you/I measure the usec per packet?

How do I disable the route cache?

What test tools do you use?
(I have modified pktgen to send TCP SYN packets)

(ps. I'll post my updated patch series, in a bit, and then I'll try not
to disturb your work on the fully parallel solution).



> perf profile is : (I have CONFIG_DEBUG_PAGEALLOC=y)
> 
> +   9,55%  ksoftirqd/0  [kernel.kallsyms]  [k] sha_transform
> +   3,56%  ksoftirqd/0  [kernel.kallsyms]  [k] ip_route_input_common
> +   3,40%  ksoftirqd/0  [kernel.kallsyms]  [k] __ip_route_output_key
> +   3,28%  ksoftirqd/0  [kernel.kallsyms]  [k] __inet_lookup_established
> +   3,13%  ksoftirqd/0  [kernel.kallsyms]  [k] tg3_poll_work
> +   2,68%  ksoftirqd/0  [kernel.kallsyms]  [k] tcp_make_synack
> +   2,67%  ksoftirqd/0  [kernel.kallsyms]  [k] __netif_receive_skb
> +   2,51%  ksoftirqd/0  [kernel.kallsyms]  [k] ipt_do_table
> +   2,17%  ksoftirqd/0  [kernel.kallsyms]  [k] memcpy
> +   1,99%  ksoftirqd/0  [kernel.kallsyms]  [k] kernel_map_pages
> +   1,96%  ksoftirqd/0  [kernel.kallsyms]  [k] inet_csk_search_req
> +   1,69%  ksoftirqd/0  [kernel.kallsyms]  [k] tg3_recycle_rx.isra.36
> +   1,63%  ksoftirqd/0  [kernel.kallsyms]  [k] kmem_cache_free
> +   1,61%  ksoftirqd/0  [kernel.kallsyms]  [k] copy_user_generic_string
> +   1,49%  ksoftirqd/0  [kernel.kallsyms]  [k] kmem_cache_alloc
> +   1,47%  ksoftirqd/0  [kernel.kallsyms]  [k] ip_rcv
> +   1,11%  ksoftirqd/0  [kernel.kallsyms]  [k] tcp_v4_conn_request
> +   1,07%  ksoftirqd/0  [kernel.kallsyms]  [k] nf_iterate
> +   1,07%      swapper  [kernel.kallsyms]  [k] sha_transform
> +   1,05%  ksoftirqd/0  [kernel.kallsyms]  [k] kfree
> +   1,05%  ksoftirqd/0  [kernel.kallsyms]  [k] skb_release_data
> +   0,99%  ksoftirqd/0  [kernel.kallsyms]  [k] __alloc_skb
> +   0,98%  ksoftirqd/0  [kernel.kallsyms]  [k] __kmalloc_node_track_caller
> +   0,97%  ksoftirqd/0  [kernel.kallsyms]  [k] netdev_alloc_frag
> +   0,96%  ksoftirqd/0  [kernel.kallsyms]  [k] dev_gro_receive
> +   0,94%  ksoftirqd/0  [kernel.kallsyms]  [k] inet_gro_receive
> +   0,85%  ksoftirqd/0  [kernel.kallsyms]  [k] build_skb
> +   0,85%  ksoftirqd/0  [kernel.kallsyms]  [k] cookie_v4_init_sequence
> +   0,85%  ksoftirqd/0  [kernel.kallsyms]  [k] ip_build_and_send_pkt
> +   0,84%  ksoftirqd/0  [kernel.kallsyms]  [k] __copy_skb_header
> +   0,82%  ksoftirqd/0  [kernel.kallsyms]  [k] nf_hook_slow
> +   0,77%  ksoftirqd/0  [kernel.kallsyms]  [k] __skb_clone
> +   0,73%  ksoftirqd/0  [kernel.kallsyms]  [k] tcp_v4_rcv
> +   0,72%  ksoftirqd/0  [kernel.kallsyms]  [k] xfrm_lookup
> +   0,69%  ksoftirqd/0  [kernel.kallsyms]  [k] dev_hard_start_xmit
> +   0,68%  ksoftirqd/0  [kernel.kallsyms]  [k] local_bh_enable
> +   0,67%  ksoftirqd/0  [kernel.kallsyms]  [k] tcp_gro_receive
> +   0,67%  ksoftirqd/0  [kernel.kallsyms]  [k] kfree_skb
> +   0,67%  ksoftirqd/0  [kernel.kallsyms]  [k] __probe_kernel_read
> +   0,67%  ksoftirqd/0  [kernel.kallsyms]  [k] skb_release_head_state
> +   0,66%  ksoftirqd/0  [kernel.kallsyms]  [k] __phys_addr
> +   0,66%  ksoftirqd/0  [kernel.kallsyms]  [k] ip_finish_output
> +   0,65%  ksoftirqd/0  [kernel.kallsyms]  [k] dst_release
> +   0,64%  ksoftirqd/0  [kernel.kallsyms]  [k] __ip_local_out
> +   0,61%  ksoftirqd/0  [kernel.kallsyms]  [k] packet_rcv_spkt
> +   0,57%  ksoftirqd/0  [kernel.kallsyms]  [k] __kfree_skb


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html