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 6F292A034F; Mon, 11 Oct 2021 21:47:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D907410FA; Mon, 11 Oct 2021 21:47:39 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 64FE940E0F for ; Mon, 11 Oct 2021 21:47:37 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10134"; a="287832112" X-IronPort-AV: E=Sophos;i="5.85,365,1624345200"; d="scan'208";a="287832112" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2021 12:47:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,365,1624345200"; d="scan'208";a="658786218" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga005.jf.intel.com with ESMTP; 11 Oct 2021 12:47:35 -0700 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 11 Oct 2021 12:47:34 -0700 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 11 Oct 2021 12:47:34 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx607.amr.corp.intel.com (10.18.126.87) 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, 11 Oct 2021 12:47:33 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.48) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Mon, 11 Oct 2021 12:47:33 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JIGK/Sj+M7Z1d+aD/aX6FTGnkadzW5oN+I13LlDLhg4cILpc9bp4QyeO9RLU7ds6qgrQ16MQq1hJ2c6CGMGQCGfAsXADbbsMApAFMqAvrMOyHmBm5oOkbWGvHEOrq/HQ5ItNfIV3z+rVYGM10GGJrGlI2KqhWQBGtAWMA0sdLeZSuP+XMbt98AwY2a9/unX8faUCjfROII2OvGqbt0kBu8sXkN7Yrj6OtxDNDaAfXckEk3omzXQfAtT4wnr7dBjWJA52x6NlKQTkAbVTEA23Xo1pqT/wNw8N4mBqmVanNC7H4qWItomA1kb0t6xNFplt027/8iyzAVbR5JGIlVISoA== 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=gtaAhWajcjD+qJMitD561U/8ucO7G1YlUf7SjJ+vMYY=; b=UKxSPgJix5fARi1TYfsS0UzgoIehUKF8sI0oyijlC2zj2c9fplSxHNyFa0dxEjLh3CQuE+7I219KtFuiOuH1dFzT6gq82HrYMSB6rA/c1jj1Px5DKifaOQGurZdvR34NKNKCkAIogvhsLUOFm+80cU+p61QKxQI+d3hRyJCU92VsMrSlJBsZFENOtGWP1S79X6nRGtnbkWzEoZ0Eskkil5DoXa1Vb9FSGFoyD+E/anfWYFK9rgWXy2uXJbB7v09V70qCo6W3UioepTbEAjCzlpHwuhjFTRtHMmnFWz3yazE0mc2W7W0w/OOnqkzRg8zat8SYAirP2SierNWea5V/VQ== 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=gtaAhWajcjD+qJMitD561U/8ucO7G1YlUf7SjJ+vMYY=; b=p+Fd1Do5U33U9N/FdRe7iLZxHwyykqL8H94IseEuwNasQ8scob1/LW/1DgHx19IkpOlJlGgcLCA5NOGEGMCcrTnp6TNBJ+dzUCcP7kWodp6oph5hjS1ZyJ3q/WZ77+4KDLkibdFQeSQ/xzK5YmTfqVmr8G1fpAU8I1hoPUUwGTo= 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 PH0PR11MB5901.namprd11.prod.outlook.com (2603:10b6:510:143::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Mon, 11 Oct 2021 19:47:20 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c%5]) with mapi id 15.20.4587.026; Mon, 11 Oct 2021 19:47:20 +0000 Message-ID: <2c09db13-6b0a-86c8-32c4-03d6ce5b3433@intel.com> Date: Mon, 11 Oct 2021 20:47:01 +0100 Content-Language: en-US To: "Ananyev, Konstantin" , Jerin Jacob , "Li, Xiaoyun" , Chas Williams , "Min Hu (Connor)" , Hemant Agrawal , Sachin Saxena , "Zhang, Qi Z" , "Wang, Xiao W" , "Matan Azrad" , Viacheslav Ovsiienko , Harman Kalra , Maciej Czekaj , "Ray Kinsella" , "Iremonger, Bernard" , Kiran Kumar K , Nithin Dabilpuram , "Hunt, David" , "Mcnamara, John" , "Richardson, Bruce" , Igor Russkikh , Steven Webster , "Peters, Matt" , Somalapuram Amaranath , Rasesh Mody , Shahed Shaikh , Ajit Khaparde , "Somnath Kotur" , Sunil Kumar Kori , Satha Rao , Rahul Lakkireddy , "Wang, Haiyue" , Marcin Wojtas , Michal Krawczyk , "Shai Brandes" , Evgeny Schemeilin , "Igor Chauskin" , Gagandeep Singh , "Daley, John" , Hyong Youb Kim , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , Yisen Zhuang , Lijun Ou , "Xing, Beilei" , "Wu, Jingjing" , "Yang, Qiming" , Andrew Boyer , "Xu, Rosen" , Shijith Thotton , Srisivasubramanian Srinivasan , Zyta Szpak , Liron Himi , Heinrich Kuhn , Devendra Singh Rawat , Andrew Rybchenko , "Wiles, Keith" , Jiawen Wu , Jian Wang , Maxime Coquelin , "Xia, Chenbo" , "Chautru, Nicolas" , "Van Haaren, Harry" , "Dumitrescu, Cristian" , "Nicolau, Radu" , Akhil Goyal , "Kantecki, Tomasz" , "Doherty, Declan" , Pavan Nikhilesh , "Rybalchenko, Kirill" , "Singh, Jasvinder" , Thomas Monjalon CC: "dev@dpdk.org" References: <20211001143624.3744505-1-ferruh.yigit@intel.com> <20211007165626.2941995-1-ferruh.yigit@intel.com> From: Ferruh Yigit X-User: ferruhy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DB6PR07CA0071.eurprd07.prod.outlook.com (2603:10a6:6:2a::33) 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 DB6PR07CA0071.eurprd07.prod.outlook.com (2603:10a6:6:2a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.4 via Frontend Transport; Mon, 11 Oct 2021 19:47:06 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1baddbc4-d5d9-4f1a-680e-08d98cefef65 X-MS-TrafficTypeDiagnostic: PH0PR11MB5901: X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr 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: 53YszNHei8jWcWcPWSWGmN1S/pyhTKYoJJ4gRk2Xw6xboKpOMAXd0f+QdCdbbvoD7D0vE4kDwj45H6oHJEgRQZJme3y6/yCZjC7klxEjbu1AeCyOm4OrHm4haRkmkQ2lAC7OYaZ67PeD4i3DX+QbzcoUqtz+bhOCMz5ROqc4ic8Vh/helD1Ko7J6bTL8zKCB7G7D5fe3l8pS3ekGUs51ZPegWVzGxEAAiCIZFcQgiIgT4OrUwHJIHDKxwhdteWYGrWopwFpy0HRH8MnBWqCMHlfDcvhYJYijidELVuIq2RBByt5ryXwEFtsinPM5yl83lkM7/vC9nruISzPbggpdZCicJjcz9LGNfGqgTy1+gxYRuqYrj5CsSjwu40oo4PjX+i+NHMGuGhUC8ID2kkr4xz6KQBm9YHgwYqGhNy/HT9SYFoXWisQ1ybmGH3krlDfh4pgP07s1H7Pn9OUh9H+KzNufEfB4TrWwKIIsi9Csda1vahgemab0xCXU8H9uf8MDDUMLYsK6eZzIxi+aj/W7MWLzlDMaJN+MBohKi8RV+ZVLUuMioKnbCj7Zt2/uElSamrFsZUW3fYlB7HWFt/B2IhSKJ1UHxMj1cuV6hodkvAVNqfR/RXu/UtiyAEbS17mJRF/NHdDxrrCRz3v1Mf6bElVbcJXJsD3Wa5nLrXTtpzxpwCFaNXMPlwVNvCYo0nNzFFsOY/n56qbJT1eandL0L24Z/9oWqaRc4qAfKfdJdpU= 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)(921005)(7366002)(7406005)(7416002)(36756003)(6486002)(1191002)(2906002)(38100700002)(44832011)(5660300002)(16576012)(110136005)(316002)(8936002)(31686004)(83380400001)(31696002)(508600001)(86362001)(4326008)(186003)(8676002)(26005)(53546011)(6666004)(66946007)(66556008)(956004)(2616005)(66476007)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N0RqcGl0N3lLb0tTSkFReDF4R0tUR0hUUEFEUEJHMnV4bFEweDQ2cEloYS9k?= =?utf-8?B?dWZOeUxmcDNGZ2ZqQ0VNZ1VBaHJhN3F3em1mbFp6eEhKT2k5TWIzZVdMaDN6?= =?utf-8?B?endGNE1zRzQ1SUN0L243M1l2NHFpLzlaVUVETWFteDI5S3lnSUg2ZmxINHlH?= =?utf-8?B?d2Z3Snh5ZllEV2xEVGhpQ2RQZzk2SXkxWHNaeTNXZ0hGQ21CVGM0bXY5bXN5?= =?utf-8?B?M1FqTDN4MXRINHdHcWVKcHNQZU9KRko0RHA1eU9CL1NSeHY0bVZZLy9pTFZ3?= =?utf-8?B?cmRjOGZhbUQrbCsvaXMzT3RrR29Iek9UdkdheXNsZE9sRHRITjRZcmx2Vjhh?= =?utf-8?B?SjhLQmhoT0VLWGpCSGsyL3pmSnhNVkFWeW9aYXJsTXAyZU9kdEduODdTNlRs?= =?utf-8?B?SzBzUVhjbE8yK0hDVHAyWDhUaW4zNk1iT2RkT2lLbXVPMk1mZkhRY3VkRnAw?= =?utf-8?B?WEhiM1FnK1NZWFREc3h3OTV4aVFGUWpxelRSdmNQRnMrYlI2Si9zSWVSZHZU?= =?utf-8?B?dzZsb2RSckhWMHdmRkdCYXowZGxteHpsbHZkNXlqZ2s1RFU2WG04TWNodHhQ?= =?utf-8?B?WGxuQXhybUR5U1VvbjJORitPT0U3bXpLbVMvU09MTy81blRYTm94YVZRS2FW?= =?utf-8?B?QW81dnc5YkQvaklZR0pUclBrc2ord05DN0VpY0ZIeHl1cDVQUXZkM3p2Sk9j?= =?utf-8?B?VjlNRUlLWjM3Z1FvazZGcnVKV1NDUlRHMEpGbWcyKzVqdXpvMENLQURnNzBV?= =?utf-8?B?SEJoVlVscFhvY3NnMnVKekNCQ0dRZ2xPRW9Xb2NybWZWSTFrTHBBa0lldWNM?= =?utf-8?B?TllRTStzUUNkZFZtT1VKT1k3N2xBMklOOXZramJkWmFjczFBOUZCRFZpazJP?= =?utf-8?B?R2o2b013akJvODM5dG1wZklwRE5IK3lCTCt2T2hZYzdNajhQRDZ6ZkJjK0tF?= =?utf-8?B?MnB6V2FkNXU5cnBCc0RsaUpFYzh0M2hXdGJHc3R3bjdQTU44QjZ0M0oxdkE2?= =?utf-8?B?cWZNVjIwZEs2c3ZlYTc2T2dzRVkxcmR4RlNLODhTOVFiRmJJY3E3dUdGTzhB?= =?utf-8?B?Y1Nub3BCMGxHUUYwNXliajVsYmZQU2lRSDZBZk5WcmtvRktSZDExYTJmQVF0?= =?utf-8?B?VnB4eGlObjJWeGpJL2hNa1JKWjNkMXhSV1N0RmNJVHZEUHBMaVhjUWR4OVh5?= =?utf-8?B?NkhZU2NxRUJLcnpLdU5RSGI4YU5XQXBKNG1QSzQ0K2RnTlpRRnRPcENTUlhG?= =?utf-8?B?ZDVrTC84cEZHVTJ3ZUNNT0REUWVpa0JWMUpHVUVoWGRONDRnM0hMM2NlSHM1?= =?utf-8?B?anloZlMyNnpZdmg0djR3ektqNTMxTklNQU9vMVFScUZac2lWQk1NK0ZMTmRZ?= =?utf-8?B?R3UzUmowMWNtbXZuRmVpTkRuOE8zSWFvMVJTUU1qZTRwbFNkeTdJVkpudTlr?= =?utf-8?B?Y3RYSUpWci8zVmdSYzdkTUY4Z09nU3MxSjZNTzZhVWZnNUR6eWVWZXBwLzc1?= =?utf-8?B?S3hpTmp1bzMrc094T0tJZU5XcWhaRUtyWTUwVXJxZ2Z2SWZSRXJSZ1ZqUWNK?= =?utf-8?B?alhVeitQdVFCSEoxWDVLTmVLVXIzOXJ4ZFhhTk1LaHV6blNLVHBzT1FVOTg4?= =?utf-8?B?Y0FXT3kyVDg4encyL3NjanVZM21EMFN0UVhJZml6TnFBelNkdlQ2bWlHV1Uv?= =?utf-8?B?eVcwV2s2MEF5aVVZaktnTVNSWW14TEYwajBWVVZCekxPa3U1ZmZEb25rbm5o?= =?utf-8?Q?L4lgPjVwaacabnV5ayQmAnzT/IBgl0lst4oz44f?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1baddbc4-d5d9-4f1a-680e-08d98cefef65 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2021 19:47:19.9869 (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: euCEj+ZaFeOu5tGj5JLBdDeSJraGxQZo5dKp6Z4/do20HCmdm4AVguB9zG9cF/ATlqRc0iBuOypMIe2HmcZnPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5901 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v5 1/6] ethdev: fix max Rx packet length 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 10/8/2021 4:57 PM, Ananyev, Konstantin wrote: > > >> There is a confusion on setting max Rx packet length, this patch aims to >> clarify it. >> >> 'rte_eth_dev_configure()' API accepts max Rx packet size via >> 'uint32_t max_rx_pkt_len' field of the config struct 'struct >> rte_eth_conf'. >> >> Also 'rte_eth_dev_set_mtu()' API can be used to set the MTU, and result >> stored into '(struct rte_eth_dev)->data->mtu'. >> >> These two APIs are related but they work in a disconnected way, they >> store the set values in different variables which makes hard to figure >> out which one to use, also having two different method for a related >> functionality is confusing for the users. >> >> Other issues causing confusion is: >> * maximum transmission unit (MTU) is payload of the Ethernet frame. And >> 'max_rx_pkt_len' is the size of the Ethernet frame. Difference is >> Ethernet frame overhead, and this overhead may be different from >> device to device based on what device supports, like VLAN and QinQ. >> * 'max_rx_pkt_len' is only valid when application requested jumbo frame, >> which adds additional confusion and some APIs and PMDs already >> discards this documented behavior. >> * For the jumbo frame enabled case, 'max_rx_pkt_len' is an mandatory >> field, this adds configuration complexity for application. >> >> As solution, both APIs gets MTU as parameter, and both saves the result >> in same variable '(struct rte_eth_dev)->data->mtu'. For this >> 'max_rx_pkt_len' updated as 'mtu', and it is always valid independent >> from jumbo frame. >> >> For 'rte_eth_dev_configure()', 'dev->data->dev_conf.rxmode.mtu' is user >> request and it should be used only within configure function and result >> should be stored to '(struct rte_eth_dev)->data->mtu'. After that point >> both application and PMD uses MTU from this variable. >> >> When application doesn't provide an MTU during 'rte_eth_dev_configure()' >> default 'RTE_ETHER_MTU' value is used. >> >> Additional clarification done on scattered Rx configuration, in >> relation to MTU and Rx buffer size. >> MTU is used to configure the device for physical Rx/Tx size limitation, >> Rx buffer is where to store Rx packets, many PMDs use mbuf data buffer >> size as Rx buffer size. >> PMDs compare MTU against Rx buffer size to decide enabling scattered Rx >> or not. If scattered Rx is not supported by device, MTU bigger than Rx >> buffer size should fail. > > LGTM in general, one question below. > > ... > >> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c >> index daf5ca924221..4d0584af52e3 100644 >> --- a/lib/ethdev/rte_ethdev.c >> +++ b/lib/ethdev/rte_ethdev.c >> @@ -1324,6 +1324,19 @@ eth_dev_validate_offloads(uint16_t port_id, uint64_t req_offloads, >> return ret; >> } >> >> +static uint16_t >> +eth_dev_get_overhead_len(uint32_t max_rx_pktlen, uint16_t max_mtu) >> +{ >> + uint16_t overhead_len; >> + >> + if (max_mtu != UINT16_MAX && max_rx_pktlen > max_mtu) >> + overhead_len = max_rx_pktlen - max_mtu; > > In theory it could be overflow here, though I do realize that in practise it is unlikely situation. > Anyway why uint16_t, why not uint32_t for all variables here? > Just no to worry about such things. > That is related to the practically expected values, it should work fine to use 'uint32_t', so I will switch to it in next version.