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 B7A94A0C47; Tue, 12 Oct 2021 13:03:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 758424112E; Tue, 12 Oct 2021 13:03:35 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 7E3F94067C for ; Tue, 12 Oct 2021 13:03:33 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10134"; a="224532676" X-IronPort-AV: E=Sophos;i="5.85,367,1624345200"; d="scan'208";a="224532676" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2021 04:03:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,367,1624345200"; d="scan'208";a="480307792" Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18]) by orsmga007.jf.intel.com with ESMTP; 12 Oct 2021 04:03:31 -0700 Received: from orsmsx606.amr.corp.intel.com (10.22.229.19) by ORSMSX605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 12 Oct 2021 04:03:30 -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; Tue, 12 Oct 2021 04:03:30 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.176) 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; Tue, 12 Oct 2021 04:03:30 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qx1tblEDvHSoGfnxvqmSylCaU2ofc6Hr/h2+bvHPexqQf9auNWOJ3/fYJbh0LMYMXYnAcV68TvOwQFpbLkleX9iSfZlqvnBsGdi95lMHfDBiJ2vaTRhgsdxpZLgyYWhmPsUv3NHqenktIqYqvG3CTPWdjw7yutszrSKI552Ou96f1Y1Fz9AbfUI2xB5O4g+PuptvUr+nSjlzsWM4owJXf9ZsEe+Kq2LnOtRRCA7DVNZ7SPPqGM2G1CF1rvKYWEYTdM0aHGh7oj2EGSHz2sOkiB0AzyxEGxwom2P0DscF8v7ek8Tiwp1VW0x9TTYVtMh1yKr1MpX9w1nHMokc+kMvYg== 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=KdgLG8UNobD1FSTexYMpKUQvCjcWuXNo/TcIl2Ug8/c=; b=Nh5AN4kwkaizdKS8cgMJQpjR8Jp1R7lw8k8aCEpC02tHiSfvWC2cxb9yspYDK368QBGUncfo16uoKiKD1t5tIzK0IlwMvfupGxXGkzlGyfOd5z/VJYns+YWSK4yoD32hctd1WsWFJyHBNKvbfG0AgSzDk2hERhPnuk8c1j/CaEBAT0Sc+2qo1zFoT7huB/NAm4UTE6gCLbFuviPEoZsVFVyLl/nbCHeOHYvTxbncNkViuMoRlQDWY/mOZj+0sCAEwi3bCqKRZPPStQmg8N2OH5EwlHXfJ76l4X2LGzN/+zYhOL1C7gVYdVa85NeSWzz6598OJxXtypm1sou9dpdUfw== 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=KdgLG8UNobD1FSTexYMpKUQvCjcWuXNo/TcIl2Ug8/c=; b=WgA6DcPssAjBmrxcy3DJSgL0s0FcowDv3uMTm4Ig2pXIXjpKFVXccpPY7ZyVXrMCl8DcmWIDWi7fmiqOw6qj3VGeDVbAA5Lfki2I0MZIQjN7g1ccDB3ECbJNLPyPr415eyE08axKhW6Fd7+vegEoccEOXws/SO7PGZfqxOo/7N4= Authentication-Results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH7PR11MB5864.namprd11.prod.outlook.com (2603:10b6:510:136::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Tue, 12 Oct 2021 11:03:24 +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; Tue, 12 Oct 2021 11:03:24 +0000 Message-ID: <9b937a68-7189-c30e-164c-3317a53145f2@intel.com> Date: Tue, 12 Oct 2021 12:03:05 +0100 Content-Language: en-US To: Matan Azrad , Jerin Jacob , "Xiaoyun Li" , Chas Williams , "Min Hu (Connor)" , Hemant Agrawal , Sachin Saxena , Qi Zhang , Xiao Wang , Slava Ovsiienko , "Harman Kalra" , Maciej Czekaj , Ray Kinsella , Bernard Iremonger , "Konstantin Ananyev" , Kiran Kumar K , Nithin Dabilpuram , "David Hunt" , John McNamara , "Bruce Richardson" , Igor Russkikh , Steven Webster , "Matt Peters" , Somalapuram Amaranath , Rasesh Mody , Shahed Shaikh , "Ajit Khaparde" , Somnath Kotur , Sunil Kumar Kori , Satha Rao , Rahul Lakkireddy , Haiyue Wang , Marcin Wojtas , "Michal Krawczyk" , Shai Brandes , "Evgeny Schemeilin" , Igor Chauskin , "Gagandeep Singh" , John Daley , Hyong Youb Kim , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , "Yisen Zhuang" , Lijun Ou , Beilei Xing , Jingjing Wu , Qiming Yang , Andrew Boyer , Rosen Xu , Shijith Thotton , Srisivasubramanian Srinivasan , Zyta Szpak , Liron Himi , Heinrich Kuhn , Devendra Singh Rawat , Andrew Rybchenko , Keith Wiles , Jiawen Wu , Jian Wang , Maxime Coquelin , Chenbo Xia , Nicolas Chautru , Harry van Haaren , Cristian Dumitrescu , Radu Nicolau , Akhil Goyal , Tomasz Kantecki , Declan Doherty , "Pavan Nikhilesh" , Kirill Rybalchenko , Jasvinder Singh , NBU-Contact-Thomas Monjalon , Dekel Peled CC: "dev@dpdk.org" References: <20211001143624.3744505-1-ferruh.yigit@intel.com> <20211005171653.3700067-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: 8bit X-ClientProxiedBy: DU2PR04CA0224.eurprd04.prod.outlook.com (2603:10a6:10:2b1::19) 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 DU2PR04CA0224.eurprd04.prod.outlook.com (2603:10a6:10:2b1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25 via Frontend Transport; Tue, 12 Oct 2021 11:03:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1d3ee812-706e-4fcd-bf73-08d98d6fe8b0 X-MS-TrafficTypeDiagnostic: PH7PR11MB5864: 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:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cTQXui/qTCj//i+RyyAh91CxquvpjUuOXBAhXTIzuby7qgUXVLXGNf8GM4m04JECt//+5qgi9sPos3onB5DFZ1X7mXTslNPtfAKU4XTOJYhYpRyjoHLfe0nQEF7rSMhEb1UIPufDsDVgNxeKJJfzbXQv4/rbn9T0fGsJRaaQ0ZGJwF0i8Yic2WvMOU8b89y2gTdqzQocB93/OSAcgjNeMIVgLibLQqkgaAn039s4sEJ0xJMplUFmD61ytySdhfI+t/TajzdJVx9147PqMZVmXu6HGAevMF77y0wdQ8PLf0GbQ/LpKCDsp0TzCKdo/d3wLXtEMD+bmDR3VYPbuJ1Q5PhukoQDTY8JwXkrkfqJB7pXDtx2gEMizTrKZyzwRZcH+Xh8VawNdG39Al7OKVOzOMvrUWpOR2dtvifFoXL9+QZOCLax//rGekwkt5AQhPntkU5ULLeoNQM/Y9QNdqEG6n+ORmtsHcO1lxY2k6Kys1GbwKFWmsJn5+9gcNC/pQfavDDeSAAful8Sa2PO0A3i/zq3eVscDHHJXPmf2NmeG3FdSeg3+tWWzEF3yESeS3d/WL5LYSmQJFxvQjsIHYf3jnCzjGr5uLTEygwoWhA2AXK5OQSGoik2GUO/Y267G6xe3Fdk0VeZ1bNe6m/n7oVv1hE8Tb+30xYAvuM33qnPSiri3eNiBgdiEYeCwE6lus5+por10qVXrzDQl75QsS/xPwSoVC9m5RrrCzUPrH7oujU= 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)(26005)(110136005)(44832011)(4326008)(8676002)(16576012)(8936002)(6486002)(7416002)(7406005)(31686004)(66946007)(86362001)(921005)(316002)(7366002)(1191002)(2616005)(66476007)(508600001)(2906002)(6666004)(956004)(5660300002)(83380400001)(36756003)(38100700002)(186003)(53546011)(66556008)(31696002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q1NGQ054V2FUNEwxZ01WVGNtVzFVWS9laWhJWmtVMjF0U29ZNEJubVBHd0Iv?= =?utf-8?B?amlJTmJXTzhweUxKU1AwcWJXV3orMWkyUVltTFdHWEdZL2ZHdlhwTml5UFli?= =?utf-8?B?ckE0VTcvdUV4Z0NhM0Y1TE1hRUtFWGtJNlZhUHoxNCt2QnpMRnM0eStGNDF6?= =?utf-8?B?RmNIZ0NuMDVPYkVxamxUSXYvQ3FIUi9QamprdjVKdkJjQUxFTFlqZ0R0R21I?= =?utf-8?B?TGhMUnBmTERhK2Z3d1pqbWN3bkE2aWdENThtajM3dEM0RDQvaHpkaGVwUTYy?= =?utf-8?B?bWUwVjZFSWlnc2ZOUWNlR05ML2Nab1NwVi9mSzluZlNqbGVGMWlQc0JlYlNQ?= =?utf-8?B?Z3JRUlV6NHVJZnFmTDIwdC9mMEc2MlFSTDVzdjhFRm1rWmVvbGtlRGk0UmU2?= =?utf-8?B?dXhaOVNmSk5VeFE3Z1RoR3lPaVBjN2I2QzVFK0phRElqOXFYcTArTzlSZWQ3?= =?utf-8?B?dVlBZ2NZK1NTZEdmMDdOY1ZkOG9XRmxVMTBURTdiYmQzUTAvUUdoUGlkTWNL?= =?utf-8?B?UzB4dDlPZ2FtYUJUaUpFVFc2Vm1KenFKUWplYUZqL1BTai9jek5BSUFQeXRv?= =?utf-8?B?LzJkR0lVT0tqV082MUxLd3ZQaDFINVVRZWJXajk3cmtRdW1UbS9HV1ZnN25H?= =?utf-8?B?c1RLbncwa01NM25VZnA0a2FqbWl4amVkNUlnL1dwSGk3UWsydm55ZCtCbGc0?= =?utf-8?B?VTA0NmZxdVFqbW5mVXFhT09EaTB5SUVhc1hTK2RpK0tCQkFBNGhvMzhIcVZE?= =?utf-8?B?SkhaWXY0Mm9oUDd3dksxQm5iN04vSU5QSFVLbnh4bGoxenJGazFYSmQzUlZR?= =?utf-8?B?amJId20vT0FDSkVJQytFY0lXc2FtU1NZNHJXZWlsS3pMRlY0U05ucm1mYkFZ?= =?utf-8?B?SThCNEM0bnZIdDhLaUlpMmVrcFpPV0Q1SzJJZUIwWnhtYnRsMEE1alpoL0Ur?= =?utf-8?B?UHVuT2VyWkVzc2lDRzFrNTFlNWREN3ZqbVpzRE41VE5uTzgyeHdrN005VkJz?= =?utf-8?B?MDQzNmhveDdKdnVWNFJ0QlFaZE1FSjlneU5hcm1Sc0JWWmVveGNMclVybElz?= =?utf-8?B?c1Mxa1FMektCK0ZBUVNNczh5SjFZa0xVL0JoK1crMVJha1ZWWEVEMTZPb3V0?= =?utf-8?B?VkNHS2M4ekMrUU5sem4zUS9xdGM0dkZuNGJCeEIxNWs4eEZuYU5Xc3ZtR0Fo?= =?utf-8?B?dDRXb2ZwRzdRejdvY2pzYXpZdUlOd3p2SG5nM1dlMVczc0wwNGd3OEpWRnVY?= =?utf-8?B?ZjVqejdDNENMY3JCUEd1c2pQWW44V1hSanEyM1pITWNIS1BSZ21tNGw0QWJC?= =?utf-8?B?NGNyZ1crZzR5c3NzOVhDMXFFRUUzczRyZUNhR25vRmV5SDlCOXlhNlkzNGZh?= =?utf-8?B?NUhzL2pVckhTT2V6RHprcC9VZWdGM1IrM28vUitzWkZYQ3BTenlSTDdoSlZP?= =?utf-8?B?NTNSbWpJdmR4VUFhR3U0VEkrUDBZcEY2M3ZRV0lSbUJpR0huNlc4OGhPSEt5?= =?utf-8?B?LzNETmlKWmRPcFZ1WGRXeWd6VXkyRkR3V1Z2Vko0OWc2dTczQ2w2eVBubmp3?= =?utf-8?B?V2tsVitXK25XZmxoaXZvVEV3L0RyYk80K2QzM0ZsS3hIK1hVNUdJcGdWSnB2?= =?utf-8?B?SUQwSEZWYW9RL25oTkQyY2kxaGhENlNSTEpacGRsRnc3NkZ4aENValIza1Jk?= =?utf-8?B?VnpyOHVRT2pYNm1Zc3BOa1hiNW1RVXVZUmoxWmc5UE10QVc3VHliWWRYRGcr?= =?utf-8?Q?pwUdqTQE80U94zLfW7rHNvkIgkpAV0NpBkApKJs?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1d3ee812-706e-4fcd-bf73-08d98d6fe8b0 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2021 11:03:24.0472 (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: Vf9nsJKpqGvPaWKl5eHqnesOLO/tnFNURkJKsfQwBafxfnxhaGUfYlI9ymK6nkxGFeBTMo/7frtMjcxPTorAEg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB5864 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v4 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/12/2021 8:03 AM, Matan Azrad wrote: > Hi Ferruh > > From: Ferruh Yigit >> On 10/10/2021 7:30 AM, Matan Azrad wrote: >>> >>> Hi Ferruh >>> >>> From: Ferruh Yigit >>>> 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. >>> >>> Should it be compared also against max_lro_pkt_size for the SCATTER >> enabling by the PMD? >>> >> >> I kept the LRO related code same, the Rx packet length change patch already >> become complex, LRO related changes can be done later instead of making >> this set more confusing. >> It would be great if you and Dekel can work on it as you introduced the >> 'max_lro_pkt_size' in ethdev. > > 'max_lro_pkt_size' is not like MTU (the LRO is done after the PHY received the packet in MTU size.), > I just asked regarding the SCATTER comparison for this case; I think it should be the same comparison as MTU. > >>> What do you think about enabling SCATTER by the API instead of making >> the comparison in each PMD? >>> >> >> Not sure if we can do that, as far as I can see there is no enforcement on the >> Rx buffer size but PMDs select it. > > Yes, it looks like currently, it is the PMD decision. > And we can take scattering later(we all the time say that 😊). > These details being not clear cause drivers implement slightly different, which makes later hard to decide which one is correct design and update those various implementations. 'max_rx_pkt_len' was one of those nuisances that took some time to address. For the others, agree to address them, just not in this set, what you have mentioned is: 1) 'max_lro_pkt_size' 2) Scattered Rx configuration Can you please make a patch to update deprecation notice for them? At least documenting them prevents us to forget (or postpone) them. Later we can find an owner, start a discussion thread and fix them for v22.11. Does it sound reasonable? > Acked-by: Matan Azrad > > Maybe, it is good to report the device's max Rx buffer length to let the application have more information to configure the most efficient mbuf size and whether it may get scattered packets or not. > Also, it will help do all the validations in ethdev layer. > > > >