From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 13:21:59 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 4529A106564A; Tue, 17 Jul 2012 13:21:59 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 985888FC17; Tue, 17 Jul 2012 13:21:58 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q6HDLtxn023268; Tue, 17 Jul 2012 20:21:55 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <500566F3.9050101@rdtc.ru> Date: Tue, 17 Jul 2012 20:21:55 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Konstantin Belousov References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <20120716232352.GE2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120716232352.GE2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Luigi Rizzo , Doug Barton , "Alexander V. Chernikov" , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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, 17 Jul 2012 13:21:59 -0000 17.07.2012 06:23, Konstantin Belousov пишет: > I do not think that your 'per-cpu' counter are correct. The thread > migration or rescheduling causes the fetch or update of the wrong > per-cpu structure. This allows parallel updates with undefined > consequences. >From practical point of view, I'like to state that most of us do NOT need scientifically exact ipfw counters values when pushing hardware to its maximum. Personaly, I'd like to have tunable that gives me another 15% of speed at cost of bad ipfw counters I don't use anyway. Eugene Grosbein