From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0F7EC3565B for ; Fri, 21 Feb 2020 18:22:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BA04920722 for ; Fri, 21 Feb 2020 18:22:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582309324; bh=EB3RCy+KkbrCa0bZvqvuVZ+vD2rifSO3C97ioE4E808=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=vVh+Mew+zx/loxtBniYTsLZDVGoPTpmz1HTTdxgssDCiX9tIYgSb31Dp1cuMau1xb EB98yyj3VNWAWfNf6BrvD1SrJz1MukEU9S59C5jjPFIKpbeESH52pJjmH0pu+cyLrj DsSM7YtoU5lKb7MhAldFmazGFEhz0Be2uFQma16A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729566AbgBUSWD (ORCPT ); Fri, 21 Feb 2020 13:22:03 -0500 Received: from mail.kernel.org ([198.145.29.99]:34238 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727966AbgBUSWD (ORCPT ); Fri, 21 Feb 2020 13:22:03 -0500 Received: from kicinski-fedora-PC1C0HJN (unknown [163.114.132.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3630C206E2; Fri, 21 Feb 2020 18:22:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582309323; bh=EB3RCy+KkbrCa0bZvqvuVZ+vD2rifSO3C97ioE4E808=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OMrbdBxiSCuSen5OTFY5Uj3YZzdkbztZ5qpMsMmI2MJ97LJHqF/jniBNa5bZZjM5m ShMgtMhqTda93WYql5cAiQakSKoB9IrmLH7G9jnTa0aAYWFDYhISpyZBsNMvlN8oSf mTYQYnaBlwLDXsogyl3Kbm0VFVGP6JpaOaZc5eho= Date: Fri, 21 Feb 2020 10:22:00 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: netdev@vger.kernel.org, davem@davemloft.net, saeedm@mellanox.com, leon@kernel.org, michael.chan@broadcom.com, vishal@chelsio.com, jeffrey.t.kirsher@intel.com, idosch@mellanox.com, aelior@marvell.com, peppe.cavallaro@st.com, alexandre.torgue@st.com, jhs@mojatatu.com, xiyou.wangcong@gmail.com, pablo@netfilter.org, mlxsw@mellanox.com, Edward Cree Subject: Re: [patch net-next 00/10] net: allow user specify TC filter HW stats type Message-ID: <20200221102200.1978e10e@kicinski-fedora-PC1C0HJN> In-Reply-To: <20200221095643.6642-1-jiri@resnulli.us> References: <20200221095643.6642-1-jiri@resnulli.us> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 21 Feb 2020 10:56:33 +0100 Jiri Pirko wrote: > From: Jiri Pirko > > Currently, when user adds a TC filter and the filter gets offloaded, > the user expects the HW stats to be counted and included in stats dump. > However, since drivers may implement different types of counting, there > is no way to specify which one the user is interested in. > > For example for mlx5, only delayed counters are available as the driver > periodically polls for updated stats. > > In case of mlxsw, the counters are queried on dump time. However, the > HW resources for this type of counters is quite limited (couple of > thousands). This limits the amount of supported offloaded filters > significantly. Without counter assigned, the HW is capable to carry > millions of those. > > On top of that, mlxsw HW is able to support delayed counters as well in > greater numbers. That is going to be added in a follow-up patch. > > This patchset allows user to specify one of the following types of HW > stats for added fitler: > any - current default, user does not care about the type, just expects > any type of stats. > immediate - queried during dump time > delayed - polled from HW periodically or sent by HW in async manner > disabled - no stats needed Hmm, but the statistics are on actions, it feels a little bit like we are perpetuating the mistake of counting on filters here. Would it not work to share actions between filters which don't need fine grained stats if HW can do more filters than stats? Let's CC Ed on this.