Message ID | 20230203135349.547933-1-horatiu.vultur@microchip.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp851679wrn; Fri, 3 Feb 2023 05:59:57 -0800 (PST) X-Google-Smtp-Source: AK7set/pM4fW9tCRwxnY7rg9SE2uWV65fFsy39JDddefMtFE3XpZvJ8Q04Jz3QRFa80wVJlYCFPL X-Received: by 2002:a17:906:1711:b0:87b:cdab:988e with SMTP id c17-20020a170906171100b0087bcdab988emr8650345eje.21.1675432797766; Fri, 03 Feb 2023 05:59:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675432797; cv=none; d=google.com; s=arc-20160816; b=WZgKeb84eUKh3VqOYhpJySRIXjmKXG7hyWTWwhLf4rwbmjX+keXqycoZF3ZZ7qdS1M RRiR9kqhvOkWKr2ClwT39LegLm15Oi34gMRA7HMRSS70+Pb3NOrsj5sRzwSYuezQ1Dk/ /nD9FkrDOTavvsT7OdLa+8hWrwe2dHdNk70WoKtpgjTPYiWy6G9X9VofAYwZV2M03qQg 8WXAhYSKbMA0mKz6EHsZHSz+Bq9YjyXKo2SSzdTfwWStOVggFMDhZxBHrrG8Y7dispEw 7qc4gnx69rjnarxR5MzDGHb3dMzyv4a84bs+ibWZ+m0uezPTGsPgcNIrOPJYov/IP9TS 5/Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=7wFbg0m1OIFrWxFH15oWtQRWddvtbZxluP2QzcoyedA=; b=RBoiAMFFwq5nEGkXxqQPlXwWoIgl1oFhymmowAHZXBMhgGJNr64tB3TWarFsedKdeY crP5YJk0BlNj37OxxnRxqjKUaytB5X2TkEtz8f96WCvx5oZiBMW74Pk8bPCq7M5JE5Wv VRhmRpAGhaUeit2W/IlbJD6uaRCzxvuVo+w+Q2fGSsnNoSNXVy4NLTt2y2ZO2i9FadV3 +mcORAVoqT8wyXHSPuLq4k1SrN+dHX+ialmNGYu4NBYQ3Y6F9mbR2rCmthRanSCWZOQ9 Z3k0uITes9W/2BAP9zmxIK7po5eKprCDUCFcpl8nq/fdn++tdGmTfhbiQPaWnsGzQkSx VkQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=eril3ttf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fc5-20020a1709073a4500b0088ee2ea34eesi3048020ejc.534.2023.02.03.05.59.33; Fri, 03 Feb 2023 05:59:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=eril3ttf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233743AbjBCN6s (ORCPT <rfc822;il.mystafa@gmail.com> + 99 others); Fri, 3 Feb 2023 08:58:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233501AbjBCN6W (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 3 Feb 2023 08:58:22 -0500 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38EB6367C2; Fri, 3 Feb 2023 05:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1675432526; x=1706968526; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=rIIg/IhlSVLPsYHvAR3Cvku2ssnOgIgRQx10yRFmoAM=; b=eril3ttfAskTZId75yc/tIeuE34nAsg0iovXXl1grp+NVn6AtoiA2H7Q w3VcQNbDh+hmvsKP1wBF+SPwiB6ziM/7Tp2Nx7svC6Uor9qjr8Kis82Wu a+nTh+NNHQ16PBSNDEbsW+ujS8J7AvDotDb/weckVOg7rwOtxAlwH5OXh FqjnVZfXJNAhK2RHTPKIUigDZWJ5dXvLu54Gk9PW3rPiOXbOz28mTghMl kjg1GIifEN6SsIRPOna5d40Jlw+QjC66DckQ3jxtrP27cIUA+Qmel5v1m XMnk/sF8qNbuWPwHKFwvJabeP86UKJFlYavQY6tGWBk9R3ahd+m3WlYWP A==; X-IronPort-AV: E=Sophos;i="5.97,270,1669100400"; d="scan'208";a="195249582" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa4.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 03 Feb 2023 06:54:07 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Fri, 3 Feb 2023 06:53:57 -0700 Received: from soft-dev3-1.microsemi.net (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2507.16 via Frontend Transport; Fri, 3 Feb 2023 06:53:56 -0700 From: Horatiu Vultur <horatiu.vultur@microchip.com> To: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> CC: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>, <UNGLinuxDriver@microchip.com>, Horatiu Vultur <horatiu.vultur@microchip.com> Subject: [PATCH net-next] net: lan966x: Add support for TC flower filter statistics Date: Fri, 3 Feb 2023 14:53:49 +0100 Message-ID: <20230203135349.547933-1-horatiu.vultur@microchip.com> X-Mailer: git-send-email 2.38.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756818621476808798?= X-GMAIL-MSGID: =?utf-8?q?1756818621476808798?= |
Series |
[net-next] net: lan966x: Add support for TC flower filter statistics
|
|
Commit Message
Horatiu Vultur
Feb. 3, 2023, 1:53 p.m. UTC
Add flower filter packet statistics. This will just read the TCAM
counter of the rule, which mention how many packages were hit by this
rule.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
---
.../microchip/lan966x/lan966x_tc_flower.c | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
Comments
On Fri, Feb 03, 2023 at 02:53:49PM +0100, Horatiu Vultur wrote: > Add flower filter packet statistics. This will just read the TCAM > counter of the rule, which mention how many packages were hit by this > rule. I am curious to know how HW stats only updating the packet count interacts with SW stats also incrementing other values, such as the byte count. > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> > --- > .../microchip/lan966x/lan966x_tc_flower.c | 22 +++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c b/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c > index 88c655d6318fa..aac3d7c87f1d5 100644 > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c > @@ -234,6 +234,26 @@ static int lan966x_tc_flower_del(struct lan966x_port *port, > return err; > } > > +static int lan966x_tc_flower_stats(struct lan966x_port *port, > + struct flow_cls_offload *f, > + struct vcap_admin *admin) > +{ > + struct vcap_counter count; > + int err; > + > + memset(&count, 0, sizeof(count)); nit: As was pointed out to me recently it's simpler to declare count as follows and skip the memset entirely. No need to respin for this! struct vcap_counter count = {}; > + > + err = vcap_get_rule_count_by_cookie(port->lan966x->vcap_ctrl, > + &count, f->cookie); > + if (err) > + return err; > + > + flow_stats_update(&f->stats, 0x0, count.value, 0, 0, > + FLOW_ACTION_HW_STATS_IMMEDIATE); > + > + return err; > +} > + > int lan966x_tc_flower(struct lan966x_port *port, > struct flow_cls_offload *f, > bool ingress) > @@ -252,6 +272,8 @@ int lan966x_tc_flower(struct lan966x_port *port, > return lan966x_tc_flower_add(port, f, admin, ingress); > case FLOW_CLS_DESTROY: > return lan966x_tc_flower_del(port, f, admin); > + case FLOW_CLS_STATS: > + return lan966x_tc_flower_stats(port, f, admin); > default: > return -EOPNOTSUPP; > } > -- Also, not strictly related, but could you consider, as a favour to reviewers, fixing the driver so that the following doesn't fail: $ make drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o DESCEND objtool CALL scripts/checksyscalls.sh CC drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o In file included from drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c:3: drivers/net/ethernet/microchip/lan966x/lan966x_main.h:18:10: fatal error: vcap_api.h: No such file or directory 18 | #include <vcap_api.h> | ^~~~~~~~~~~~ compilation terminated.
The 02/04/2023 18:12, Simon Horman wrote: > > On Fri, Feb 03, 2023 at 02:53:49PM +0100, Horatiu Vultur wrote: > > Add flower filter packet statistics. This will just read the TCAM > > counter of the rule, which mention how many packages were hit by this > > rule. > > I am curious to know how HW stats only updating the packet count > interacts with SW stats also incrementing other values, such as the byte > count. First, our HW can count only the packages and not also the bytes, unfortunately. Also we use the flag 'skip_sw' when we add the rules in this case the statistics look OK. If the user doesn't use the skip_sw then the statistics will look something like this (using command: tc -s filter show dev eth0 ingress): Action statistics: Sent 92 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) Sent software 92 bytes 2 pkt Sent hardware 0 bytes 2 pkt backlog 0b 0p requeues 0 used_hw_stats immediate As you see there are different counters for SW and Hw statistics. > > > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> > > --- > > .../microchip/lan966x/lan966x_tc_flower.c | 22 +++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c b/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c > > index 88c655d6318fa..aac3d7c87f1d5 100644 > > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c > > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c > > @@ -234,6 +234,26 @@ static int lan966x_tc_flower_del(struct lan966x_port *port, > > return err; > > } > > > > +static int lan966x_tc_flower_stats(struct lan966x_port *port, > > + struct flow_cls_offload *f, > > + struct vcap_admin *admin) > > +{ > > + struct vcap_counter count; > > + int err; > > + > > + memset(&count, 0, sizeof(count)); > > nit: As was pointed out to me recently it's simpler to declare > count as follows and skip the memset entirely. > No need to respin for this! > > struct vcap_counter count = {}; Good to know this. > > > + > > + err = vcap_get_rule_count_by_cookie(port->lan966x->vcap_ctrl, > > + &count, f->cookie); > > + if (err) > > + return err; > > + > > + flow_stats_update(&f->stats, 0x0, count.value, 0, 0, > > + FLOW_ACTION_HW_STATS_IMMEDIATE); > > + > > + return err; > > +} > > + > > int lan966x_tc_flower(struct lan966x_port *port, > > struct flow_cls_offload *f, > > bool ingress) > > @@ -252,6 +272,8 @@ int lan966x_tc_flower(struct lan966x_port *port, > > return lan966x_tc_flower_add(port, f, admin, ingress); > > case FLOW_CLS_DESTROY: > > return lan966x_tc_flower_del(port, f, admin); > > + case FLOW_CLS_STATS: > > + return lan966x_tc_flower_stats(port, f, admin); > > default: > > return -EOPNOTSUPP; > > } > > -- > > Also, not strictly related, but could you consider, as a favour to > reviewers, fixing the driver so that the following doesn't fail: > > $ make drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > DESCEND objtool > CALL scripts/checksyscalls.sh > CC drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > In file included from drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c:3: > drivers/net/ethernet/microchip/lan966x/lan966x_main.h:18:10: fatal error: vcap_api.h: No such file or directory > 18 | #include <vcap_api.h> > | ^~~~~~~~~~~~ > compilation terminated. I will try to have a look at this.
On Mon, Feb 06, 2023 at 10:52:27AM +0100, Horatiu Vultur wrote: > The 02/04/2023 18:12, Simon Horman wrote: > > > > On Fri, Feb 03, 2023 at 02:53:49PM +0100, Horatiu Vultur wrote: > > > Add flower filter packet statistics. This will just read the TCAM > > > counter of the rule, which mention how many packages were hit by this > > > rule. > > > > I am curious to know how HW stats only updating the packet count > > interacts with SW stats also incrementing other values, such as the byte > > count. > > First, our HW can count only the packages and not also the bytes, > unfortunately. Also we use the flag 'skip_sw' when we add the rules in > this case the statistics look OK. > If the user doesn't use the skip_sw then the statistics will look > something like this (using command: tc -s filter show dev eth0 ingress): > > Action statistics: > Sent 92 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) > Sent software 92 bytes 2 pkt > Sent hardware 0 bytes 2 pkt > backlog 0b 0p requeues 0 > used_hw_stats immediate > > As you see there are different counters for SW and Hw statistics. Thanks, that answers my question. I appreciate that hw has limitations, and this does seem to be an appropriate solution in this case. > > > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> ... > > Also, not strictly related, but could you consider, as a favour to > > reviewers, fixing the driver so that the following doesn't fail: > > > > $ make drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > > DESCEND objtool > > CALL scripts/checksyscalls.sh > > CC drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > > In file included from drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c:3: > > drivers/net/ethernet/microchip/lan966x/lan966x_main.h:18:10: fatal error: vcap_api.h: No such file or directory > > 18 | #include <vcap_api.h> > > | ^~~~~~~~~~~~ > > compilation terminated. > > I will try to have a look at this. Thanks, much appreciated.
The 02/06/2023 10:59, Simon Horman wrote: > > > > Also, not strictly related, but could you consider, as a favour to > > > reviewers, fixing the driver so that the following doesn't fail: > > > > > > $ make drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > > > DESCEND objtool > > > CALL scripts/checksyscalls.sh > > > CC drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > > > In file included from drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c:3: > > > drivers/net/ethernet/microchip/lan966x/lan966x_main.h:18:10: fatal error: vcap_api.h: No such file or directory > > > 18 | #include <vcap_api.h> > > > | ^~~~~~~~~~~~ > > > compilation terminated. > > > > I will try to have a look at this. > > Thanks, much appreciated. Sorry for coming back to this, but it seems that I can't reproduce the issue: $ make drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o CALL scripts/checksyscalls.sh DESCEND objtool CC drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o I have tried different configurations without any luck. Any suggestion on how to reproduce the issue?
On Mon, Feb 06, 2023 at 11:32:52AM +0100, Horatiu Vultur wrote: > The 02/06/2023 10:59, Simon Horman wrote: > > > > > > Also, not strictly related, but could you consider, as a favour to > > > > reviewers, fixing the driver so that the following doesn't fail: > > > > > > > > $ make drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > > > > DESCEND objtool > > > > CALL scripts/checksyscalls.sh > > > > CC drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > > > > In file included from drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c:3: > > > > drivers/net/ethernet/microchip/lan966x/lan966x_main.h:18:10: fatal error: vcap_api.h: No such file or directory > > > > 18 | #include <vcap_api.h> > > > > | ^~~~~~~~~~~~ > > > > compilation terminated. > > > > > > I will try to have a look at this. > > > > Thanks, much appreciated. > > Sorry for coming back to this, but it seems that I can't reproduce the > issue: > > $ make drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > CALL scripts/checksyscalls.sh > DESCEND objtool > CC drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o > > I have tried different configurations without any luck. Any suggestion > on how to reproduce the issue? Sorry, perhaps it is something on my side. I tried running through the steps below, which is what I assume I had done last time, but I don't see the problem any more. I'll let you know if it shows up again. But in the meantime sorry for the false reporting. $ git checkout net-next/main $ make allmodconfig $ make prepare $ make drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.o
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c b/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c index 88c655d6318fa..aac3d7c87f1d5 100644 --- a/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_tc_flower.c @@ -234,6 +234,26 @@ static int lan966x_tc_flower_del(struct lan966x_port *port, return err; } +static int lan966x_tc_flower_stats(struct lan966x_port *port, + struct flow_cls_offload *f, + struct vcap_admin *admin) +{ + struct vcap_counter count; + int err; + + memset(&count, 0, sizeof(count)); + + err = vcap_get_rule_count_by_cookie(port->lan966x->vcap_ctrl, + &count, f->cookie); + if (err) + return err; + + flow_stats_update(&f->stats, 0x0, count.value, 0, 0, + FLOW_ACTION_HW_STATS_IMMEDIATE); + + return err; +} + int lan966x_tc_flower(struct lan966x_port *port, struct flow_cls_offload *f, bool ingress) @@ -252,6 +272,8 @@ int lan966x_tc_flower(struct lan966x_port *port, return lan966x_tc_flower_add(port, f, admin, ingress); case FLOW_CLS_DESTROY: return lan966x_tc_flower_del(port, f, admin); + case FLOW_CLS_STATS: + return lan966x_tc_flower_stats(port, f, admin); default: return -EOPNOTSUPP; }