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 5436241BAA; Thu, 2 Feb 2023 09:43:24 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D823B42B7E; Thu, 2 Feb 2023 09:43:23 +0100 (CET) Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02on2044.outbound.protection.outlook.com [40.107.95.44]) by mails.dpdk.org (Postfix) with ESMTP id B215F406A2 for ; Thu, 2 Feb 2023 09:43:22 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SJN1YsgV8yQd52k+S+KZzaUXbo7yjeB+9KHCt3LyK9UDfDNjec2mBc1EWsVdIdQOqk2iCpAQMEI3A/ctaumzSN+6eBEs/+zCRlkNHNbTIa7KZh0ebzMrPyDAEhXd5v9peb3KNsUjc06mXy/NORrFL2OlrCNwR+bE60sgiaRvlws945QnnvC9uHrl7pje18RayrvtdPCPYx304BiJLWmPT/H20IEsyKmx4QWhCYoRX/7ZFxfs6AYXfklW6okUJCsyABGlT9VERMCIhx9Iy2DBjAlPK3nxC5xH9J2qKmBw/9+xNtgPC2Ri3YtBZfdBtfkpHRNAL2yH9rwaRIDYQ2/eHg== 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=CTpZSXMhy6/PkeyZR7I/Pk6FW3aa5BtHIyGnAQNJB/g=; b=F4mCpn738Af6Zs+UUyuqaXqnm/XqEPr0ze+BvUFuGy//UsIHKGGNKIJTTpwv9DX8jP/XVrlB181XDRNWgip8K1yXUc6p37AnUpQ9NFmyXMSWABSlTQdQg/V2iIrVjivYGW8VmPfE1NrAiSqmASKecWQh+fF9aXHS6UNRE73thnsoOeGey0iye3nrCn/o0z5oZHYuHFdwbeMus7Lh5VnNqimiM6m69xpAh9g8/K03DXIO9kNQ1GohZlibb5elFyp6m89o4rkkq0ZQ2AxwpNxa0PBSMy/69zlwOXI600fA9lIYrQib8SgOxZE/5zAkkkMurJeNmWM34nM/nk0TqfGRAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CTpZSXMhy6/PkeyZR7I/Pk6FW3aa5BtHIyGnAQNJB/g=; b=ZQizCT2YwamUQTrZeFAesxJJKF8W3+DUifDcMC4eIMisoBruHYrkhZhLXGPS7z1qOPaLlqMoh0Y8TXmvJ5oFs7xft2SMMnAaxks3g994qWYSYxACr15YmWT+h4fvHcxVzeiz21bS3TLKqfaksWmgryvsq6GH+wlXIkKiHSPacz0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by LV2PR12MB5845.namprd12.prod.outlook.com (2603:10b6:408:176::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.24; Thu, 2 Feb 2023 08:43:20 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::4807:1f44:5e04:e05a]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::4807:1f44:5e04:e05a%8]) with mapi id 15.20.6064.024; Thu, 2 Feb 2023 08:43:20 +0000 Message-ID: Date: Thu, 2 Feb 2023 08:43:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: Jerin Jacob Cc: Thomas Monjalon , Andrew Rybchenko , Ori Kam , Ivan Malov , Nithin Kumar Dabilpuram , Aman Singh , Yuying Zhang , "dev@dpdk.org" , Hanumanth Reddy Pothula , Slava Ovsiienko , Jerin Jacob Kollanukkaran , "david.marchand@redhat.com" References: <20221220200250.2413443-1-hpothula@marvell.com> <98a80c20-a5e4-deea-f7dc-c6aa5d52800b@oktetlabs.ru> <2490780.4XsnlVU6TS@thomas> <22a65100-bee8-1726-6e27-14b9028a29d4@amd.com> <01d3b455-3f3e-2658-db51-4da7cfc3cdeb@amd.com> From: Ferruh Yigit Subject: Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PA7P264CA0040.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:34b::10) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|LV2PR12MB5845:EE_ X-MS-Office365-Filtering-Correlation-Id: 2e43e766-e48c-4bd2-4d90-08db04f98949 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bcMGgZN7hBywcc11cMWckDiJgnXR2aTTxQQHpRI9x9uHn2cybo0OhVsx8FbdrN8A8MMk0vRCBDZ32XaUvACAIdB6MIOmjQlA7SFU7+CFk8P9q2Ax46QKo2CFLkvrA1Kd1Rkf1eY3t+7QdK5JyrScUK5JfQa1v07EDwyMYOWlCEyNCIl9VP/RKNdLqA3dsz7AXI1c5g3GF175d3fBvbNzc5RjxOWh0wVo9uEXp96vsGzgSkimElors5c3eACW9N3xpCZWUMD5rlFec7VFjHJbx7rxHCqanrNyz9+rV98J8WEXuIGQ0voa4dXs1LkEp97t08xD8Fkh2knAUy4bw74kE4BnNII7wiuhBj0hh6x6ta78qzGsCpl5Xf2oU0V3Sjt+Q27Y/Cb1K0QeXv9X1q31kVm+wztq2LrNFRTel/+wNw+Sbj/uXZ2z3vTYwZjNlds55CMHs3HHdbSRDqa0uiGvcj+S5KoCXGYUbzBZwQQ9rKZO5SwFHu0fUh1Uf+JnDD6GKduAAVhZWRwif0A0v5Ku1swgOCJVI+JYT7A6oUKY7cfyeFWF9w7X7BzKQbDjOyZ5khEeEubF8MKhQTMIIGICmLKVUbEbobCIQeqUVQPHkK8XF7hOHdxkgdCh+w5vmOqNt+WdTDJgu1FLKnq9MsDDI/DIAI3feSqJyr/EfHUCCcbjzV0pYOc0YOP29VptkbtdOxUEYb06IUJoYFtKVvoYHjc8zoBAbKZ+RAYFQc3KbEI= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(376002)(39860400002)(346002)(366004)(396003)(136003)(451199018)(5660300002)(44832011)(38100700002)(2906002)(7416002)(31686004)(31696002)(6486002)(53546011)(478600001)(2616005)(6512007)(186003)(26005)(36756003)(86362001)(54906003)(83380400001)(6666004)(66556008)(66946007)(8676002)(66476007)(6506007)(6916009)(41300700001)(316002)(8936002)(4326008)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZUs1NWVGYjMySHN5TkNXeWt4elB5ZFdhOU03V2NYeCttRm8ycktTL25ydGd2?= =?utf-8?B?QWlvVGltTWdPL2dsUkZnMkFNcGMwWVV6R1RNSk1vUExQM29QNDUyRDBraGFh?= =?utf-8?B?L2NSNG9IUnBGUnJNbDlhTWNtWW1HQUlQV3hHNHpMT042MkVsQWQ1THV6czlX?= =?utf-8?B?ZkJpUnhhQ0pFZitlOVhsazJicUVLUzVlNDJJMVB2cG54dmloL2VZRjZTOENp?= =?utf-8?B?NEMrZUtLN3pHWUxSUVovQ001TWozYWVydU1xekpMR2llUHFrZEMvcjJna1FG?= =?utf-8?B?ZzJCNllmaTgvcW1IUkducHFEVFVzY21ieUlSS1Y5alJMQlBoMG44SVdrdjR6?= =?utf-8?B?K3hESnZ6NlBHM0dKMmlrNkRzS2FPNGJETE1iQk0xc2NlT214SlJjV0U4azJ6?= =?utf-8?B?MVhVNXFIczQwR013citZM2FZRVl6VllJaWVPT2hua0haMlY4Y3pMK2dnczFO?= =?utf-8?B?NjBJK3c5QVkyRHloVWxNbU1RMVFuZDhpYytHWXR2bEZ5UXl4ZTdRczBrUU0r?= =?utf-8?B?UDVqOGJuWlRacklMamlhNURyamdsQjE4Q1VTM3Z5dHk2NFNlWW45Z1Fjay9H?= =?utf-8?B?OGc2K29yNWNoWkcrVm1lM3Z3YnorZlg3elBHRndROE80NjkzQ1lXYnVxYUJH?= =?utf-8?B?MC9URGJLUnMxWmFVSTNMODIvVVQwU2VaZ2NGOG1lZHBBK0JwNS9zTTlUWVhP?= =?utf-8?B?OUowTnhva3NLTE0wWHJBQ1hqZHVVMDg5aDFlR3lHbE54ZlIvVjBCRXdYbS9V?= =?utf-8?B?VE1wSkNOVzQ4c0ZsNmFYVXVNaVZyV0hPb0ViYWZHSlcrcXUwNGp4bzFycUhU?= =?utf-8?B?VVlxSkMwdWVTRjZuQVZYTWlZNFIzT2V4dzVLUjZZNjJ0Y1lLVXBKYWxYZWYw?= =?utf-8?B?eFltdWQzdVNjb3hES2FLR3M5YVNpYzg4QjV4UzlVR1lrd1BMc3N4S1ljbVNl?= =?utf-8?B?REROL252QmMwNXdnbDVxSkpXN1M0SkZ5TlFpY3hRZWZnWmpxc1BlRWlaMTE2?= =?utf-8?B?ckMzb0IxeDZ1ZHlnQU85RjVPTGFFdG9rbi9sWXZzRWdpKzYwSWN5TVg1YnFp?= =?utf-8?B?SEV0em14NHFjdDZiNTV3MS9ncDVibjl5K1ZsbVNXRGJNRmdpMkRTWElKcHlG?= =?utf-8?B?UDBPbEtqRE0zUUdoYVArMG9zK20vSTAwL1d1azBZbXplSHpmZCtyYUc3OGNv?= =?utf-8?B?YllVelQrSmxxTjMrNUF5K0hoMnU2VEtrWWVKNTM0RVFIL1lWUUptSjBUL0Zs?= =?utf-8?B?MzFhbFNFTWpJeTZWTDBUR1ljVDQ4SzRRSWhUTTBIMVVSdnI0VlY2S2phOUd1?= =?utf-8?B?U3h1MGt1d2g2MFd1V3JCaUJBYXcwRWZ4RHRMemRIdXl1MDFkb05lSzJZVWM3?= =?utf-8?B?Z3JQYVlqL3ZjYzB0WUdqaXN0ZFVrcVRScUFERi92K0h6TmxmV2ttYjArMUt2?= =?utf-8?B?aDRicW95TWlGdmtrT3RrdXEvdGhSdkZPcFZya2pQR3o3QlVoWkQ4eUhYMGVZ?= =?utf-8?B?ZjVvbUlaUnZaSG0rSUNyNFBFY3M1YW9HSUg0YUlBZnlLR0pZbU9Mc3BjcVlW?= =?utf-8?B?UTJJa01QdUs4eEZtZ1RCckdkQjZOa2UxL21McGp4Q3ZIS3I2aGVzUytCWWQ4?= =?utf-8?B?bnVMQytzYnNkQ0ZRUm5pVzRWLy9Gc3JIdW9LSEtkK29tRWlNLzhNWUtmSnh5?= =?utf-8?B?YnZVT2lodEdSTkhGcE9XM01od1RJeTREZk9XUm9JOE1kTUNIT1NPdTZqNlFv?= =?utf-8?B?OTBHazFGK3RpZmpVSlVJMFRBcGpDZ2VyOFVpSEttZHVoS2Roc2RlS1o3TmJG?= =?utf-8?B?Vnk2c0NTSkdtNThpa2w0WUk3RThOUUdLWEpZMFp1ajJyRTRKZlVKK0kxV1F5?= =?utf-8?B?ZjE5eWdkUWpEbDNsRDJiQU4rNG9Ea1RkMDZjYStuTG5XcnhKOEVFd2FvVlhk?= =?utf-8?B?ZE1oZm13SmtEMkNiR0hHR2JKVndJUjRkTVlzbWdid05sWGlqWUptT0wzZzdQ?= =?utf-8?B?czlHczEwQVNsTWk3ZXBXSkk0WmFsb2dDdTVsN1hsZE9OY2xXcFNCbzlTakdQ?= =?utf-8?B?eFNQMkpDcjljaWxwRzdQbWVZa2NjcHBQWW5UY3M2SmNDcE1UZ3E2MllybHZR?= =?utf-8?Q?idG89wcR8d0FFAEtwkLSReqlb?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e43e766-e48c-4bd2-4d90-08db04f98949 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2023 08:43:20.2206 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: p5oMeGH1fS5JiPaRlQLb2OWH++T8URKHaF4sY/kWUXbnVt/IjS7NjodZGbmkODPa X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5845 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 2/1/2023 3:22 PM, Jerin Jacob wrote: > On Wed, Feb 1, 2023 at 8:20 PM Ferruh Yigit wrote: >> >> On 2/1/2023 1:48 PM, Jerin Jacob wrote: >>> On Wed, Feb 1, 2023 at 5:06 PM Ferruh Yigit wrote: >>>> >>>> On 2/1/2023 11:15 AM, Jerin Jacob wrote: >>>>> On Wed, Feb 1, 2023 at 4:35 PM Thomas Monjalon wrote: >>>>>> >>>>>> 01/02/2023 11:58, Andrew Rybchenko: >>>>>>> On 2/1/23 13:48, Jerin Jacob wrote: >>>>>>>> On Wed, Feb 1, 2023 at 2:59 PM Andrew Rybchenko >>>>>>>> wrote: >>>>>>>>> Frankly speaking I don't understand why default value is so >>>>>>>>> important if we have a way to change it. Reasons should be >>>>>>>>> really strong to change existing defaults. >>>>>>>> >>>>>>>> The only reason is, typically testpmd will be used performance >>>>>>>> benchmarking as an industry standard. It is difficult to tell/educate >>>>>>>> the QA or customers >>>>>>>> that, "BTW if you need to get better performance add more flag to >>>>>>>> testpmd command line". >>>>>> >>>>>> I disagree. >>>>>> When you do performance benchmark, you tune settings accordingly. >>>>> >>>>> IMO, We tune the system resources like queue depth not the disabling >>>>> features for raw performance. >>>>> queue depth etc people know to tune so it is obvious. What is not >>>>> obvious is, testpmd only >>>>> negotiated some features by default.I am not using that feature, hence >>>>> I need to explicitly >>>>> disable it. >>>>> >>>> >>>> When 'rte_eth_rx_metadata_negotiate()' API is NOT used at all, and I >>>> believe that is the case for almost all applications since API is a >>>> relatively new one, PMD default behavior should be to enable Rx metadata >>>> flow rules, in case user requests them later. >>>> >>>> So, enabling all in application is same with not calling the API at all. >>>> >>>> In this perspective, disabling Rx metadata is additional >>>> optimization/tuning that application can do if it is sure that Rx >>>> metadata flow rules won't be used at all. >>>> And API is more meaningful when it is used to disable Rx metadata. >>>> >>>> I think it is reasonable to enable all Rx metadata by default in testpmd >>>> with a capability to disable it when wanted. >>>> >>>> OR >>>> >>>> May be we don't call 'rte_eth_rx_metadata_negotiate()' API by default in >>>> testpmd, it is only called when it is requested explicitly from user, >>>> enable or disable. >>> >>> Second option looks good to me. >>> When >>> 1) user request for action which is needed negotiate(), >>> AND >>> 2) rte_eth_rx_metadata_negotiate() != ENOSUP >>> then, testpmd print a warning that need to enable >>> rte_eth_rx_metadata_negotiate(). >>> >> >> We are not suggesting same thing. >> >> What you described above assumes PMD disabled Rx metadata flow rule >> support by default, and it needs to be enabled explicitly by >> 'rte_eth_rx_metadata_negotiate()' API. This API becomes mandatory for >> functionality. >> >> As far as I understand PMD wants to disable this flow rule by default >> because of performance concerns. But this creates inconsistency between >> PMDs, because rest of them will enable this flow rule by default (if it >> is supported) and be ready to use it when proper flow rule created. >> >> With this approach some PMDs will need 'rte_eth_rx_metadata_negotiate()' >> to enable Rx metadata flow rules, some won't. This can be confusing for >> applications that *some* PMDs require double enabling with specific API >> call. >> >> >> Instead what I was trying to suggest is reverse, >> all PMDs enable the Rx metadata flow rule by default, and don't require >> double enabling. >> But if application knows that it won't use Rx metadata flow rule, it can >> disable it to optimize the performance. >> This makes 'rte_eth_rx_metadata_negotiate()' functionally optional, and >> for testpmd context it can be called via a command on demand by user for >> optimization purpose. > > This won't solve concern I have outlined earlier[1]. > Yes, it won't. > I think, The part of the problem there is no enough adaption of > rte_eth_rx_metadata_negotiate(), > > The view is total different from PMD maintainer PoV vs testpmd application PoV. > Agree, and I assume it is different for user application too, which may prioritize consistency and portability. Overall, I am not fan of the 'rte_eth_rx_metadata_negotiate()' API, I think it is confusing. > Just to avoid back and forth. We will call off this patch and remove > rte_eth_rx_metadata_negotiate() > PMD callback from cnxk driver. Keep it as old behavior, so we don't need to care > about rte_eth_rx_metadata_negotiate(). > When you remove 'rx_metadata_negotiate' callback, what will be the PMD behavior? I assume PMD will do the required preparations as if all Rx metadata is enabled. And what is the performance impact, is removing callback improve the performance? > [1] > The only reason is, typically testpmd will be used performance > benchmarking as an industry standard. It is difficult to tell/educate > the QA or customers > that, "BTW if you need to get better performance add more flag to > testpmd command line". > To make that worst, only some PMD needs to give the additional > parameter to get better number. > And also, testpmd usage will be treated as application modeling. > >> >> >> >> >>> >>>>> >>>>>> >>>>>>>> To make that worst, only some PMD needs to give the additional >>>>>>>> parameter to get better number. >>>>>>>> And also, testpmd usage will be treated as application modeling. >>>>>>>> >>>>>>>> Since this feature only used on sfc and cnxk driver, What is the >>>>>>>> situation with sfc driver? >>>>>>>> Keeping it as negotiated and not use the feature, will impact the per >>>>>>>> core performance of sfc or >>>>>>>> is it just PCI bandwidth thing which really dont show any difference in testpmd? >>>>>>> >>>>>>> Yes, sfc could run faster if no Rx metadata are negotiated. So, >>>>>>> it is better to negotiate nothing by default. But it is always >>>>>>> painful to change defaults. You need to explain that now you >>>>>>> need to negotiate Rx metadata to use mark, flag and tunnel offloads. >>>>>>> Yes, it will be required on sfc and cnxk only. >>>>>>> As an sfc maintainer I don't mind to change testpmd defaults. >>>>>> >>>>>> If we change testpmd defaults to "do nothing", >>>>>> then we should disable MBUF_FAST_FREE as well. >>>>> >>>>> if you see MBUF_FAST_FREE, it does nothing. Actually, >>>>> !MBUF_FAST_FREE is doing more work. >>>>> >>>>> >>>>>> >>>>>> >>>> >>