From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7A152A0545; Mon, 20 Jun 2022 14:35:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 659514069C; Mon, 20 Jun 2022 14:35:29 +0200 (CEST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2064.outbound.protection.outlook.com [40.107.236.64]) by mails.dpdk.org (Postfix) with ESMTP id 991A040151 for ; Mon, 20 Jun 2022 14:35:27 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CtDDmWJDyJknIYzzgwR18dEoJi0dx9Nm7FDy1a6bzflGw+/gG6zNv6hSOcy4bFiPLqZmRQVfPiCiOx2SXkQu3QhEhp3b9fvDbjTBBjtCVVbxNBSdHP3Sp6VVBzAZpkmN/aIURtPdKxk2biCVbdpURZ93JLV2PN/49cSmyZGM2XaY1VrLZ/CkRlzzgzjaxz7XNBNBgN+29wWGTOlkdz0tPxACtXakjb9Z+fLd+Oi5DIw32U6D3UFdAf6Suy0yY2XVJDbANrz5yG33SrRklTmhULB0LoGPmnxN4JUYYP9XzEypzDubGu8IatfQnvvKxdVpPSIA/Fs+RSPIjENcSsvlkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=u5e6rADogvlmACE4p4t0W039dmvG0GpC0KWyd12BVNA=; b=Rf7gDDRAqUZAfrBE5Kfro+VKL4nZ4Jnyf9YfGla8leTpKWBVJn3AXkuSLpwspfa2s47she6Pa4/fRPh2NpGp5NaU8McWzI7MMG1SOwg0dcGo4oTGTT30XUMApm+/Kz7vw2dnvkTHP3vQKcWz/TlemF27MYDDtbuhptTWzEIZcob4yKaxmUDSAEmU2N7SbAYis0uKQ2rE8WOPplPys5jmTh3sgWk1rtwjS8Yz2O5iYXYhzCZkna68zrEG0F64ypNShw4vZw8xMhWiN4UjFZhYQS6q9lkQoI7Cl9YoJYue8OqBi09D6CJvUf2aNCtum1WCpiQiYZV4KetTgKMYQS3lYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.80.198) smtp.rcpttodomain=huawei.com smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u5e6rADogvlmACE4p4t0W039dmvG0GpC0KWyd12BVNA=; b=Zj7Kx12EPkQ7Q+oi46IFxjBT7HljO8VcuFDvPg0Nx4yTgb2oRWwPp5+yGEmfpiE+UuUFqRx5fWJiQ3WBOaS6hgk9kK8cDeeqezqJjpA/GzWQjwvZStTVSkDoBroa0yoyhOB7chEJgOC5FYlcFKneZ+ACWd47P1XZsJi+fDWXq98= Received: from SA0PR11CA0126.namprd11.prod.outlook.com (2603:10b6:806:131::11) by DM6PR02MB5977.namprd02.prod.outlook.com (2603:10b6:5:156::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.20; Mon, 20 Jun 2022 12:35:20 +0000 Received: from SN1NAM02FT0037.eop-nam02.prod.protection.outlook.com (2603:10b6:806:131:cafe::33) by SA0PR11CA0126.outlook.office365.com (2603:10b6:806:131::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.14 via Frontend Transport; Mon, 20 Jun 2022 12:35:18 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.80.198) smtp.mailfrom=xilinx.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=xilinx.com; Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates 149.199.80.198 as permitted sender) receiver=protection.outlook.com; client-ip=149.199.80.198; helo=xir-pvapexch01.xlnx.xilinx.com; pr=C Received: from xir-pvapexch01.xlnx.xilinx.com (149.199.80.198) by SN1NAM02FT0037.mail.protection.outlook.com (10.97.4.243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5353.14 via Frontend Transport; Mon, 20 Jun 2022 12:35:17 +0000 Received: from xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Mon, 20 Jun 2022 13:35:16 +0100 Received: from smtp.xilinx.com (172.21.105.197) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Mon, 20 Jun 2022 13:35:16 +0100 Envelope-to: lihuisong@huawei.com, xiaoyun.li@intel.com, aman.deep.singh@intel.com, yuying.zhang@intel.com, andrew.rybchenko@oktetlabs.ru, dev@dpdk.org, thomas@monjalon.net, huangdaode@huawei.com Received: from [10.71.119.54] (port=59091) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1o3Gcd-0008So-Rr; Mon, 20 Jun 2022 13:35:16 +0100 Message-ID: <04f8806c-0dfe-67a3-0027-c21465b29a77@xilinx.com> Date: Mon, 20 Jun 2022 13:35:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH V3 app/testpmd 1/4] app/testpmd: fix supported RSS offload display Content-Language: en-US To: "lihuisong (C)" , , , , CC: , , References: <20220429102445.23711-1-lihuisong@huawei.com> <20220607083246.12259-1-lihuisong@huawei.com> <20220607083246.12259-2-lihuisong@huawei.com> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 21ce8465-ae62-4b64-619a-08da52b95550 X-MS-TrafficTypeDiagnostic: DM6PR02MB5977:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0/VD21sm6C1JhCUQNaaYZjsNvQmSLcSvBrVJfF+8FMRPIRWQjKlJ17jaYn5ibR8XHJDKbgFfDwVTC9PNb8+uilApA1ZHOInu4/CvfOt788Sq0BgUnd2r4aNiwX4BTt8JTM6+hNeTX4KNj5iGexkIbS6RtalMurjaqdwUBczvN8MeUu/8s5dUaX3SGvF8v8ATm6eTnWgrs/lXUbkbuOyIP+r/dw6WWwubLuMNZrYmRmjOVGQ5xtDDB4DXQK7uVtCl7cbQsb2APW+XfuOGV2c1K98hNXGh9eRh2XKuzTVmWIIAWTnRZSEHOvbt0EEH5ufUXy20qMdrEnrxYizEtSVNtCkrQOZS2cDt1jlLhSFERnKAQR3IL+ZxmJCKq0wUtSbVjUI8XQybHE9WcX00WwQ0FLEMgXxUemf0jHszd13UtxEJfsJQ+q2NLtZ6WWoAtg4A+7OB8GctjjV1TjSI3Rk2ETZTwBgguTCMQM2oOkL4y0mTCfMUadHJstDr3uTW//DLlE/ccjl9flxw0FEhLxGRVG0Lq2BaUr3L/VvivAOd13eE9mOXBK/Ydvx1AHMj+bvq6AxkiCj2BEcRwtBK3jlp5oo8CykNSQBsR2N9EdjGazViR4cnB3zyHlscevDP1CN48ILm5vhadYM03XmxcVvruRaIvoLOdF5/ruEh1i4KGkiuRuIVEwADwfHSK6j/BuUJPukSoOyu4gMZn5C6CMYKjBrQXpZzM68FWMrGjF+Xwkc7SWMkWWeANcrKaqSPxaeDv/IURxQZtXNAQ3EnsXnnIw== X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch01.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230016)(4636009)(376002)(396003)(39860400002)(136003)(346002)(36840700001)(40470700004)(46966006)(186003)(82740400003)(36860700001)(47076005)(40460700003)(7636003)(356005)(9786002)(54906003)(2616005)(83380400001)(336012)(31696002)(426003)(26005)(4326008)(44832011)(110136005)(53546011)(31686004)(2906002)(36756003)(8936002)(82310400005)(40480700001)(70206006)(70586007)(5660300002)(8676002)(41300700001)(316002)(478600001)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2022 12:35:17.7449 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 21ce8465-ae62-4b64-619a-08da52b95550 X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.80.198]; Helo=[xir-pvapexch01.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT0037.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB5977 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 6/9/2022 4:25 AM, lihuisong (C) wrote: > CAUTION: This message has originated from an External Source. Please use > proper judgment and caution when opening attachments, clicking links, or > responding to this email. > > > 在 2022/6/7 23:45, Ferruh Yigit 写道: >> On 6/7/2022 9:32 AM, Huisong Li wrote: >> >>> >>> And rte_eth_dev_info.flow_type_rss_offloads is populated in terms of >>> RTE_ETH_RSS_* bits. If PMD sets RTE_ETH_RSS_L3_SRC_ONLY to >>> dev_info->flow_type_rss_offloads. testpmd will display "user defined 63" >>> when run 'show port info 0'. Because testpmd use flowtype_to_str() >>> to display the supported RSS offload of PMD. In fact, the function is >>> used to display flow type in FDIR commands. This patch uses the >>> RTE_ETH_RSS_* bits to display supported RSS offload of PMD. >>> >>> Fixes: b12964f621dc ("ethdev: unification of RSS offload types") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Huisong Li >>> Signed-off-by: Ferruh Yigit >>> --- >>>   app/test-pmd/config.c | 85 ++++++++++++++++++++++++++++++++++++++----- >>>   1 file changed, 75 insertions(+), 10 deletions(-) >>> >>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c >>> index 72d2606d19..d290ca3a06 100644 >>> --- a/app/test-pmd/config.c >>> +++ b/app/test-pmd/config.c >>> @@ -86,6 +86,56 @@ static const struct { >>>          }, >>>   }; >>> >>> +const struct rss_type_info rss_offload_table[] = { >>> +       {"ipv4", RTE_ETH_RSS_IPV4}, >>> +       {"ipv4-frag", RTE_ETH_RSS_FRAG_IPV4}, >>> +       {"ipv4-tcp", RTE_ETH_RSS_NONFRAG_IPV4_TCP}, >>> +       {"ipv4-udp", RTE_ETH_RSS_NONFRAG_IPV4_UDP}, >>> +       {"ipv4-sctp", RTE_ETH_RSS_NONFRAG_IPV4_SCTP}, >>> +       {"ipv4-other", RTE_ETH_RSS_NONFRAG_IPV4_OTHER}, >>> +       {"ipv6", RTE_ETH_RSS_IPV6}, >>> +       {"ipv6-frag", RTE_ETH_RSS_FRAG_IPV6}, >>> +       {"ipv6-tcp", RTE_ETH_RSS_NONFRAG_IPV6_TCP}, >>> +       {"ipv6-udp", RTE_ETH_RSS_NONFRAG_IPV6_UDP}, >>> +       {"ipv6-sctp", RTE_ETH_RSS_NONFRAG_IPV6_SCTP}, >>> +       {"ipv6-other", RTE_ETH_RSS_NONFRAG_IPV6_OTHER}, >>> +       {"l2_payload", RTE_ETH_RSS_L2_PAYLOAD}, >>> +       {"ipv6-ex", RTE_ETH_RSS_IPV6_EX}, >>> +       {"ipv6-tcp-ex", RTE_ETH_RSS_IPV6_TCP_EX}, >>> +       {"ipv6-udp-ex", RTE_ETH_RSS_IPV6_UDP_EX}, >>> +       {"port", RTE_ETH_RSS_PORT}, >>> +       {"vxlan", RTE_ETH_RSS_VXLAN}, >>> +       {"geneve", RTE_ETH_RSS_GENEVE}, >>> +       {"nvgre", RTE_ETH_RSS_NVGRE}, >>> +       {"gtpu", RTE_ETH_RSS_GTPU}, >>> +       {"eth", RTE_ETH_RSS_ETH}, >>> +       {"s-vlan", RTE_ETH_RSS_S_VLAN}, >>> +       {"c-vlan", RTE_ETH_RSS_C_VLAN}, >>> +       {"esp", RTE_ETH_RSS_ESP}, >>> +       {"ah", RTE_ETH_RSS_AH}, >>> +       {"l2tpv3", RTE_ETH_RSS_L2TPV3}, >>> +       {"pfcp", RTE_ETH_RSS_PFCP}, >>> +       {"pppoe", RTE_ETH_RSS_PPPOE}, >>> +       {"ecpri", RTE_ETH_RSS_ECPRI}, >>> +       {"mpls", RTE_ETH_RSS_MPLS}, >>> +       {"ipv4-chksum", RTE_ETH_RSS_IPV4_CHKSUM}, >>> +       {"l4-chksum", RTE_ETH_RSS_L4_CHKSUM}, >>> +       {"l2tpv2", RTE_ETH_RSS_L2TPV2}, >>> +       {"l3-pre96", RTE_ETH_RSS_L3_PRE96}, >>> +       {"l3-pre64", RTE_ETH_RSS_L3_PRE64}, >>> +       {"l3-pre56", RTE_ETH_RSS_L3_PRE56}, >>> +       {"l3-pre48", RTE_ETH_RSS_L3_PRE48}, >>> +       {"l3-pre40", RTE_ETH_RSS_L3_PRE40}, >>> +       {"l3-pre32", RTE_ETH_RSS_L3_PRE32}, >>> +       {"l2-dst-only", RTE_ETH_RSS_L2_DST_ONLY}, >>> +       {"l2-src-only", RTE_ETH_RSS_L2_SRC_ONLY}, >>> +       {"l4-dst-only", RTE_ETH_RSS_L4_DST_ONLY}, >>> +       {"l4-src-only", RTE_ETH_RSS_L4_SRC_ONLY}, >>> +       {"l3-dst-only", RTE_ETH_RSS_L3_DST_ONLY}, >>> +       {"l3-src-only", RTE_ETH_RSS_L3_SRC_ONLY}, >>> +       {NULL, 0}, >>> +}; >>> + >> >> Hi Huisong, >> >> Why not reusing existing 'rss_type_table[]', but adding a new one? >> Is it to have each individual RSS type instead of grouping >> 'rss_type_table[]' has? If so, since command "port config all rss ..." >> using the grouping, I think it makes sense to have grouping. >> > The 'rss_offload_table[]' includes all defined RSS offloads in ethdev > layer, every iterm has one bit, > and is part of 'rss_type_table[]'. Some iterms in 'rss_type_table[]' > consist of multiple bits. If we > want to display all RSS offloads PMD supported and resolve undefined > offload, we have to check > 'flow_type_rss_offloads' bit by bit. However, "port config all rss ..." > and "show port 0 rss-hash" > commands supports the configuration and display of multiple offload bits > at a time. So it is necessary > to introduce this 'rss_offload_table[]' to display > 'flow_type_rss_offloads'. That's what I think. 'rss_type_table[]' has both group and individual types, so show functions displays both. A sample of grouping is UDP, a few UDP flags compined under UDP, #define RTE_ETH_RSS_UDP ( \ RTE_ETH_RSS_NONFRAG_IPV4_UDP | \ RTE_ETH_RSS_NONFRAG_IPV6_UDP | \ RTE_ETH_RSS_IPV6_UDP_EX) Above mentioned commands use 'RTE_ETH_RSS_UDP' to set "udp" type RSS, and when displying instead of displaying each above type separately, I think displaying as "udp" makes sense. And again I believe having two different arrays is prone to error for future. >> Another thing is having two different array with very similar content >> is easy to confuse and can cause diversion on arrays and generate bugs. >> > Add some notes about the use of the 'rss_offload_table[]'? >> >> As mentioned from "port config all rss ..." command, it seems it is >> also not using 'rss_type_table[]', but all string to RSS type matching >> done within the function ('cmd_config_rss_parsed()') duplicating what >> we have in 'rss_type_table[]'. Again this has concern to diverge >> between set and show functions. >> If you have time for it, can you make an additional patch to update >> 'cmd_config_rss_parsed()' to use new 'str_to_rsstypes()' function? > All right. Let's fix it. Thanks, and if you want it can be a separate patch on top of this one, it doesn't have to be part of this set if you don't have time for it. >> >> Thanks, >> ferruh >> >>>   const struct rss_type_info rss_type_table[] = { >>>          { "all", RTE_ETH_RSS_ETH | RTE_ETH_RSS_VLAN | RTE_ETH_RSS_IP >>> | RTE_ETH_RSS_TCP | >>>                  RTE_ETH_RSS_UDP | RTE_ETH_RSS_SCTP | >>> RTE_ETH_RSS_L2_PAYLOAD | >>> @@ -675,6 +725,19 @@ print_dev_capabilities(uint64_t capabilities) >>>          } >>>   } >>> >>> +static const char * >>> +rss_offload_to_str(uint64_t rss_offload) >>> +{ >>> +       uint16_t i; >>> + >>> +       for (i = 0; rss_offload_table[i].str != NULL; i++) { >>> +               if (rss_offload_table[i].rss_type == rss_offload) >>> +                       return rss_offload_table[i].str; >>> +       } >>> + >>> +       return NULL; >>> +} >>> + >>>   void >>>   port_infos_display(portid_t port_id) >>>   { >>> @@ -779,19 +842,21 @@ port_infos_display(portid_t port_id) >>>          if (!dev_info.flow_type_rss_offloads) >>>                  printf("No RSS offload flow type is supported.\n"); >>>          else { >>> +               uint64_t rss_offload_types = >>> dev_info.flow_type_rss_offloads; >>>                  uint16_t i; >>> -               char *p; >>> >>>                  printf("Supported RSS offload flow types:\n"); >>> -               for (i = RTE_ETH_FLOW_UNKNOWN + 1; >>> -                    i < sizeof(dev_info.flow_type_rss_offloads) * >>> CHAR_BIT; i++) { >>> -                       if (!(dev_info.flow_type_rss_offloads & (1ULL >>> << i))) >>> -                               continue; >>> -                       p = flowtype_to_str(i); >>> -                       if (p) >>> -                               printf("  %s\n", p); >>> -                       else >>> -                               printf("  user defined %d\n", i); >>> +               for (i = 0; i < sizeof(rss_offload_types) * CHAR_BIT; >>> i++) { >>> +                       uint64_t rss_offload = RTE_BIT64(i); >>> +                       if ((rss_offload_types & rss_offload) != 0) { >>> +                               const char *p = >>> + rss_offload_to_str(rss_offload); >>> +                               if (p) >>> +                                       printf("  %s\n", p); >>> +                               else >>> +                                       printf("  user defined >>> 0x%"PRIx64"\n", >>> +                                              rss_offload); >>> +                       } >> >> If you go with 'rss_type_table[]', you need to change above logic as >> you did in your v2. >> >>>                  } >>>          } >>> >>> -- >>> 2.33.0 >>> >> >> .