Skip site navigation (1)Skip section navigation (2)
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>