From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 21:26:14 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E7EF1065744 for ; Thu, 19 Apr 2012 21:26:14 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A1CA88FC15 for ; Thu, 19 Apr 2012 21:26:13 +0000 (UTC) Received: (qmail 15631 invoked from network); 19 Apr 2012 21:21:26 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Apr 2012 21:21:26 -0000 Message-ID: <4F908327.5070905@freebsd.org> Date: Thu, 19 Apr 2012 23:27:03 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "K. Macy" References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <4F907FB4.3080400@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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: Thu, 19 Apr 2012 21:26:14 -0000 On 19.04.2012 23:17, K. Macy wrote: >>> This only helps if your flows aren't hitting the same rtentry. >>> Otherwise you still convoy on the lock for the rtentry itself to >>> increment and decrement the rtentry's reference count. >> >> >> The rtentry lock isn't obtained anymore. While the rmlock read >> lock is held on the rtable the relevant information like ifp and >> such is copied out. No later referencing possible. In the end >> any referencing of an rtentry would be forbidden and the rtentry >> lock can be removed. The second step can be optional though. > > Can you point me to a tree where you've made these changes? It's not in a public tree. I just did a 'svn up' and the recent pf and rtsocket changes created some conflicts. Have to solve them before posting. Timeframe (early) next week. >>>> i was wondering, is there a way (and/or any advantage) to use the >>>> fastforward code to look up the route for locally sourced packets ? >>>> >>> >>> If the number of peers is bounded then you can use the flowtable. Max >>> PPS is much higher bypassing routing lookup. However, it doesn't scale >>> to arbitrary flow numbers. >> >> >> In theory a rmlock-only lookup into a default-route only routing >> table would be faster than creating a flow table entry for every >> destination. It a matter of churn though. The flowtable isn't >> lockless in itself, is it? > > It is. In a steady state where the working set of peers fits in the > table it should be just a simple hash of the ip and then a lookup. Yes, but the lookup requires a lock? Or is every entry replicated to every CPU? So a number of concurrent CPU's sending to the same UDP destination would content on that lock? -- Andre