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 306B7A04B5; Wed, 13 Jan 2021 12:04:42 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D084B140CFC; Wed, 13 Jan 2021 12:04:41 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id AD0FD140CF6 for ; Wed, 13 Jan 2021 12:04:39 +0100 (CET) IronPort-SDR: VYCfi8LUn+mut02ZuT+b1sqdOq4fuhAJZArQG4aSKn+sgjl+869Y3Sdqpctlb0FQzhMUDvWhi9 J8jY4ZiUw4GQ== X-IronPort-AV: E=McAfee;i="6000,8403,9862"; a="157963015" X-IronPort-AV: E=Sophos;i="5.79,344,1602572400"; d="scan'208";a="157963015" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2021 03:04:38 -0800 IronPort-SDR: XvanxOdZIidmHPAjQN6TPQrdO1lVzf7jSZvRcNRl1lX0ehqBU5j2suJB0Mts3LwWyyzmW11ejB RPHA76NMwWjg== X-IronPort-AV: E=Sophos;i="5.79,344,1602572400"; d="scan'208";a="363850358" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.253.194]) ([10.213.253.194]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2021 03:04:24 -0800 To: "Yang, SteveX" , oulijun , "dev@dpdk.org" Cc: "Lu, Wenzhuo" , "Xing, Beilei" , "Iremonger, Bernard" , "asomalap@amd.com" , "rahul.lakkireddy@chelsio.com" , "hemant.agrawal@nxp.com" , "sachin.saxena@oss.nxp.com" , "Guo, Jia" , "Wang, Haiyue" , "g.singh@nxp.com" , "xuanziyang2@huawei.com" , "cloud.wangxiaoyun@huawei.com" , "zhouguoyang@huawei.com" , "xavier.huwei@huawei.com" , "humin29@huawei.com" , "yisen.zhuang@huawei.com" , "Wu, Jingjing" , "Yang, Qiming" , "Zhang, Qi Z" , "Xu, Rosen" , "sthotton@marvell.com" , "srinivasan@marvell.com" , "heinrich.kuhn@netronome.com" , "hkalra@marvell.com" , "jerinj@marvell.com" , "ndabilpuram@marvell.com" , "kirankumark@marvell.com" , "rmody@marvell.com" , "shshaikh@marvell.com" , "andrew.rybchenko@oktetlabs.ru" , "mczekaj@marvell.com" , "thomas@monjalon.net" , "ivan.boule@6wind.com" , "Ananyev, Konstantin" , "samuel.gauthier@6wind.com" , "david.marchand@6wind.com" , "shahafs@mellanox.com" , "stephen@networkplumber.org" , "maxime.coquelin@redhat.com" , "olivier.matz@6wind.com" , "lihuisong@huawei.com" , "shreyansh.jain@nxp.com" , "wei.dai@intel.com" , "fengchunsong@huawei.com" , "chenhao164@huawei.com" , "tangchengchang@hisilicon.com" , "Zhang, Helin" , "yanglong.wu@intel.com" , "xiaolong.ye@intel.com" , "Xu, Ting" , "Li, Xiaoyun" , "Wei, Dan" , "Pei, Andy" , "vattunuru@marvell.com" , "skori@marvell.com" , "sony.chacko@qlogic.com" , "Richardson, Bruce" , "ivan.malov@oktetlabs.ru" , "rad@semihalf.com" , "slawomir.rosek@semihalf.com" , "kamil.rytarowski@caviumnetworks.com" , "Jiang, JunyuX" , "kumaras@chelsio.com" , "girish.nandibasappa@amd.com" , "rolf.neugebauer@netronome.com" , "alejandro.lucero@netronome.com" References: <20201209031628.29572-1-stevex.yang@intel.com> <20201217092312.27033-1-stevex.yang@intel.com> <20201217092312.27033-2-stevex.yang@intel.com> <6a6dc10b-aa1d-76f6-2c4e-a8368253bdd9@huawei.com> From: Ferruh Yigit Message-ID: Date: Wed, 13 Jan 2021 11:04:20 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2 01/22] ethdev: fix MTU size exceeds 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 1/6/2021 3:36 AM, Yang, SteveX wrote: <...> >>> If max rx packet length is smaller then MTU + Ether overhead, that >>> will drop all MTU size packets. >>> >>> Update the MTU size according to the max rx packet and Ether overhead. >>> Can you please elaborate the explanation a little more, it is hard to understand the problem with above description. Problem is: " Ethdev is using default Ethernet overhead to decide if provided 'max_rx_pkt_len' value is bigger than max (non jumbo) MTU value, and limits it to MAX if it is. Since the application/driver used Ethernet overhead is different than the ethdev one, check result is wrong. If the driver is using Ethernet overhead bigger than the default one, the provided 'max_rx_pkt_len' is trimmed down, and in the driver when correct Ethernet overhead is used to convert back, the resulting MTU is less than the intended one, causing some packets to be dropped. Like, app -> max_rx_pkt_len = 1500/*mtu*/ + 22/*overhead*/ = 1522 ethdev -> 1522 > 1518/*MAX*/; max_rx_pkt_len = 1518 driver -> MTU = 1518 - 22 = 1496 Packets with size 1497-1500 are dropped although intention is to be able to send/receive them. The fix is to make ethdev use the correct Ethernet overhead for port, instead of default one. " Addition to above, the code reviews suggest slight difference, like dropping the ethdev check completely for non-jumbo packets, please reflect them to the commit log if changes are implemented. >>> Fixes: 59d0ecdbf0e1 ("ethdev: MTU accessors") >>> >>> Signed-off-by: Steve Yang >>> ---