From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 14:16:19 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF4C8106564A; Tue, 24 Apr 2012 14:16:19 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8D39E8FC0A; Tue, 24 Apr 2012 14:16:19 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id C2EE5200C8; Tue, 24 Apr 2012 07:17:36 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Tue, 24 Apr 2012 07:16:19 -0700 From: "Li, Qing" To: Luigi Rizzo Thread-Topic: Some performance measurements on the FreeBSD network stack Thread-Index: AQHNIhyqmxIlJMdUe0+llxsSqqHVrpaqduMA//+MHgQ= Date: Tue, 24 Apr 2012 14:16:18 +0000 Message-ID: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <4F96A7C0.3010909@freebsd.org>, <20120424140228.GA58809@onelab2.iet.unipi.it> In-Reply-To: <20120424140228.GA58809@onelab2.iet.unipi.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.133.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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: Tue, 24 Apr 2012 14:16:19 -0000 >=0A= >From previous tests, the difference between flowtable and=0A= >routing table was small with a single process (about 5% or 50ns=0A= >in the total packet processing time, if i remember well),=0A= >but there was a large gain with multiple concurrent processes.=0A= >=0A= =0A= Yes, that sounds about right when we did the tests a long while ago.=0A= =0A= >=0A= > Removing flowtable increases the cost in ip_output()=0A= > (obviously) but also in ether_output() (because the=0A= > route does not have a lle entry so you need to call=0A= > arpresolve on each packet). =0A= >=0A= =0A= Yup.=0A= =0A= >=0A= > So in revising the route lookup i believe it would be good=0A= > if we could also get at once most of the info that=0A= > ether_output() is computing again and again.=0A= >=0A= =0A= Well, the routing table no longer maintains any lle info, so there=0A= isn't much to copy out the rtentry at the completion of route=0A= lookup.=0A= =0A= If I understood you correctly, you do believe there is a lot of value=0A= in Flowtable caching concept, but you are not suggesting we reverting=0A= back to having the routing table maintain L2 entries, are you ?=0A= =0A= --Qing=0A=