From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next 0/3] nfp: flower: speed up stats update loop Date: Wed, 10 Oct 2018 22:33:00 -0700 (PDT) Message-ID: <20181010.223300.2048327590978672766.davem@davemloft.net> References: <20181009015736.30268-1-jakub.kicinski@netronome.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, oss-drivers@netronome.com To: jakub.kicinski@netronome.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:48988 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726070AbeJKM6g (ORCPT ); Thu, 11 Oct 2018 08:58:36 -0400 In-Reply-To: <20181009015736.30268-1-jakub.kicinski@netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Jakub Kicinski Date: Mon, 8 Oct 2018 18:57:33 -0700 > This set from Pieter improves performance of processing FW stats > update notifications. The FW seems to send those at relatively > high rate (roughly ten per second per flow), therefore if we want > to approach the million flows mark we have to be very careful > about our data structures. > > We tried rhashtable for stat updates, but according to our experiments > rhashtable lookup on a u32 takes roughly 60ns on an Xeon E5-2670 v3. > Which translate to a hard limit of 16M lookups per second on this CPU, > and, according to perf record jhash and memcmp account for 60% of CPU > usage on the core handling the updates. > > Given that our statistic IDs are already array indices, and considering > each statistic is only 24B in size, we decided to forego the use > of hashtables and use a directly indexed array. The CPU savings are > considerable. > > With the recent improvements in TC core and with our own bottlenecks > out of the way Pieter removes the artificial limit of 128 flows, and > allows the driver to install as many flows as FW supports. Series applied.