From owner-svn-src-all@FreeBSD.ORG Mon Apr 20 10:33:06 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56CCD106566C; Mon, 20 Apr 2009 10:33:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1DC8FC14; Mon, 20 Apr 2009 10:33:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id BC2BC46B1A; Mon, 20 Apr 2009 06:33:05 -0400 (EDT) Date: Mon, 20 Apr 2009 11:33:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: <3c1674c90904200001s1d03c7d8udcd2dd4cf99984fd@mail.gmail.com> Message-ID: References: <200904190444.n3J4i5wF098362@svn.freebsd.org> <200904192221.55744.zec@freebsd.org> <3c1674c90904191405v56298134g286ea31ee4680769@mail.gmail.com> <200904200844.12344.zec@freebsd.org> <3c1674c90904200001s1d03c7d8udcd2dd4cf99984fd@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, Andre Oppermann , svn-src-all@freebsd.org, src-committers@freebsd.org, Marko Zec Subject: Re: svn commit: r191259 - head/sys/netinet X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 10:33:06 -0000 On Mon, 20 Apr 2009, Kip Macy wrote: >> ... which means you fall back to the ordinary routing lookups, but only >> after you have wasted cycles to compute a hash and found out that it >> doesn't match anything in your cache -> in this case I would expect only a >> degradation in performance, not an improvement. > > If your normal operating conditions are DDOS then you have more serious > problems. I said that the system would not collapse as you were in fact > claiming, not that it would perform optimally. I think a useful test case to exercise this would be to look at the performance of a real-world benchmark during a simulated synflood from spoofed source IPs in which you gradually scale up the size of the source IP pool for the synflood, as compared to running without the flowcache. The overhead of all the flowcache misses should, presumably, be quite noticeable once it overflows, as it adds additional locking and lookups (both of which have historically been very noticeable) I think the important question is not whether we can measure the overhead (if we can't then we're not testing right), but whether it leads to a performance collapse that didn't previously exist. Robert N M Watson Computer Laboratory University of Cambridge