From owner-freebsd-net@FreeBSD.ORG Mon Jul 7 23:03:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F679106564A for ; Mon, 7 Jul 2008 23:03:56 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from atlas.gtcomm.net (atlas.gtcomm.net [67.215.15.242]) by mx1.freebsd.org (Postfix) with ESMTP id 040B48FC1C for ; Mon, 7 Jul 2008 23:03:55 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from c-76-108-197-4.hsd1.fl.comcast.net ([76.108.197.4] helo=[192.168.1.6]) by atlas.gtcomm.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KFzgU-0006sS-M3; Mon, 07 Jul 2008 18:59:50 -0400 Message-ID: <4872A155.70606@gtcomm.net> Date: Mon, 07 Jul 2008 19:05:57 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Artem Belevich References: <4867420D.7090406@gtcomm.net> <486FFF70.3090402@gtcomm.net> <48701921.7090107@gtcomm.net> <4871E618.1080500@freebsd.org> <20080708002228.G680@besplex.bde.org> <48724238.2020103@freebsd.org> <20080708034304.R21502@delplex.bde.org> <20080708045135.V1022@besplex.bde.org> <48727BA9.6020702@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Julian Elischer Subject: Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2008 23:03:56 -0000 We could add this as a part of the fastforwarding code and for a router turn it on and for a server leave it off. When I use a FBSD box for a router, it doesn't do anything else, so there could be two optimized paths that is one for routing/forwarding/firewalling only and one for use as a server. Artem Belevich wrote: >> Prefetching when you are waiting for the data isn't a help. >> > > Agreed. Got to start prefetch around ns > before you actually need the data and move on doing other things that > do not depend on the data you've just started prefetching. > > >> what you need is a speculative prefetch where you an tell teh processor "We >> will probably need the following address so start getting it while we go do >> other stuff". >> > > It does not have to be 'speculative' either. In this particular case > we have very good idea that we *will* need some data from ethernet > header and, probably, IP and TCP headers as well. We might as well tel > the hardware to start pulling data in without stalling the CPU. Intel > has instructions specifically for this purpose. I assume AMD has them > too. > > --Artem > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >