From owner-freebsd-current@FreeBSD.ORG Thu Apr 19 21:11:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D50E1065672 for ; Thu, 19 Apr 2012 21:11:32 +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 6EB7B8FC19 for ; Thu, 19 Apr 2012 21:11:31 +0000 (UTC) Received: (qmail 15491 invoked from network); 19 Apr 2012 21:06:44 -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:06:44 -0000 Message-ID: <4F907FB4.3080400@freebsd.org> Date: Thu, 19 Apr 2012 23:12:20 +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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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-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: Thu, 19 Apr 2012 21:11:32 -0000 On 19.04.2012 22:34, K. Macy wrote: >>> This is indeed a big problem. I'm working (rough edges remain) on >>> changing the routing table locking to an rmlock (read-mostly) which >> > > 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. >> 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? -- Andre