Date: Sun, 29 Feb 2004 11:32:43 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Mike Silbersack <silby@silby.com> Cc: freebsd-hackers@freebsd.org Subject: RE: em0, polling performance, P4 2.8ghz FSB 800mhz Message-ID: <Pine.NEB.3.96L.1040229112851.24114d-100000@fledge.watson.org> In-Reply-To: <20040229001251.Q11460@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Feb 2004, Mike Silbersack wrote: > On Sat, 28 Feb 2004, Don Bowman wrote: > > > this would only allow 2 concurrent TCP sessions per unique > > source address. Depends on the syn flood you are expecting > > to experience. You could also use dummynet to shape syn > > traffic to a fixed level i suppose. > > Does that really help? If so, we need to optimize the syncache. :( Given that we have syncookie support, the other thing we could consider doing under high syn load is simply to drop the syncache from the loop entirely. The syncache provides us with the ability to "gracefully degrade" as the syn rate goes up, but the FIFO cache bucket overflow handling means we pay the cost of syncache entry allocation even in the high load situation. It might be interesting to measure when syncache overflow is taking place, and simply drop it from the loop under a rate known to exceed the syncache capacity, then re-enable it again once the rate drops. This would remove a memory allocation, queue walking, and in the case of an SMP system, locking, from the syn handling path. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040229112851.24114d-100000>