From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 20:40:57 2006 Return-Path: X-Original-To: current@freebsd.org 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 CD49116A41F; Sat, 7 Jan 2006 20:40:57 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5818243D45; Sat, 7 Jan 2006 20:40:57 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4/8.13.4) with ESMTP id k07KeviA095628; Sat, 7 Jan 2006 12:40:57 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4/8.13.4/Submit) id k07KetMR095625; Sat, 7 Jan 2006 12:40:55 -0800 (PST) Date: Sat, 7 Jan 2006 12:40:55 -0800 (PST) From: Matthew Dillon Message-Id: <200601072040.k07KetMR095625@apollo.backplane.com> To: Scott Long References: <73774.1136109554@critter.freebsd.dk> <20060101035958.A86264@xorpc.icir.org> <43B7E1EC.5090301@mac.com> <200601060636.k066aNYn079015@apollo.backplane.com> <43BFEB2E.4040303@freebsd.org> <200601071940.k07JeHt3095158@apollo.backplane.com> <43C02362.2070009@samsco.org> Cc: Andre Oppermann , current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jan 2006 20:40:58 -0000 : :Matthew Dillon wrote: :[...] : :I'm about to release a patch to Andre that should allow if_em to fast :forward 1mpps or more on his hardware, using no shortcuts or hacks other :than the inherent shortcut that the ffwd code provides. The approach :I'm taking also works on the other high performance network interfaces. :There is also a lot of work going on to streamline the ifnet layer that :will likely result in several hundred nanoseconds of latency being :removed from there. I'd personally love to see DragonFly approach this :level of performance. Given that it took FreeBSD about 3-4 years to :slog through setting up and validating a new architecture before we :could start focusing on performance, I think that DFly is right on track :on the same schedule. Hopefully the results are as worthwhile on DFly :in the future as they are on FreeBSD right now. : :Scott I think it's very possible. We have taken pains to retain the fast-forwarding architecture (i.e. direct lookups, no context switches, handle everything in the interrupt) and to greatly reduce mbuf allocation overheads (e.g. by using Jeff's objcache infrastructure, which is an algorithmic port of Sun's objcache infrastructure). There are three areas of interest for us in this architecutre: (1) Route table lookups. This is basically a non-problem because Jeff already has a per-cpu route table replication patch that will allow us to do route table lookups without having to obtain or release any locks or perform any bus locked instructions. (2) Per-interface serializer (mutex). Right now the core packet processing loop must release the originating interface serializer and obtain the target interface serializer to forward a packet, then release the target and re-obtain the originating. Clearly this can be cleaned up by aggregating packets processed by the originating interface and only doing the swap-a-roo once for N packets. The current code is a migratory 'hack' until the whole network subsystem can be moved to the new network interface serializer. Right now only the network interrupt subsystem has been moved to the new serializer, so networking code is holding both the MP lock AND the serializer. (3) The IP filter / firewall code is the last big item we are going to have a problem with. I intend to remove at least one of the packet filters we support and do per-cpu replication for the remainder. It turns out that most of the packet filter can be replicated, even dynamically generated rules and queues and such. But its a lot of work. -Matt Matthew Dillon