From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <ferruh.yigit@xilinx.com>)
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)" <lihuisong@huawei.com>, <aman.deep.singh@intel.com>,
<yuying.zhang@intel.com>, <andrew.rybchenko@oktetlabs.ru>
CC: <dev@dpdk.org>, <thomas@monjalon.net>, <huangdaode@huawei.com>,
<liudongdong3@huawei.com>, <kirill.rybalchenko@intel.com>
References: <20220429102445.23711-1-lihuisong@huawei.com>
<20220624072401.21839-1-lihuisong@huawei.com>
<20220624072401.21839-2-lihuisong@huawei.com>
<a43047e9-79da-cbc4-a85c-2843f0b42fff@xilinx.com>
<0cd12d0a-5b59-aeef-af2e-037506408cf9@huawei.com>
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <lihuisong@huawei.com>
>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@xilinx.com>
>>> ---
>>> 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
>>>
>>
>> .