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 959ACA0C51; Wed, 21 Jul 2021 17:30:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3E3B34014D; Wed, 21 Jul 2021 17:30:23 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id 20D4840143 for ; Wed, 21 Jul 2021 17:30:19 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10052"; a="191731614" X-IronPort-AV: E=Sophos;i="5.84,258,1620716400"; d="scan'208";a="191731614" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2021 08:30:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,258,1620716400"; d="scan'208";a="462427192" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga008.jf.intel.com with ESMTP; 21 Jul 2021 08:30:06 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) 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.10; Wed, 21 Jul 2021 08:30:03 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Wed, 21 Jul 2021 08:30:03 -0700 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (104.47.56.40) 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.10; Wed, 21 Jul 2021 08:30:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z32VifdyMYl7XattiOBXJ4gTyCKh2kkXIIkf/L4YAwf5mMBcHPsd2LVZMI1uvprjV/uXa7PdcTaS3ozSBsxMqS/dXiwWctvsqT/WmWdNLyknX1Ru3ro9+oNiGgawqFg1aF/+/o7EQbZz4jD4cSg3C2J5VuNp7eDTeU6eDpo55GH9jaDfRqS9k8x6xgZXN4NCUWhVnfOz9lZ8gUDtUdqpLYIGCMDNNyfV1TCQdH1FxPljVua2d8sOf8K+pXKmphRl4klXhDDMQ93NCwCPTsImZHOWceKW/JAEI/jke3+H2bQrVqmMAeHo+JRpYNfPeR/U8FBCa8p87ILAqg3CMFeNNQ== 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-SenderADCheck; bh=glt9hQrZ3KgcVH6Rgde7pUqJCAPMBYkNoD13THCBnTw=; b=KrNvoL14BPCQszoM3E0L+vlX+GFyofkPhdqG0ghgvhkhcq5H4L5rsCxLBlUm7GdsMY7yoMyQKiFv1H3JYOK/bwDUwtOl2oHyPMMU109bBA3Yf8IfmXmevWgBWt3ShSIJuicKE2NGX/5J0GqcgfTVZpDVTmhVKDS4et+SlnO5UjN/Nsa0vwvgZTLKeaA1c8Qs2qKZzF9NBdzMob9/qMMdSBNxqxQAHJ/tvtzgzdmmqhj1HkGALCFCs/KXAaQszkxZZ42SFGnhqWRY0U6D1aHcppavk7uX6CE7gYhmqN2ve6rgG408qq75gLRewrTcgbSSr919dB98hrsFeZxvUF5k3Q== 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=glt9hQrZ3KgcVH6Rgde7pUqJCAPMBYkNoD13THCBnTw=; b=JdASUrXC4q7M9o9AneFm7Iv6xMEV882lX84bLGFnVC9jPjJ6692XC49/ShfhSpJcuuzlIDqIyPsHn/tLuOKMIViemjoyxB/dxhZ14l/5KkyKTYn04XYKdQzo52pSYjsS62U/1aJ2ACFHE7C8+MjKfnI8P9+LW6TiFFnm0AjMT08= Authentication-Results: dpdk.org; dkim=none (message not signed) header.d=none;dpdk.org; dmarc=none action=none header.from=intel.com; Received: from SJ0PR11MB5005.namprd11.prod.outlook.com (2603:10b6:a03:2d3::21) by BYAPR11MB2598.namprd11.prod.outlook.com (2603:10b6:a02:cb::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.23; Wed, 21 Jul 2021 15:29:59 +0000 Received: from SJ0PR11MB5005.namprd11.prod.outlook.com ([fe80::a018:c8bc:f54e:514c]) by SJ0PR11MB5005.namprd11.prod.outlook.com ([fe80::a018:c8bc:f54e:514c%7]) with mapi id 15.20.4331.034; Wed, 21 Jul 2021 15:29:59 +0000 To: Huisong Li CC: "dev@dpdk.org" References: <20210709172923.3369846-1-ferruh.yigit@intel.com> <1a891390-1122-6dcf-03e8-1f0b147b30ec@huawei.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <4e1ae26c-197b-ea45-0860-66c195d1f820@intel.com> Date: Wed, 21 Jul 2021 16:29:46 +0100 In-Reply-To: <1a891390-1122-6dcf-03e8-1f0b147b30ec@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: JNXP275CA0018.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:19::30) To SJ0PR11MB5005.namprd11.prod.outlook.com (2603:10b6:a03:2d3::21) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.206] (37.228.236.146) by JNXP275CA0018.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:19::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21 via Frontend Transport; Wed, 21 Jul 2021 15:29:57 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cf3eb815-29b2-4a9d-7d32-08d94c5c66d5 X-MS-TrafficTypeDiagnostic: BYAPR11MB2598: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ODSOENu2T6rJMnsZlZ/JUDA6BFX+G7+1Pv3rB6UukhldN4LJHMlSxQ3J5oMIN7IdZMVZDSpcIamtKAgROJROu2dVkGM+60BnJ2GA4iTWtMQokdhbORLrMM6Tsn5/DPUCxcpY41pJc6KbPoJmHZQK9/rf8NxMCvxNuB3FsgvpsmLp5gd6+bn93GqUmrvXckId8HjvVQ82XGmnoZ/wCZ++kGYlIJE3dVSYb2fbtJhlHmVV6cXyNO6eIZkBGPuLd6s5Uf+uHekZvRM0DRsVM5BftpqcLdlzPmPMMF+jMtZ1l440ABHUlxuOBDCPKg8a+USzTlr+K1cAMrK3ARidCXQg1m/M9pVQHJX2TB6tHtwrwfA6ELuRa31fdlajybU/+1d4gRd9gNw601XWosIyFdWL6Maw0+lVZ/ypKaVHNSBw3EU9uR489SldZBa0EqMhse6XtwM1uDKl2vBBEWPLo7DBy8dGBok3wrBKpmJQgFk05kkqyv/GUvW+Od35ZKx4hAwZWr6ggfNWgl5QHyK4pvCmv+S1z/0IjbaM3BxLO+FeYt8p4QSwUdybDBBi8daLAnQw3wUcE+rvBAm7ONcmoXMKCUAemLhge7XpKxSO8NaQgfnNVQ1T4bLLXiYDCP2AuSjot6n7+Q22zIdbEeaJ586wUPS7nCACnBgESUicWoiH9LevO1IFG8UIeKTa1DuYWjfPyybznVUDc5tM9FKOGoGmjQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB5005.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(366004)(346002)(39860400002)(136003)(5660300002)(66476007)(66946007)(316002)(86362001)(26005)(6666004)(66556008)(38100700002)(44832011)(4326008)(8676002)(8936002)(2616005)(31696002)(186003)(31686004)(30864003)(53546011)(956004)(6916009)(36756003)(83380400001)(2906002)(478600001)(6486002)(16576012)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NkdUZ0VRakd3RXJCT2w0M25iM1ZQOWI2bmU5UHpHeHY5Q3JZOTZNejdad0pq?= =?utf-8?B?czR6QzhYdVMvTUNTd3d3N0pmNG01QXZ1MXdUMEw4MW1NdncxUFlDdlh1MlVs?= =?utf-8?B?R0lkQWVSOTM2ajFsWWlZMWNSeFZjcHNkZ21zUmsyNWsxcnYrcElpSEdtcWJt?= =?utf-8?B?Q0xneS93dUI3Y1VpQkZMYVY2eUYzTmQwRys2ajBKVUhjTjFRUGR2dmRWK1dB?= =?utf-8?B?dE5NdEVIVzduR1hRb1c4NDd0dHI5YStGemQ2Yi9ReWNaSkpRMjZla2FaVVp0?= =?utf-8?B?QnJnZVFFdE5ubHdaM2xKdkIxVjZWTEE2Q3p1S294S2NVcldPd2plSnZZdW5P?= =?utf-8?B?RjZiak43UTlXRmxjRFl1WGFrRHZYYjZ2NkhSNGhnQllaTE9RenlSaG9GUkNh?= =?utf-8?B?Qy93YzRpWStob2ptQ1h0U2VXc3YrNml1eHlVUURlOW14c0REOXA1ZmRpVm9i?= =?utf-8?B?NjZ0aDBobHdkYXB0NFY2Yk85dXM3aTVZVnhYRjU2cTVDbm55T3l3S0paUTZ4?= =?utf-8?B?UmVMUjZMZDFkQ2pQSzRTNWtoS2pjK1VUeEtueEtyK1J0alpSdXpGSUEzQ2g1?= =?utf-8?B?YVdiUGhLM1lnMU5hQTFVSVVZNVkxYVNFYk9Fdm5ZcS9XZDc2cnZvY05ocjBn?= =?utf-8?B?bzVXSS9EMG1yVkZZbDRzYjNTZ3F4MFhGNnYyUVZjMmw5OHJDNnFTd0JLK1dI?= =?utf-8?B?elFrUDNiMDhWTW1ZVTBOdmN6R01zdHVXUEtjbUJBWDVoRG1JMkhyR3ZvbE9s?= =?utf-8?B?Smx4cEZyOEFBdktZUlM0aFFNU1ozSnBZc29NYzcwQVRrVXdNRG12YTlnclRO?= =?utf-8?B?TWk2R2FEVlYwQUF3aFlPZTRhb01LMGY0QndqSE5qNGJqek9SMlZUWjFuRitL?= =?utf-8?B?Tk9iTXdWcXFtZ3l0bkdRMWVPdVlYWDFoczIvYjYxdkJ6RjZGZ0VEZFZtM3Mr?= =?utf-8?B?dlU5b1QwWURrQTByM2FSZTZtRDM2bHpGVjk1QW9hWjF2VE5lQTZIeGRJUytp?= =?utf-8?B?dkZBWlRrWTc5ZEgxMWdqWFdiMFpvVUc0RDVYTU0weG0vMmxTTWlvaDA1TWpi?= =?utf-8?B?c0RuK2Q2SXB1ZHpDRjJYekxRVWExeFhKUWFxQ0dDald3TDNDbWRoTzVWS3pE?= =?utf-8?B?SDRNVUxmRjZKTFNDRUhHMVZ6WW50eHdBejRuR01nSHZIWStad0hrWFdRMmF0?= =?utf-8?B?aUUzWEJBalh2a3Vxc3VrQzUwTk5VUmhOZFJhejArbUtrTkx1eTNRWCt0aDB5?= =?utf-8?B?RGVZbXk1bDJrVFhGN2Nsemp5NExjWXo1WTdqcGRoL21HL2VrazJiQlVkSkxo?= =?utf-8?B?R2xQWFRwbmtHRGkycHhKU2dOL1RIK0dEdjZCcVI1d3pGcWM3TFd6WWtyUFF2?= =?utf-8?B?NmVBRVI4VHhVcUZwTFBhOVB4d2MwcDRiNUFNM2loMklDaW5ab1VmcDdSaFpk?= =?utf-8?B?akQyTjIrbkM4SkQ0c3RoMGhEek9oTEVUc0htOWZNbkZxZHdicGd2a01uWGJz?= =?utf-8?B?V21FQUZTSFFvNHowMTVUZmtDTWp4QU5PYnZVWEJrS2dzOEtYcnFRN25icVA4?= =?utf-8?B?Mi9razRYbzlZWjhLOHBPSm04MmlWSTF0bmNYK3pqK1Y3OU1IdldibWptTC9k?= =?utf-8?B?aDNydnhQdngvMkV5VDl3Q1RoRGRzTXgrT0MvYnIvNTdtaVE1cG4rOXdQMklV?= =?utf-8?B?bG1KVzNiOUZYWUFibU92U0VPWVQrYk9UZEYvR3V1dzBwSHhhSVJJbVJIN3I4?= =?utf-8?Q?rOr4DLpiMNC0rEOnueh3Kom4jiI7vkuxiHmtei7?= X-MS-Exchange-CrossTenant-Network-Message-Id: cf3eb815-29b2-4a9d-7d32-08d94c5c66d5 X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5005.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2021 15:29:59.7427 (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: Eo+MSt4CPMGFY1sDMAesiATZO0l84ygTrGz/fFQvqbz2No3YTRnvZQ/jl7CX2cLyhQBGib2E5Ckz/ID9Z3PakA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2598 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 1/4] 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 7/19/2021 4:35 AM, Huisong Li wrote: > Hi, Ferruh > Hi Huisong, Thanks for the review. > 在 2021/7/10 1:29, 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' filed 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 two different related method 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, but this 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. >> >> As additional clarification, MTU is used to configure the device for >> physical Rx/Tx limitation. Other related issue is size of the buffer to >> store Rx packets, many PMDs use mbuf data buffer size as Rx buffer size. >> And compares MTU against Rx buffer size to decide enabling scattered Rx >> or not, if PMD supports it. If scattered Rx is not supported by device, >> MTU bigger than Rx buffer size should fail. >> >> Signed-off-by: Ferruh Yigit <...> >> diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c >> index e51512560e15..8bccdeddb2f7 100644 >> --- a/drivers/net/hns3/hns3_ethdev.c >> +++ b/drivers/net/hns3/hns3_ethdev.c >> @@ -2379,20 +2379,11 @@ hns3_refresh_mtu(struct rte_eth_dev *dev, struct >> rte_eth_conf *conf) >>   { >>       struct hns3_adapter *hns = dev->data->dev_private; >>       struct hns3_hw *hw = &hns->hw; >> -    uint32_t max_rx_pkt_len; >> -    uint16_t mtu; >> -    int ret; >> - >> -    if (!(conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME)) >> -        return 0; >> +    uint32_t max_rx_pktlen; >>   -    /* >> -     * If jumbo frames are enabled, MTU needs to be refreshed >> -     * according to the maximum RX packet length. >> -     */ >> -    max_rx_pkt_len = conf->rxmode.max_rx_pkt_len; >> -    if (max_rx_pkt_len > HNS3_MAX_FRAME_LEN || >> -        max_rx_pkt_len <= HNS3_DEFAULT_FRAME_LEN) { >> +    max_rx_pktlen = conf->rxmode.mtu + HNS3_ETH_OVERHEAD; >> +    if (max_rx_pktlen > HNS3_MAX_FRAME_LEN || >> +        max_rx_pktlen <= HNS3_DEFAULT_FRAME_LEN) { >>           hns3_err(hw, "maximum Rx packet length must be greater than %u " >>                "and no more than %u when jumbo frame enabled.", >>                (uint16_t)HNS3_DEFAULT_FRAME_LEN, > > The preceding check for the maximum frame length was based on the scenario where > jumbo frames are enabled. > > Since there is no offload of jumbo frames in this patchset, the maximum frame > length does not need to be checked and only ensure conf->rxmode.mtu is valid. > > These should be guaranteed by dev_configure() in the framework . > Got it, agree that 'HNS3_DEFAULT_FRAME_LEN' check is now wrong, and as you said these checks are becoming redundant, so I will remove them. In that case 'hns3_refresh_mtu()' becomes just wrapper to 'hns3_dev_mtu_set()', I will remove function too. <...> >> diff --git a/drivers/net/hns3/hns3_ethdev_vf.c >> b/drivers/net/hns3/hns3_ethdev_vf.c >> index e582503f529b..ca839fa55fa0 100644 >> --- a/drivers/net/hns3/hns3_ethdev_vf.c >> +++ b/drivers/net/hns3/hns3_ethdev_vf.c >> @@ -784,8 +784,7 @@ hns3vf_dev_configure(struct rte_eth_dev *dev) >>       uint16_t nb_rx_q = dev->data->nb_rx_queues; >>       uint16_t nb_tx_q = dev->data->nb_tx_queues; >>       struct rte_eth_rss_conf rss_conf; >> -    uint32_t max_rx_pkt_len; >> -    uint16_t mtu; >> +    uint32_t max_rx_pktlen; >>       bool gro_en; >>       int ret; >>   @@ -825,29 +824,21 @@ hns3vf_dev_configure(struct rte_eth_dev *dev) >>               goto cfg_err; >>       } >>   -    /* >> -     * If jumbo frames are enabled, MTU needs to be refreshed >> -     * according to the maximum RX packet length. >> -     */ >> -    if (conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) { >> -        max_rx_pkt_len = conf->rxmode.max_rx_pkt_len; >> -        if (max_rx_pkt_len > HNS3_MAX_FRAME_LEN || >> -            max_rx_pkt_len <= HNS3_DEFAULT_FRAME_LEN) { >> -            hns3_err(hw, "maximum Rx packet length must be greater " >> -                 "than %u and less than %u when jumbo frame enabled.", >> -                 (uint16_t)HNS3_DEFAULT_FRAME_LEN, >> -                 (uint16_t)HNS3_MAX_FRAME_LEN); >> -            ret = -EINVAL; >> -            goto cfg_err; >> -        } >> - >> -        mtu = (uint16_t)HNS3_PKTLEN_TO_MTU(max_rx_pkt_len); >> -        ret = hns3vf_dev_mtu_set(dev, mtu); >> -        if (ret) >> -            goto cfg_err; >> -        dev->data->mtu = mtu; >> +    max_rx_pktlen = conf->rxmode.mtu + HNS3_ETH_OVERHEAD; >> +    if (max_rx_pktlen > HNS3_MAX_FRAME_LEN || >> +        max_rx_pktlen <= HNS3_DEFAULT_FRAME_LEN) { >> +        hns3_err(hw, "maximum Rx packet length must be greater " >> +             "than %u and less than %u when jumbo frame enabled.", >> +             (uint16_t)HNS3_DEFAULT_FRAME_LEN, >> +             (uint16_t)HNS3_MAX_FRAME_LEN); >> +        ret = -EINVAL; >> +        goto cfg_err; >>       } > Please remove this check now, thanks! ack <...> >> diff --git a/examples/ip_reassembly/main.c b/examples/ip_reassembly/main.c >> index ce8882a45883..f868e5d906c7 100644 >> --- a/examples/ip_reassembly/main.c >> +++ b/examples/ip_reassembly/main.c >> @@ -162,7 +162,7 @@ static struct lcore_queue_conf >> lcore_queue_conf[RTE_MAX_LCORE]; >>   static struct rte_eth_conf port_conf = { >>       .rxmode = { >>           .mq_mode        = ETH_MQ_RX_RSS, >> -        .max_rx_pkt_len = JUMBO_FRAME_MAX_SIZE, >> +        .mtu = JUMBO_FRAME_MAX_SIZE, > > It feel likes that the replacement of max_rx_pkt_len with MTU is inappropriate. > > Because "max_rx_pkt_len " is the sum of  "mtu" and "overhead_len". You are right, it is not same thing. I will update it to remove overhead. <...> >> @@ -1448,49 +1459,45 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t >> nb_rx_q, uint16_t nb_tx_q, >>       } >>         /* >> -     * If jumbo frames are enabled, check that the maximum RX packet >> -     * length is supported by the configured device. >> +     * Check that the maximum RX packet length is supported by the >> +     * configured device. >>        */ >> -    if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) { >> -        if (dev_conf->rxmode.max_rx_pkt_len > dev_info.max_rx_pktlen) { >> -            RTE_ETHDEV_LOG(ERR, >> -                "Ethdev port_id=%u max_rx_pkt_len %u > max valid value %u\n", >> -                port_id, dev_conf->rxmode.max_rx_pkt_len, >> -                dev_info.max_rx_pktlen); >> -            ret = -EINVAL; >> -            goto rollback; >> -        } else if (dev_conf->rxmode.max_rx_pkt_len < RTE_ETHER_MIN_LEN) { >> -            RTE_ETHDEV_LOG(ERR, >> -                "Ethdev port_id=%u max_rx_pkt_len %u < min valid value %u\n", >> -                port_id, dev_conf->rxmode.max_rx_pkt_len, >> -                (unsigned int)RTE_ETHER_MIN_LEN); >> -            ret = -EINVAL; >> -            goto rollback; >> -        } >> +    if (dev_conf->rxmode.mtu == 0) >> +        dev->data->dev_conf.rxmode.mtu = RTE_ETHER_MTU; > Here, it will cause a case that the user configuration is inconsistent with the > configuration saved in the framework . What is the framework you mentioned? Previously 'max_rx_pkt_len' was mandatory when jumbo frame is configured even user doesn't really case about it and it was causing additional complexity in the configuration. This check is required to use defaults when application doesn't need a specific value, I believe this is a good usability improvement. Application who cares about a specific value can set it explicitly and it will be in sync with application. > Is it more reasonable to provide a prompt message? Not sure about it. We are not changing a user configured value, but using default value when application doesn't set it, and that kind of log will be printed by most of the applications, this may cause noise. >> +    max_rx_pktlen = dev->data->dev_conf.rxmode.mtu + overhead_len; >> +    if (max_rx_pktlen > dev_info.max_rx_pktlen) { >> +        RTE_ETHDEV_LOG(ERR, >> +            "Ethdev port_id=%u max_rx_pktlen %u > max valid value %u\n", >> +            port_id, max_rx_pktlen, dev_info.max_rx_pktlen); >> +        ret = -EINVAL; >> +        goto rollback; >> +    } else if (max_rx_pktlen < RTE_ETHER_MIN_LEN) { >> +        RTE_ETHDEV_LOG(ERR, >> +            "Ethdev port_id=%u max_rx_pktlen %u < min valid value %u\n", >> +            port_id, max_rx_pktlen, RTE_ETHER_MIN_LEN); >> +        ret = -EINVAL; >> +        goto rollback; >> +    } > > Above "max_rx_pktlen < RTE_ETHER_MIN_LEN " case will be  inconsistent with > dev_set_mtu() API. > > The reasons are as follows: > > The value of RTE_ETHER_MIN_LEN is 64. If "overhead_len" is 26 caculated by > eth_dev_get_overhead_len(), it means > > that dev->data->dev_conf.rxmode.mtu equal to 38 is reasonable. > > But, in  dev_set_mtu() API, the check for mtu is: > > @@ -3643,12 +3644,27 @@ rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu) >   >          if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu) >              return -EINVAL; > > It should be noted that dev_info.min_mtu is RTE_ETHER_MIN_MTU (68). > Agree on the inconsistency. RTE_ETHER_MIN_MTU is 68, that is min MTU for IPv4 RTE_ETHER_MIN_LEN is 64, and min MTU for Ethernet frame Although we are talking about MTU, we are mainly concerned about Ethernet frame payload, not IPv4. I suggest only using RTE_ETHER_MIN_LEN. Since this inconsistency was already there before this patch, I will update it in seperate patch instead of fixing in this one.