From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 14:42:52 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id EECEE106566B; Wed, 18 Jul 2012 14:42:51 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id A9FAC14EA9C; Wed, 18 Jul 2012 14:42:49 +0000 (UTC) Message-ID: <5006CAFC.1000206@FreeBSD.org> Date: Wed, 18 Jul 2012 18:41:00 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eugene Grosbein 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> <500566F3.9050101@rdtc.ru> In-Reply-To: <500566F3.9050101@rdtc.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , Doug Barton , Luigi Rizzo , 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: Wed, 18 Jul 2012 14:42:52 -0000 On 17.07.2012 17:21, Eugene Grosbein wrote: > 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. It seems that this can be done even with sysctl. The same approach can be applied to per-cpu interface counters (and global per-protocol statistics). > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- WBR, Alexander