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 5ED85A0548; Mon, 20 Sep 2021 11:46:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CFE8E40DF7; Mon, 20 Sep 2021 11:46:15 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id EDA9540DF5 for ; Mon, 20 Sep 2021 11:46:13 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10112"; a="202596791" X-IronPort-AV: E=Sophos;i="5.85,308,1624345200"; d="scan'208";a="202596791" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2021 02:46:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,308,1624345200"; d="scan'208";a="702421922" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga005.fm.intel.com with ESMTP; 20 Sep 2021 02:46:09 -0700 Received: from orsmsx606.amr.corp.intel.com (10.22.229.19) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 20 Sep 2021 02:46:01 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Mon, 20 Sep 2021 02:46:01 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.49) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Mon, 20 Sep 2021 02:46:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hEwhyvOLr7oA0FBn6ILMaCtAapJvxJwtTbGPau2OOEGQyKan0whzTiFcv/NXgBNotskGy+INfyWB6FDfdbMKVZNRTNed2oIwS2Zzw4pBJEvG3v/kS3i3HL5OK+gicNzwXj5Q5PXZVBuVTT/1G7KiSmkUwuf0intPrmPb8nn4es7xJMyQLH8Z+ejciDufO8qOgOtax2pSzP5U8U+S8Tld01hCCwG6Tr1Z83DepN4rRadokasuEx2luqJOjYjZaDgZWHuKPNGNa2dLTcwQBnvLfSu1TQfReea6TA8ZYGUTPdhzsx/zn6wdVWHTkpGvwDUHjl/owiyd+6fBEakKTavXng== 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=DZWoFWl6UeUNBnub918hc9odRLdyldbGXiwWe5U5WeE=; b=FXwYMMHU8CMW1nM0a95sn6xk5H5LSPRtJ0AmVHzXFhMSHma2ek+ZgYZuChRp4uIa15ZaLjEmODFFLESR+oNQdNpkI0gqjBugzT6NDRyttd9AoSQOxxBglSI1Dtj+4/2hG6iVmL0ZiUm0zTE9v6CbcCoLsQgBuoK/W99i3l8+qqzhH5sy4QuiMF4WIUghvnzkR8RQ166eo1J3eo1/bK7LxR3b5C31GpXOcTKOCEnBvnufCVS8G+wxfBRis+nYhB0eUkEhAdnRnl/0xVWWBgnauMq0c4qn5JyU3CMJA9GfMDp3D/hzsSkZQ4JXqQ6Fb4AzK24S/OPzuUh4Z9veWyjP9g== 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=DZWoFWl6UeUNBnub918hc9odRLdyldbGXiwWe5U5WeE=; b=he0jEvB8neMS3E/lawlIjatJNVwH672hlmbc+GOtMtyogivUD3WdKTODvdJv/bHztdTnndnttdQCFFdG7yQIl1Wb2pCb1BKb6XfgXfAp2NONQ8VY2nvWT/5uWKms3MyFNwTC4ftyPMeh3H8G6dQezUpuQ2eVM+XvEVBx7PwYLSw= 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 PH0PR11MB5111.namprd11.prod.outlook.com (2603:10b6:510:3c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16; Mon, 20 Sep 2021 09:45:59 +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.018; Mon, 20 Sep 2021 09:45:59 +0000 To: "Li, Xiaoyun" , "Wang, Jie1X" , "dev@dpdk.org" CC: "andrew.rybchenko@oktetlabs.ru" , "thomas@monjalon.net" , "jerinj@marvell.com" , "Ananyev, Konstantin" References: <20210826070924.308368-1-jie1x.wang@intel.com> <20210827081740.365037-1-jie1x.wang@intel.com> <20210827081740.365037-3-jie1x.wang@intel.com> <9d302c27-572b-2d03-4286-a19bc0b77779@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <07b5befe-d39d-2bf5-e306-c9b5e334faf5@intel.com> Date: Mon, 20 Sep 2021 10:45:53 +0100 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB7PR03CA0099.eurprd03.prod.outlook.com (2603:10a6:10:72::40) 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 DB7PR03CA0099.eurprd03.prod.outlook.com (2603:10a6:10:72::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16 via Frontend Transport; Mon, 20 Sep 2021 09:45:58 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 99586fb9-7070-4136-9aea-08d97c1b7399 X-MS-TrafficTypeDiagnostic: PH0PR11MB5111: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: J8WGYCr5V0GZay+NVWqPbEMYRtEr43FqlLCd+sToHB3UndTO5+Uxl7QF8D3Ur2V54llxbjMTAQxon1ixUoNVPE8zZJVNFss9CN385tyWggBNFYB0BXM2GfA61AuX/JiuG2/6I0BhA96/2nXa7GFp8vCMjvTFNie5AYW4u8AFYrUaMF3msD6+bnpB6Hy+WgfoCHVZ11LWIHqymFHGYwWqFX6Ds+SfI87ISmao8KzwgvUTGABwr24fYuc1pZjEHGEUWNheFmWqZJZ/1ttIugZ6X0J7QzfJr2emdUGHBF5A0y1UY6EPRZeIfh5Nx5bEjJdnpylXUsvTyzwsEru4K6flKsc44r2TdAIul7tBlQ4WKIsfTrgAiQI5ZiT1T2RVyT49On9LsU8YTVudq1gO8hKkbrgXvsUOqc0EdYxhGXab6hJWrM9ry1YVQuGIrJvO7SsZ8irKzthFBDW9cAnHDPJvrdbsHhfFpy3yPbNsC3wQ0mg9dFFhwjZZvBfmWjqDFpIF68oTgj+hH6s+ouy41qHWxnf6Z3L0JDlnEbk/pYg9cpR9RS/ofu1DG7bFm4ruPB431lqruYSx3qZOgVPLtINF8X1ueX911kn7+p+6pqz4nMUkHMCNmOMkRB/4jh5klsKrb/B5qIyUiDV8zQ56hrS+b/UxsBThBsESARQ18UnNvytHlTA46FvXNcvJU1Fwv73+Ixb0wkf9ZWeh1UIjys9yVw== 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)(366004)(39860400002)(346002)(396003)(376002)(136003)(36756003)(2906002)(5660300002)(8676002)(8936002)(478600001)(66556008)(53546011)(6486002)(110136005)(38100700002)(16576012)(4326008)(54906003)(66476007)(66946007)(2616005)(316002)(186003)(31686004)(26005)(86362001)(956004)(107886003)(31696002)(44832011)(6666004)(83380400001)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bGZuN215MXRQOERQUWZqNnc3dXlwZUFCL1hCeEhhTXd4MWFNOHZWekd3VndU?= =?utf-8?B?YTQrQVJlTXlEWkx0aHNVMm1zenc3OVo2UXNyTEtPOW9qelFMN05teTV3WnNU?= =?utf-8?B?M2dCMVJiZ3VKS0RKVFdsRUM1SjFacVAzT2k0VGZCVlBxdmlwclB0TDk2NXYy?= =?utf-8?B?L2ljNWRsMTJsRkswR3FHcEQvM1p5QVU4VzFaOWE4QU1tYXlNSUlIZ3pIVnF6?= =?utf-8?B?dHJnbDZoWUh5SkJpcHNndmpnWFc3N1lxOVVZTmV0dWI2QXF2cENoWnhXRkxX?= =?utf-8?B?ZS9EaTBBRzk2VFpMZTBnKzM3MTkvU045NEIzRWRSVmtlbHBGaUs3N1JlaUpX?= =?utf-8?B?VENBN0RUU0plM1FhaU5OakE2LzZEVlkvbGhqS3V6RDVXWmlyci81elUrZTdx?= =?utf-8?B?OEV1SHQvbXdyN09nUzRTWFhZNnNyVXpJR2lhZXd0TEZBZmxqQks1NDlTQTZU?= =?utf-8?B?L3RTYTEzR1dqbWJ3TmVENHdpWk9nOGNoSzUxZFlhY0hQZVNuNExvMUpKcmg2?= =?utf-8?B?aDIzeTdIVmsxcjZjYmRXQVJwb21UNFRXZFg3b1grcTVKVkUzbzd5RlIrQzAz?= =?utf-8?B?dDljTHE1SmhWTnpHbzZPSm1hTjJ2NzJmNkh2T1ZNT0Z4MjZrV05WNGhNR1lK?= =?utf-8?B?N05mb1FmcUlJSnhRaGpUOWMrM2xKRkJWTWxMd2txaEI2RnRHQmcxMzBldDRC?= =?utf-8?B?VTcwV3pnVy9iOHd5bXFoYnBiSzBIdGFlSUJwYnVyNm5EWkJSTzk0Vk9RYm90?= =?utf-8?B?SFFOS1B1Mmwxa0NiNTl3bGlYbEsrQTEzVFpyWmxxUFYxbTlFeUhod3BmK0lv?= =?utf-8?B?MWhZTFVwRzc4N1B2dWRwcEx1OWYrMGFoRDlnZ0xzQzZkN3QzSlh0cmhaUGFP?= =?utf-8?B?TmpueUR5cWd5MGhkNFN3eEdYNFUvMk5YRy8yd2thaWZnbDQ3M0RjcjBMb3Vq?= =?utf-8?B?V2RBOUkvWEgvYndsTHlmSC9tOWpNbzhqQXBQeUVDZ0xhbVkycnlIUFBubVFp?= =?utf-8?B?L0hsak56T0VpN1FUTmgydlFGQThPTy9WaHVzSWlRbTlJSzQ4d0p2REJoYVpO?= =?utf-8?B?Qy9NUG9pWmIzR2hQMzdPYzBoWm96WFRNNDB4U2tNZ3paVHBDYVZ6bzkvWDhX?= =?utf-8?B?NlJjelRVTXJGKzRzUXIxbnp5QThLOFRLd0JFNmNTQ2NvUVlmZEMzMExXMit1?= =?utf-8?B?S2hXUk50NHUxQThJdm1aR05KdXBQdDZCZElJQ3ZqK1VsdnlGQ1FySXFMcDQr?= =?utf-8?B?NHJpZklpZFl3Yjh4d1ZaS01kSzQySVU2b2RoeHBwaUVCSlFwR1c2Mm96T25p?= =?utf-8?B?VjZvdjl6eUZIcVVTeGVxZjIwWVFlaE1UWVlHcFM4dEpPem1QWENidzNTTEhW?= =?utf-8?B?aTdnVWdablE4NHZBcHFiMGZFVHVYWDhSNzY4VXJTLzN0cEs5NWpNK0VSMkhF?= =?utf-8?B?QVozUWhGRjVMSm9WZHUrTW1NMS9FZ0kxQVYyOVEveTdtWGtsaFkrOTBRNFlY?= =?utf-8?B?UzFPdTNYTEJVMThuUUVYYlczaGNkNnZoVlRRaUlkV1ljRklacDRXZkllUXAz?= =?utf-8?B?bGt3dlRTM21OR3l3bTFGcG12UTRhU1pxNUJrcFpTK1k5UnhKL1ZvdDBjME9U?= =?utf-8?B?dEEyZUpvTnZ6ekVYTHRwcHkzWGxCMXBUa24vRytuMWJDZDZML2d3MCs4NURh?= =?utf-8?B?QU52MWMyYUsySnlkMGtBc094Y2R3SnB5MTRPeERaNld1SmF3MWQ1cnBpTDhm?= =?utf-8?Q?59Sycf0wO9aDjSe5uF+Uny0qSlnIne+3G+d+PGC?= X-MS-Exchange-CrossTenant-Network-Message-Id: 99586fb9-7070-4136-9aea-08d97c1b7399 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2021 09:45:59.7681 (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: InfnYjgLzWArtU75Fz7e1wupa78A64ephLLuuQKWlRGyzTGe5/g3+4hl+9T1aSn6sr8f+QJflPscIoZ3lGRhcw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5111 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/18/2021 3:18 AM, Li, Xiaoyun wrote: > Hi > >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Friday, September 17, 2021 18:20 >> To: Li, Xiaoyun ; Wang, Jie1X ; >> dev@dpdk.org >> Cc: andrew.rybchenko@oktetlabs.ru; thomas@monjalon.net; >> jerinj@marvell.com; Ananyev, Konstantin >> Subject: Re: [PATCH v8 2/2] app/testpmd: fix testpmd doesn't show RSS hash >> offload >> >> 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? > > I'm not sure I fully understand. > So for showing cmd, just use API rte_eth_tx/rx_queue_info_get to get dev queue config and new added API rte_eth_dev_conf_info_get to get dev config. > > And for the cases where port->dev_config is used as a right value, replace them with use getting API. > For example: "if (res->value == port->dev_conf.rxmode.max_rx_pkt_len)" will be changed like "if (res->value == rte_eth_dev_conf_info_get().rxmode.max_rx_pkt_len)" > > But other things keep the same as what this patch does? > Yes. (Only I have a small comment on this patch, I will comment on other tread.) And for this patch I don't suggest any additional change other than RSS show, rest can be updated gradually. > This makes sense to me if I understand it right.