From owner-freebsd-net@FreeBSD.ORG Sat May 17 14:44:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3604F65; Sat, 17 May 2014 14:44:32 +0000 (UTC) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28C3028D8; Sat, 17 May 2014 14:44:31 +0000 (UTC) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKU3d1yRQ4mfjkdO4/nYcUMTwPNb8Zx3uB@postini.com; Sat, 17 May 2014 07:44:32 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s4HEiLqK012362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 May 2014 10:44:24 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sat, 17 May 2014 10:44:21 -0400 From: "Bentkofsky, Michael" To: "'freebsd-net@freebsd.org'" Subject: Re: [rfc] tcp timer update for RSS Thread-Topic: Re: [rfc] tcp timer update for RSS Thread-Index: Ac9x2wm0XVYCeE+tS3KGThdtBwSzYA== Date: Sat, 17 May 2014 14:44:20 +0000 Message-ID: <080FBD5B7A09F845842100A6DE79623346F2EB44@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "'Adrian Chadd \(adrian@freebsd.org\)'" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 14:44:32 -0000 Hi Adrian, I haven't had the chance to look this over carefully yet as we're at BSDCan= . I think I understand what you're trying to achieve by aligning the per-CP= U timer processing per core. In principal that sounds reasonable, although = I am unsure if you were trying to solve a particular performance issue with= this particular change. My sense is this is all preparatory with the goal = of all inp processing to become per core. Could you comment on the general = evolution you're considering? Do most of the PCB structures become per-core= , as in PCB groups? If you'd like us to test this change, I'm happy to do so. At the moment I d= on't know if we'd expect to see any benefit - do you have any traffic condi= tions for which this showed any difference? But we can certainly drive many= hundreds of thousands of connections at reasonably high connection rates i= f that will help. Thanks, Mike