From owner-freebsd-current@FreeBSD.ORG Fri May 7 17:01:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 099D216A4CE for ; Fri, 7 May 2004 17:01:53 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE69343D41 for ; Fri, 7 May 2004 17:01:43 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 54584 invoked from network); 8 May 2004 00:01:43 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.47]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 May 2004 00:01:43 -0000 Message-ID: <409C2366.4010307@freebsd.org> Date: Sat, 08 May 2004 02:01:42 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Gerrit Nagelhout Subject: Re: 4.7 vs 5.2.1 SMP/UP bridging performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2004 00:01:53 -0000 Robert Watson wrote: > Something I'd like to explore in detail is a careful comparison of > performing delivery to completion in the interrupt thread vs using a set > of netisr threads pinned to CPUs. Avoiding lots of context switches is a > good thing, but I don't have any measurements that suggest at what layer > in the inbound packet path we get the most coallescing: we know interrupt > mitigation and coallescing works well at a high level, but are we > currently seeing substantial coallescing due to long-running interrupt > threads, handoffs to netisrs, etc? Some decent measurements with counters > at each of the hand-off points might go a long way. For the IP packet forwarding case you can profile normal forwarding against ip_fastforwarding (netinet/ip_fastfwd.c). IP fast forwarding processes to completion from the interrupt thread. If you don't have ipfw or pfil compiled in or active the only locking it will do is for the routing table lookup. To get that down best is to have just one route, the default route. sysctl -w net.inet.ip.fast_forwarding=1 Fast forwarding gives some nice speedups and reduces the variance in packet processing quite a bit. I've measured a reduction of CPU usage for forwarding of approx. 40% on my old (now decomissioned) Athlon 900MHz with two fxp interfaces with link0 enabled. Haven't profiled on my new Dual-Opteron 1.4GHz with two bge interfaces yet. -- Andre