From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 29 08:33:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEBCD16A4CE for ; Sun, 29 Feb 2004 08:33:51 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF61443D1F for ; Sun, 29 Feb 2004 08:33:50 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i1TGWhDL047221; Sun, 29 Feb 2004 11:32:43 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i1TGWh1j047218; Sun, 29 Feb 2004 11:32:43 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 29 Feb 2004 11:32:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20040229001251.Q11460@odysseus.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: RE: em0, polling performance, P4 2.8ghz FSB 800mhz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 16:33:52 -0000 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