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=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 5A8A5C433E0 for ; Wed, 24 Jun 2020 12:44:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 30FB720836 for ; Wed, 24 Jun 2020 12:44:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=mojatatu-com.20150623.gappssmtp.com header.i=@mojatatu-com.20150623.gappssmtp.com header.b="ADAC9Nm+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390877AbgFXMoj (ORCPT ); Wed, 24 Jun 2020 08:44:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388942AbgFXMoi (ORCPT ); Wed, 24 Jun 2020 08:44:38 -0400 Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12BABC061573 for ; Wed, 24 Jun 2020 05:44:38 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id u12so1482280qth.12 for ; Wed, 24 Jun 2020 05:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=K+GGZXKgpzdCsUctXsT0qtaMFmUhAglO46kKwDBE35k=; b=ADAC9Nm+AjdV8L4TTS7PIGLMY15VNal3PX2tkETlMZKLDRFTA5Zq7fyeasnJFbp8aQ u35RXtvdaqiOl2B34/rDKVfk/KU5yGbvLGjLj5uBbsgbgxlieYKMYe61G7Aa3nJSqNsJ aSS1D/M+o9/ClQ8ZDo9o+Cm+Ywc+anYTuJfGUyz91nsTQAtPlOnm+eEintzNQG/V67me duDxwZV4JBFW67bkT02/tyvtt63LcTnGQu03PsWedd0d7bGH4vD2mrADYMwcQpgn8Tw9 CBSjxkARtflMFT8a0pxLNB3Ihb+pE571AonOVTeiVD9S+18zwm1RX5bPUeYKjJEuo3Om USUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=K+GGZXKgpzdCsUctXsT0qtaMFmUhAglO46kKwDBE35k=; b=kxEqoRjTeYk3kklM0sKBxw+sTOTPHPAdpOsJlqXyKC/06azT+4KEHEx67Q0FZyQ88+ dI2/CGUGEGZvavxokWNg9WNlK+W3xHcGwMi1b9pnnLeaUwF++TIprJ0IBsNW9uQ63y92 9Xx0N7Zr0aKHFyFq+mD3kncgoXT0u/9HIUMiUoRY0MHMQNrJaU8iJ4IuU2fjytsP3NKM 4OmRU4i+2CEVNJQUP+3wtU1wj7i6G99Q4n5ba5mlz0jM+LuDL7rhfBo2ukxybu+1LjGF l492LG7himWxEM0/3uJZje1vPKeqHm+otc34nD+rHtekpb38MLlyKF2mcuWdWLZIDZn6 F2hA== X-Gm-Message-State: AOAM530+k0lOiO11ZxXB0YL9fYui86Xzsn6X8zLTBaQUiSZtjXwkVEb7 z1VoYze35+cV6ElQq24YAkr8/w== X-Google-Smtp-Source: ABdhPJyQIqA1QaiDwKbaPsVfBf/aqoPaaAgynomS8v8sVwttSlNATi+gb0yJ2j0k/hkgTxeCYTLIeQ== X-Received: by 2002:ac8:794c:: with SMTP id r12mr26584071qtt.201.1593002677309; Wed, 24 Jun 2020 05:44:37 -0700 (PDT) Received: from [192.168.1.117] (23-233-27-60.cpe.pppoe.ca. [23.233.27.60]) by smtp.googlemail.com with ESMTPSA id f65sm1914390qtd.61.2020.06.24.05.44.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 05:44:36 -0700 (PDT) Subject: Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading To: Po Liu , "davem@davemloft.net" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "idosch@idosch.org" Cc: "jiri@resnulli.us" , "vinicius.gomes@intel.com" , "vlad@buslov.dev" , Claudiu Manoil , Vladimir Oltean , Alexandru Marginean , "michael.chan@broadcom.com" , "vishal@chelsio.com" , "saeedm@mellanox.com" , "leon@kernel.org" , "jiri@mellanox.com" , "idosch@mellanox.com" , "alexandre.belloni@bootlin.com" , "UNGLinuxDriver@microchip.com" , "kuba@kernel.org" , "xiyou.wangcong@gmail.com" , "simon.horman@netronome.com" , "pablo@netfilter.org" , "moshe@mellanox.com" , "m-karicheri2@ti.com" , "andre.guedes@linux.intel.com" , "stephen@networkplumber.org" , Edward Cree References: From: Jamal Hadi Salim Message-ID: <18e0ceb0-7cc7-12cc-624d-286cfbd70b94@mojatatu.com> Date: Wed, 24 Jun 2020 08:44:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-23 7:52 p.m., Po Liu wrote: > Hi Jamal, > > >>>> My question: Is this any different from how stats are structured? >>> [..] >> My question: Why cant you apply the same semantics for the counters? >> Does your hardware have an indexed counter/stats table? If yes then you > > Yes, That is the point i was trying to get to. Basically: You have a counter table which is referenced by "index" You also have a meter/policer table which is referenced by "index". For policers, they maintain their own stats. So when i say: tc ... flower ... action police ... index 5 The index referred to is in the policer table But for other actions, example when i say: tc ... flower ... action drop index 10 The index is in the counter/stats table. It is not exactly "10" in hardware, the driver magically hides it from the user - so it could be hw counter index 1234 The old approach is to assume the classifier (flower in this case) has a counter. The reason for this assumption is older hardware was designed to deal with a single action per match. So a counter to the filter is also the counter to the (single) action. I get the feeling your hardware fits in that space. Modern use cases have evolved from the ACL single match and action approach. Maintaining the old thought/architecture breaks in two use cases: 1) when you have multiple actions per policy filter. You need counter-per-action for various reasons 2) Sharing of counters across filters and action. This can be achieve tc supports the above and is sufficient to cover the old use cases. I am just worried, architecturally, we are restricting ourselves to the old scheme. Another reason this is important is for the sake of analytics. A user space app can poll just for the stats table in hardware (or the cached version in the kernel) and reduce the amount of data crossing to user space.. cheers, jamal