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 7C2BDA057B; Tue, 28 Jun 2022 15:18:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6AE7D4114B; Tue, 28 Jun 2022 15:18:09 +0200 (CEST) Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02on2070.outbound.protection.outlook.com [40.107.95.70]) by mails.dpdk.org (Postfix) with ESMTP id A0A72400D7 for ; Tue, 28 Jun 2022 15:18:07 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U8pSx7UTQyk3juZgTGR7qxsLqo2jqBQf0K9TJiIv1RXBqxME1Z1x0Rs4Qu6GCn/suojaNcpcexa9+xQ7i4/fBdpBcYNlwB1yQbe5v0wWVp/rNwAUPGTaPIOwp6oR7+12EzogsvNRXh8GMhjCZoxz63wr3fBI0e1JB4SPqUZf7KB3Thq2vwT8Wymhzm/x2sbPKV/QJ4m10UO/XvaKPh1+Lvu4EsQh01sWlAgLaHEfz7DJdxBhUYlsvuLnfv3bpYa7WHGgzAGkeKfoafV1Ew5WZQ3Dq79cED6nwubQ7rY56LZIP6KaVh5W0flWWsn12R/mrd1kw+HJaqPIzMj2Qnnz5g== 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=QiBeiG6SYdRpL5wcPF2wUcrRJ+ICLCfA+0lnX04Nsoo=; b=UnpWtjmey1uOdRKG5n5YMORxoHV90RWyl5TRMKrjOyfcfDLv1ipxidzlc6Pjmg73pIrcjm+kkY0Xplo7eQD0IujwjZrAypifCnSqiz/sJWwTS935s7/TrhUnv32DTi3JmljjKyo3ngFYliuY1Qgyt0DpKzAoBLY8So5DGrZ5jZpHk1tvlijiBqGsskcH+Fvf6QYUR2xyPPwE3Fb5NRkQEKZtrf7SoqBVNDuJUiPFEDd6zy3V8Sg57wQ5ZyJzftTsb4HhZ6mzvw34seMmWID4gbt1/ELpvNCWcUkGuloc+RJD3NHjGXnuTXfBBfuYIqBkhA9VNvMeY3ZKVTrUc4cfzA== 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=QiBeiG6SYdRpL5wcPF2wUcrRJ+ICLCfA+0lnX04Nsoo=; b=EBFFd7hTQMkz6M3LdQVSogpoB3yS+LPkG47vr6zfCye0msyNSJn4WK3Tqu1MJf3MftRv/lFeHaP4vbr+Rq3KctJne90wbI2Ma2/Z52Kfa/cN3h/HI9BgAoN12jYMazew1tFFc4ajlbX+juFwAH3/TaWLLbt93inZw15pjsqAwHA= Received: from BN6PR16CA0031.namprd16.prod.outlook.com (2603:10b6:405:14::17) by MWHPR02MB2861.namprd02.prod.outlook.com (2603:10b6:300:109::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.17; Tue, 28 Jun 2022 13:18:03 +0000 Received: from BN1NAM02FT029.eop-nam02.prod.protection.outlook.com (2603:10b6:405:14:cafe::52) by BN6PR16CA0031.outlook.office365.com (2603:10b6:405:14::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.21 via Frontend Transport; Tue, 28 Jun 2022 13:18:03 +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 BN1NAM02FT029.mail.protection.outlook.com (10.13.2.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5373.15 via Frontend Transport; Tue, 28 Jun 2022 13:18:03 +0000 Received: from xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) 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; Tue, 28 Jun 2022 14:18:02 +0100 Received: from smtp.xilinx.com (172.21.105.197) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Tue, 28 Jun 2022 14:18:02 +0100 Envelope-to: lihuisong@huawei.com, aman.deep.singh@intel.com, yuying.zhang@intel.com, andrew.rybchenko@oktetlabs.ru, dev@dpdk.org, thomas@monjalon.net, huangdaode@huawei.com, liudongdong3@huawei.com, kirill.rybalchenko@intel.com Received: from [10.71.119.54] (port=15766) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1o6B6P-0000Qh-DW; Tue, 28 Jun 2022 14:18:01 +0100 Message-ID: <60fa8edc-4c83-8ef5-a1e3-049ab456b605@xilinx.com> Date: Tue, 28 Jun 2022 14:18:01 +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 V5 1/7] app/testpmd: fix supported RSS offload display Content-Language: en-US To: "lihuisong (C)" , , , CC: , , , , References: <20220429102445.23711-1-lihuisong@huawei.com> <20220624072401.21839-1-lihuisong@huawei.com> <20220624072401.21839-2-lihuisong@huawei.com> <0cd12d0a-5b59-aeef-af2e-037506408cf9@huawei.com> From: Ferruh Yigit In-Reply-To: <0cd12d0a-5b59-aeef-af2e-037506408cf9@huawei.com> 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: 47b34861-221e-43e6-b44d-08da5908a1d4 X-MS-TrafficTypeDiagnostic: MWHPR02MB2861:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JhqZFJzOXRbs4iUSkXlQ7lDZU8tsyLctBzCx6pCy99OtA/m764Tt95FIhgnXwlJgW3tnSifs+b+dTKAHTKvWi5K+O1am4f/GCittVk8UyouhOqlc2oMY7SK7A+cb8fAIYXbmNOG2b1FmOpDoMvGGkctsH8YoorQYDnrTYAqF6fCkvTGF6aXfPo5rIAJTMpci6jvp0ygwyYld4rLcWxjsqYPDpxiv/+DHF2CpEw/vZmpESPeHoXQVRAF+POu98oj2gPe0odFZ5eFVs4GilDsX+402wOTNLH3KUWxVSrJhRAXNhPgw4BO1pBfSoLmqwI8C8qbfMFP/g+hhnjN9IQ/pICyjbjq5LWhGGN2ictZtYDfL7MMKkbV6TiaXNAqZ3GfmCGSoxSJEA/xh1W1c6jIa64Glikzn6vE92QKUQ7e4LkRAzg7c3AmnIEL3bVdmZGMZmqiFm75XfZJBeMpDWsjNjr8OmzGgaiqhQKEYnZtgceeqHU91VfyFYfF0HNs3PKQkiJ5IbcQ1Pdt/7qwY5IiVTE4RKBPB5lfwy6390DZ7lOSrZFk7ohEFx6moNqNS++Fbr7KpLmY7eV+w4JniBu+ZdeH5r76LyIuQ3tDBXp6VJhebA2QuAH4BxjfQsJJRIuwHYdiERg7FAQrTlg9PnPiFPyWYjJGo9hYhZRHYBWl/TXUssdns6W6xObYU9Btmk6QLf+4y4po7RZQRVCwActVG10XRJZQfii/zvC/2bnFu8BP+5dfRb5K2uaxrbEuAKwPYLMWIc06ZL7bOpAyipQdfltKK7RXdN1pMSE34IiWSE2eazW5Z9ybwaTKpuyMludefEKjzjkLLqQ9aJOCElss2IwUKp1ISoj6x6PmybZUmQStfbp8ZFUIFdKeKTYxoIf1hf2MJQ+5DBQHrGj/+EeF74/JIv/KsnmCBZqVL4I7kEac= 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)(396003)(39860400002)(136003)(376002)(346002)(46966006)(40470700004)(36840700001)(70206006)(4326008)(110136005)(36860700001)(53546011)(70586007)(8936002)(36756003)(478600001)(44832011)(316002)(47076005)(356005)(7636003)(426003)(2906002)(54906003)(82740400003)(186003)(82310400005)(336012)(5660300002)(26005)(83380400001)(31696002)(2616005)(31686004)(41300700001)(9786002)(40460700003)(40480700001)(8676002)(966005)(50156003)(21314003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2022 13:18:03.4309 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 47b34861-221e-43e6-b44d-08da5908a1d4 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: BN1NAM02FT029.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2861 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/25/2022 3:12 AM, lihuisong (C) wrote: > > 在 2022/6/24 21:01, Ferruh Yigit 写道: >> On 6/24/2022 8:23 AM, Huisong Li wrote: >>> >>> The 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 for i40e or ixgbe. This patch >>> uses the RTE_ETH_RSS_* bits to display supported RSS offload of PMD. >>> >>> In addition, offloads that are not in rss_type_table[] should be >>> displayed >>> as "unknown offload xxx", instead of "user defined 63". So this patch >>> fixes >>> it. >>> >> >> There is something as "user defined" RSS type, so please keep it as it >> is. >> For more details please check: >> Commit 8b94c81e3341 ("app/testpmd: port info prints dynamically mapped >> flow types") >> Commit 5a4806d304e0 ("app/testpmd: support updating pctype mapping") >> >> Simply this is to allow doing RSS on user defined protocols, supported >> by plugging like Intel DDP. > All right. >> >>> 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  | 40 ++++++++++++++++++++++++++-------------- >>>   app/test-pmd/testpmd.h |  2 ++ >>>   2 files changed, 28 insertions(+), 14 deletions(-) >>> >>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c >>> index 62833fe97c..36a828307c 100644 >>> --- a/app/test-pmd/config.c >>> +++ b/app/test-pmd/config.c >>> @@ -66,8 +66,6 @@ >>> >>>   #define NS_PER_SEC 1E9 >>> >>> -static char *flowtype_to_str(uint16_t flow_type); >>> - >>>   static const struct { >>>          enum tx_pkt_split split; >>>          const char *name; >>> @@ -675,6 +673,19 @@ print_dev_capabilities(uint64_t capabilities) >>>          } >>>   } >>> >>> +const char * >>> +rsstypes_to_str(uint64_t rss_type) >>> +{ >>> +       uint16_t i; >>> + >>> +       for (i = 0; rss_type_table[i].str != NULL; i++) { >>> +               if (rss_type_table[i].rss_type == rss_type) >>> +                       return rss_type_table[i].str; >>> +       } >>> + >>> +       return NULL; >>> +} >>> + >>>   void >>>   port_infos_display(portid_t port_id) >>>   { >>> @@ -779,19 +790,20 @@ 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); >> >> This logic is wrong, as we talked before some RSS types can be >> multiple bit, with about logic you can't catch them. >> >> The logic in the V2 of this set [1] is correct, which walks through >> 'rss_type_table[]' array and check if any value in that array exists >> in 'flow_type_rss_offloads'. >> >> [1] >> https://patchwork.dpdk.org/project/dpdk/patch/20220425092523.52338-2-lihuisong@huawei.com/ >> > Here is what I think. They have different purposes. The logic of current > patch > is to retain the original display behavior that is single bit offload and > "user defined xx". However, the logic in the V2 has changed the behavior. > I don't think this patch should change its original behavior. And it is > better > to print offload by single bit. In this way, the parsed offload > capability is > more accurate and convenient to use. OK, lets keep original behavior. Since 'rss_type_table[]' array has both single bit and combined bit entries, same array can work for both purposes. >> >>> +                       if ((rss_offload_types & rss_offload) != 0) { >>> +                               const char *p = >>> rsstypes_to_str(rss_offload); >>> +                               if (p) >>> +                                       printf("  %s\n", p); >>> +                               else >>> +                                       printf(" >>> unknown_offload(BIT(%u))\n", >>> +                                              i); >>> +                       } >>>                  } >>>          } >>> >>> @@ -5604,6 +5616,8 @@ set_record_burst_stats(uint8_t on_off) >>>          record_burst_stats = on_off; >>>   } >>> >>> +#if defined(RTE_NET_I40E) || defined(RTE_NET_IXGBE) >>> + >>>   static char* >>>   flowtype_to_str(uint16_t flow_type) >>>   { >>> @@ -5647,8 +5661,6 @@ flowtype_to_str(uint16_t flow_type) >>>          return NULL; >>>   } >>> >>> -#if defined(RTE_NET_I40E) || defined(RTE_NET_IXGBE) >>> - >>>   static inline void >>>   print_fdir_mask(struct rte_eth_fdir_masks *mask) >>>   { >>> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h >>> index eeefb5e70f..195488b602 100644 >>> --- a/app/test-pmd/testpmd.h >>> +++ b/app/test-pmd/testpmd.h >>> @@ -1199,6 +1199,8 @@ extern int flow_parse(const char *src, void >>> *result, unsigned int size, >>>                        struct rte_flow_item **pattern, >>>                        struct rte_flow_action **actions); >>> >>> +const char *rsstypes_to_str(uint64_t rss_type); >>> + >>>   /* For registering driver specific testpmd commands. */ >>>   struct testpmd_driver_commands { >>>          TAILQ_ENTRY(testpmd_driver_commands) next; >>> -- >>> 2.33.0 >>> >> >> .