08d9c92027
When packet is a SYN packet, we don't need to modify any existing PCB. Normally SYN arrives on a listening socket, we either create a syncache entry or generate syncookie, but we don't modify anything with the listening socket or associated PCB. Thus create a new PCB lookup mode - rlock if listening. This removes the primary contention point under SYN flood - the listening socket PCB. Sidenote: when SYN arrives on a synchronized connection, we still don't need write access to PCB to send a challenge ACK or just to drop. There is only one exclusion - tcptw recycling. However, existing entanglement of tcp_input + stacks doesn't allow to make this change small. Consider this patch as first approach to the problem. Reviewed by: rrs Differential revision: https://reviews.freebsd.org/D29576 |
||
---|---|---|
.. | ||
dest6.c | ||
frag6.c | ||
icmp6.c | ||
icmp6.h | ||
in6_cksum.c | ||
in6_fib_algo.c | ||
in6_fib.c | ||
in6_fib.h | ||
in6_gif.c | ||
in6_ifattach.c | ||
in6_ifattach.h | ||
in6_jail.c | ||
in6_mcast.c | ||
in6_pcb.c | ||
in6_pcb.h | ||
in6_pcbgroup.c | ||
in6_proto.c | ||
in6_rmx.c | ||
in6_rss.c | ||
in6_rss.h | ||
in6_src.c | ||
in6_var.h | ||
in6.c | ||
in6.h | ||
ip6_ecn.h | ||
ip6_fastfwd.c | ||
ip6_forward.c | ||
ip6_gre.c | ||
ip6_id.c | ||
ip6_input.c | ||
ip6_mroute.c | ||
ip6_mroute.h | ||
ip6_output.c | ||
ip6_var.h | ||
ip6.h | ||
ip6protosw.h | ||
ip_fw_nat64.h | ||
ip_fw_nptv6.h | ||
mld6_var.h | ||
mld6.c | ||
mld6.h | ||
nd6_nbr.c | ||
nd6_rtr.c | ||
nd6.c | ||
nd6.h | ||
pim6_var.h | ||
pim6.h | ||
raw_ip6.c | ||
raw_ip6.h | ||
route6.c | ||
scope6_var.h | ||
scope6.c | ||
sctp6_usrreq.c | ||
sctp6_var.h | ||
send.c | ||
send.h | ||
tcp6_var.h | ||
udp6_usrreq.c | ||
udp6_var.h |