From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 17:40:14 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 B7F1B106566C; Tue, 24 Apr 2012 17:40:14 +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 95C578FC08; Tue, 24 Apr 2012 17:40:14 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id E2285200D3; Tue, 24 Apr 2012 10:41:33 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 24 Apr 2012 10:40:14 -0700 From: "Li, Qing" To: Luigi Rizzo Thread-Topic: Some performance measurements on the FreeBSD network stack Thread-Index: AQHNIhyqmxIlJMdUe0+llxsSqqHVrpaqduMA//+MHgSAAJ5UgP//mxvg Date: Tue, 24 Apr 2012 17:40:13 +0000 Message-ID: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> In-Reply-To: <20120424163423.GA59530@onelab2.iet.unipi.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] 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 17:40:14 -0000 Yup, all good points. In fact we have considered all of these while doing the work. In case you haven't seen it already, we did write about these=20 issues in our paper and how we tried to address those, flow-table was one of the solutions. http://dl.acm.org/citation.cfm?id=3D1592641 --Qing > > > > Well, the routing table no longer maintains any lle info, so there > > isn't much to copy out the rtentry at the completion of route > > lookup. > > > > If I understood you correctly, you do believe there is a lot of value > > in Flowtable caching concept, but you are not suggesting we reverting > > back to having the routing table maintain L2 entries, are you ? >=20 > I see a lot of value in caching in general. >=20 > Especially for a bound socket it seems pointless to lookup the > route, iface and mac address(es) on every single packet instead of > caching them. And, routes and MAC addresses are volatile anyways > so making sure that we do the lookup 1us closer to the actual use > gives no additional guarantee. >=20 > The frequency with which these info (routes and MAC addresses) > change clearly influences the mechanism to validate the cache. > I suppose we have the following options: >=20 > - direct notification: a failure in a direct chain of calls > can be used to invalidate the info cached in the socket. > Similarly, some incoming traffic (e.g. TCP RST, FIN, > ICMP messages) that reach a socket can invalidate the cached values > - assume a minimum lifetime for the info (i think this is what > happens in the flowtable) and flush it unconditionally > every such interval (say 10ms). > - if some info changes infrequently (e.g. MAC addresses) one could > put a version number in the cached value and use it to validate > the cache. >=20 > cheers > luigi