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 11FAAA0C46; Fri, 17 Sep 2021 12:20:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8E473406B4; Fri, 17 Sep 2021 12:20:13 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 3F3E440689 for ; Fri, 17 Sep 2021 12:20:10 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10109"; a="222806338" X-IronPort-AV: E=Sophos;i="5.85,301,1624345200"; d="scan'208";a="222806338" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2021 03:20:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,301,1624345200"; d="scan'208";a="473081936" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga007.jf.intel.com with ESMTP; 17 Sep 2021 03:20:10 -0700 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Fri, 17 Sep 2021 03:20:09 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx609.amr.corp.intel.com (10.22.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Fri, 17 Sep 2021 03:20:09 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.105) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Fri, 17 Sep 2021 03:20:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M4THzFgc9mBKWByh9YrDjYv5giIAky15gKvwC7RppiH1NuLvnxqa93pa8FuEXTKPyvQqbQ+DEynho5VtQ67rZuDnXBoHvIgWMn1j03EtkVuGBhRfjVOjZ2QnHsEeYcnjqFgSacHV67emC0p0Hjf7i/DLZQP94XK6aDGp9yghEAoEjulph5fpRFu4zhpyExCv1fKHf5Xbwrct7TgB1ogm+S2+XiW6MPXrubMVQpKDVzbRG89K8IGlA+MN3TLmrDlT11CUuJ5OxP5iKtH51SuXcryNI4lKmj9Nqc/2k4ztvipIQzcpM2A8HyvJjvz4a2UPwm1jGjvlDj0fT1jvC6/csA== 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; bh=PXt4/STQjq/XjM8G92NRd/0PN6YVh8kKqCpJNpOOss4=; b=jiicAiGyH60APBUnCl/+BcMrDm/AEIibbfZvv3p2KNl1bAesk9o9o6Sj5K8PjlS2XRZYph+AWiB9tPjTBNnp5K4Otv6XF5rDlk12CPdEbMOFld45EoW34hKnfYFPgKsNjymWYqT4vCRqKM8hrEhHpyY8a+755vnIdAmHIYy+BqRAY00GK1f7LURu7Gkwg966zCjlvnXHvAWS+yGuM/00nrhvAlmsy7Fn03z87faZEeP0GTfqMToiYQ0v3KDRUbC1hKFuErfwZWo3vQrL0glaagsxknHesFVl9qGTggTeofQbNbs+Lf9waCds2gbptRJnIZlkY4lHJdOCOTzMV+XxGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PXt4/STQjq/XjM8G92NRd/0PN6YVh8kKqCpJNpOOss4=; b=imEWrxurUxUm2xIcxE1K+p8f+Q48c1/hkRjVPNpu3YYv6DqlxSP5T11AQ43/kc9RpMvBb2u7fcon1g0HNc+Gy+ELgOXeRoFMhwADFWQNq9YGzztqmsRp/6ogz9w9G+J9hdZmepl8mbpGAWEfXYF7exuvN/6ba8kGZjkdFIn2XSI= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB4902.namprd11.prod.outlook.com (2603:10b6:510:37::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Fri, 17 Sep 2021 10:20:08 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc%5]) with mapi id 15.20.4523.017; Fri, 17 Sep 2021 10:20:08 +0000 To: "Li, Xiaoyun" , "Wang, Jie1X" , "dev@dpdk.org" CC: "andrew.rybchenko@oktetlabs.ru" , "thomas@monjalon.net" , "jerinj@marvell.com" , Konstantin Ananyev References: <20210826070924.308368-1-jie1x.wang@intel.com> <20210827081740.365037-1-jie1x.wang@intel.com> <20210827081740.365037-3-jie1x.wang@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <9d302c27-572b-2d03-4286-a19bc0b77779@intel.com> Date: Fri, 17 Sep 2021 11:20:03 +0100 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB9PR02CA0011.eurprd02.prod.outlook.com (2603:10a6:10:1d9::16) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB9PR02CA0011.eurprd02.prod.outlook.com (2603:10a6:10:1d9::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16 via Frontend Transport; Fri, 17 Sep 2021 10:20:06 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1b7c1319-84b8-48d0-b772-08d979c4b950 X-MS-TrafficTypeDiagnostic: PH0PR11MB4902: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QN8TlaMHWJDzVbdOQICAJQmx7IFpSAToatxb585pUJHyDH19oJvY2I6F0D6crUtb1ci1YxniSWcwF9v36ymrZHmTgKmf1RBPrpNOmF9XSCkws1c7dYzCIUT8TJc+yO/9Qu2xEMiP3cxsN5lpiEdCEqMoTqNxfd4aZIQa3GyillD3s+u2zh4uv9i4KMy4T6a8A4KZ/ucIdt+Ix9By1d1tsNHjJ3A+fklc5L/rQlC3tP4PDrGjSD096iMJbIpM4BW/RDpxDR0QMSsFkjwuuclFE4trxB9oz2tnAN3c8ZQiCrM4XxSqXbv09HYRidPjXfmMkMrgGAdnmULnOi9L/TYIMLBap65zsIb/Pkown7SEVFiNWyWpVMNH+ExFnovEqKoUkGJxSinTVgZftRQWWd4SRcIWj8dm6FM3M+8hi10vZEzeaxSAy+D9/QVR5+1FweMyUuAnAs0G5JBOuEhhV2rUIWPS5k74odY1HTo1Y31zht45BcUqI5wjxWjWHeTKhlzFUqgpqCm4TsyWjzyl0Y8nRnnwxrSHV0Ei+XJ0tmbse2TMn0EGpm0kZ2goZxCjzumFqmeF44h00Mhs73hySeAMlvdus3/vA+Nd5RG0vBjSIZK8dRK4zzpw+kKLYGWfH8r9cbFN6p7AVV0U/252r1loLoc+FxGqInxtZ+KQK7pndqYF3Hv3dFSqFGVwqqMsmvy1qfWgnT5d4psnANV3onPTyA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(316002)(31686004)(5660300002)(83380400001)(38100700002)(16576012)(54906003)(110136005)(2906002)(478600001)(31696002)(86362001)(107886003)(6486002)(6666004)(36756003)(44832011)(956004)(66556008)(4326008)(66476007)(8936002)(8676002)(26005)(53546011)(66946007)(186003)(2616005)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YmRCMi9JYnFLZkxzaWNibHlFWnIxZnZBc0pWY2t4QUMxTHg2STZ5Ykc0SHBX?= =?utf-8?B?T0lPQXRWdGRBSGZwS0NuQXlwbHBDNW05R0pseTZiOG1rQUFackdJTmlsdU90?= =?utf-8?B?L0dSWng0WGlzZlJ5VjE5YlhNVi9USVA5YlFuMlByck1sQ1JLOTFqcVRkeU40?= =?utf-8?B?cERxWkFLZ2dVYjl6aFMyaUt3SEdLbFUyTC9QdUxRUHU3WURTZWR5VjVNU3hv?= =?utf-8?B?S3lkdnM2Z2x3YmNBRnpJOE1NOEdTS1BJdU9UaUlPOXIwTkpZL2xjdDJuWndn?= =?utf-8?B?RlhOMnJhb3NQN2c4K1lXaVE4b0Q2RS9yUDJzMUw4ZzJJOEhtalEvZGpibTE5?= =?utf-8?B?b0NGZk8yZXJ1Zm5idExwdi96ZzQrUHJxTWpscGNzMjZkdkNUOGd5TGlnOVpW?= =?utf-8?B?WlVrdFJaZ3RoSW5ucnpkZlhQM0dubkxVc29hUnpPaGlxS1UvUGtzY3U0NjY4?= =?utf-8?B?ckVxVmJiRVFFZVQ5YjQ4YXo4cmdncWM2blBWRTJkWXV4bVh4cU9Bbk1qNmJm?= =?utf-8?B?bVJZbG5hbTdxYnJCNnRlOG9IdmRIYWgva0k2SDlTTkJ4aWN5b0tWUmlTa29j?= =?utf-8?B?WGxKZzF0U2RGVmU4ZlQ4bmRBNmgvVHN1QnNRczVUR1AxZ0hxMnREcUdvZ2Nh?= =?utf-8?B?cCtKUHcxcWM2cUFrQSsvUCtPcDlQQUJPK2ZGMXVMZmNReWw1MlhxdXNmVStq?= =?utf-8?B?Sk94SitxNFJZOHY3RDE3UWFiaHdoNkVKQ2FuUWdCMGdDWU5raXFnV2FRbVUr?= =?utf-8?B?ai91eXJXRmtvazRsTjlRZ1cvSUwrYVMwelNYZm9oa1NPYWYxcFNPRXRYY293?= =?utf-8?B?SEVaTlhQNko4TTc5c1hoOHVJL1JSemhnMnVuUVpJV1Z3aVFTNStTZnZFUkl6?= =?utf-8?B?WkNMYitOKzJRcEhvMFkrU1lVeG5MQnNtanoyamZzNEI1dGFGRktlRFo1bFVP?= =?utf-8?B?cnFBZHB2RHZEVWxuMjhSeHRlUUU5cTZSMmh0aTI2VGkyeUFlN0kxN05nUzZE?= =?utf-8?B?SFd6Z3ZlRUM2Nm9XNzhQS2RUeUF6NytTNW5STTFHRmYwSnpSeVR6NVducWwz?= =?utf-8?B?MHdYZ21yN2VwSHp5dy9xMjNNT0MwTjdTYlVSbXJ1WjFwbEdzVnNzME52OHZN?= =?utf-8?B?YWc4RUlEOUh6a0JnbDA1c3E4ZU1GbzZCOW9pUUxTOVBnRHRLZ2h3bHAvRTJz?= =?utf-8?B?MkZTbVJyWGQ4OGt0V2dya1B0SFJJRnRZRFF5by9raUprNVY2ZmRrS1VqUnFY?= =?utf-8?B?eE1GYm1mTll2NU1IcTgzNmlLdDYzblNOdlBNMGhQczhENnlZSytvVFBKY1lJ?= =?utf-8?B?Q1N6S29FSnY2NkNIemxZZ0pJN3JKNTJNTmJSUk1KalBUcXpMZ1RacDg1UkI3?= =?utf-8?B?NzNjSkVrMUZ0UC9MQkhLajkvekZIZnRWa0FkZFJ0Y21lVUJJbGpWWlNFY1Vq?= =?utf-8?B?RlFYUkxhM1RRQWJFRVlqVUd1TFVVSFUzRjZLN2NTd204VFpMUldSb0dsVTZB?= =?utf-8?B?Q3p5WEV4MmV2R3ZmWGN6TTBoZ3BGRnlBRFFCVGt6STVmTnlkK1BENVBUSnRM?= =?utf-8?B?V2xCOVNyanVsQUxjWkRqUUlRYU9iWTZLa0ZmMGFXajZ6U2VzeVF1MFpxWjFr?= =?utf-8?B?NHJIYmY5VVgwNlpraVRKZitXRzI2dnpjL0FtdXMxMzgyRGdraFcyM3hiVldW?= =?utf-8?B?TFBSdSsyTG5aYlNMc3RwRnFqWERKL0V2c281c3NjZWxHQ3haN1pvUEJHYlg4?= =?utf-8?Q?hTCiZBHcolxB5ozSxI9rKslFwVi+aNfLmbaiha6?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1b7c1319-84b8-48d0-b772-08d979c4b950 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2021 10:20:08.2039 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: xfKh9i1DFEiCYRarPOzMHS3G33z47QGUqT7VzNnHx0PdcPYwOYegWHH+FzggG9x05wgVX1bQICTFr6MPyiqygQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4902 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/testpmd: fix testpmd doesn't show RSS hash offload 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 Sender: "dev" On 9/9/2021 4:31 AM, Li, Xiaoyun wrote: > Hi > >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Thursday, September 9, 2021 00:51 >> To: Wang, Jie1X ; dev@dpdk.org; Li, Xiaoyun >> >> Cc: andrew.rybchenko@oktetlabs.ru; thomas@monjalon.net >> Subject: Re: [PATCH v8 2/2] app/testpmd: fix testpmd doesn't show RSS hash >> offload >> >> On 8/27/2021 9:17 AM, Jie Wang wrote: >>> The driver may change offloads info into dev->data->dev_conf in >>> dev_configure which may cause port->dev_conf and port->rx_conf contain >>> outdated values. >>> >>> This patch updates the offloads info if it changes to fix this issue. >>> >>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings") >>> >>> Signed-off-by: Jie Wang >>> --- >>> app/test-pmd/testpmd.c | 34 ++++++++++++++++++++++++++++++++++ >>> app/test-pmd/testpmd.h | 2 ++ >>> app/test-pmd/util.c | 15 +++++++++++++++ >>> 3 files changed, 51 insertions(+) >>> >>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index >>> 6cbe9ba3c8..bd67291160 100644 >>> --- a/app/test-pmd/testpmd.c >>> +++ b/app/test-pmd/testpmd.c >>> @@ -2461,6 +2461,9 @@ start_port(portid_t pid) >>> } >>> >>> if (port->need_reconfig > 0) { >>> + struct rte_eth_conf dev_conf_info; >>> + int k; >>> + >>> port->need_reconfig = 0; >>> >>> if (flow_isolate_all) { >>> @@ -2498,6 +2501,37 @@ start_port(portid_t pid) >>> port->need_reconfig = 1; >>> return -1; >>> } >>> + /* get rte_eth_conf info */ >>> + if (0 != >>> + eth_dev_conf_info_get_print_err(pi, >>> + &dev_conf_info)) { >>> + fprintf(stderr, >>> + "port %d can not get device >> configuration info\n", >>> + pi); >>> + return -1; >>> + } >>> + /* Apply Rx offloads configuration */ >>> + if (dev_conf_info.rxmode.offloads != >>> + port->dev_conf.rxmode.offloads) { >>> + port->dev_conf.rxmode.offloads = >>> + dev_conf_info.rxmode.offloads; >>> + for (k = 0; >>> + k < port->dev_info.max_rx_queues; >>> + k++) >>> + port->rx_conf[k].offloads = >>> + >> dev_conf_info.rxmode.offloads; >>> + } >>> + /* Apply Tx offloads configuration */ >>> + if (dev_conf_info.txmode.offloads != >>> + port->dev_conf.txmode.offloads) { >>> + port->dev_conf.txmode.offloads = >>> + dev_conf_info.txmode.offloads; >>> + for (k = 0; >>> + k < port->dev_info.max_tx_queues; >>> + k++) >>> + port->tx_conf[k].offloads = >>> + >> dev_conf_info.txmode.offloads; >>> + } >>> } >> >> Above implementation gets the configuration from device and applies it to the >> testpmd configuration. >> >> Instead, what about a long level target to get rid of testpmd specific copy of the >> configuration and rely and the config provided by devices. @Xiaoyun, what do >> you think, does this make sense? > > You mean remove port->dev_conf and rx/tx_conf completely in the future? Or keep it in initial stage? > > Now, port->dev_conf will take global tx/rx_mode, fdir_conf and change some based on dev_info capabilities. And then use dev_configure to apply them for device. > After this, actually, dev->data->dev_conf contains all device configuration. > > So It seems it's OK to remove port->dev_conf completely. Just testpmd needs to be refactored a lot and regression test in case of issues. > But from long term view, it's good to keep one source and avoid copy. > Yes, this is the intention I have for long term. I expect that testpmd still will keep some configuration in application level but we can prevent some duplication. And the main point is, by cleaning up testpmd we can recognize blockers and fix them in libraries to help user applications. > As for rx/tx_conf, it takes device default tx/rx_conf in dev_info and some settings in testpmd parameters also offloads from dev_conf. > So keep port->rx/tx_conf? But then it still needs copy from dev_conf since this may change. > I am not very clear what is suggested above, can you please elaborate? And 'struct rte_port' seems has following structs that can be get from library: struct rte_eth_dev_info dev_info; struct rte_eth_conf dev_conf; struct rte_eth_rxconf rx_conf[] struct rte_eth_txconf tx_conf[] I don't think we can remove them, but perhaps reduce the usage of them, please see below. >> >> So instead of above code, update where RSS hash offload information printed to >> use device retrieved config instead of testpmd config, will it work? > > It's OK for device offload configurations. > But queue offloads are a bit tricky since dev->data->dev_conf doesn't include queue conf. > And it's not fair to use device offload configurations for queue offloads since user can use cmdline to config queue offload and that info can only be saved in port->rx/tx_conf and configure the device in setup_queue. > It is common in testpmd that, a command changes the application copy of the configs, and mark as device configuration is required (for port or for queue). So in later stage this changed configuration is applied to device. This async approach has its benefits and I don't think we should change it. (Also has some disadvantages that we hit in the past, like detecting some configuration can't be applied in later stage when we try to apply the config, not when command is issued at first place.). What we can do it, reduce the testpmd config usage for the case to gather user requests and apply them to device. But to display device configuration, or to decide based on device configuration we can user config values get by device by APIs. What do you think, can above distinction makes sense, or does it work? And there is still a chance that application copy of config diverge from device config, and since we provide full config in our APIs (not changes), there is a chance to overwrite a device configuration. To prevent this it is possible to read device config and overwrite testpmd config with that, similar to what this patch does, but I am not sure where this sync can be done. What do you think about doing this just after device configured? Thanks, ferruh