From owner-freebsd-net@FreeBSD.ORG Mon Jul 7 20:25:14 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 F04991065683 for ; Mon, 7 Jul 2008 20:25:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outt.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id D36108FC17 for ; Mon, 7 Jul 2008 20:25:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id BFF0A2408; Mon, 7 Jul 2008 13:25:17 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 9304B2D6006; Mon, 7 Jul 2008 13:25:13 -0700 (PDT) Message-ID: <48727BA9.6020702@elischer.org> Date: Mon, 07 Jul 2008 13:25:13 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Artem Belevich References: <4867420D.7090406@gtcomm.net> <2d3001c8def1$f4309b90$020b000a@bartwrkstxp> <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net 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 20:25:15 -0000 Artem Belevich wrote: > Hi, > > As was already mentioned, we can't avoid all cache misses as there's > data that's recently been updated in memory via DMA and therefor > kicked out of cache. > > However, we may hide some of the latency penalty by prefetching > 'interesting' data early. I.e. we know that we want to access some > ethernet headers, so we may start pulling relevant data into cache > early. Ideally, by the time we need to access the field, it will > already be in the cache. When we're counting nanoseconds per packet > this may bring some performance gain. Prefetching when you are waiting for the data isn't a help. 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". As far as I know we have no capacity to do that.. > > Just my $0.02. > --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"