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 D4FA2A04B5; Wed, 13 Jan 2021 11:32:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BDE02140CCA; Wed, 13 Jan 2021 11:32:32 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id C99C2140CC7 for ; Wed, 13 Jan 2021 11:32:30 +0100 (CET) IronPort-SDR: 5bihfzpFr5IekBZO9ebJqx/AsnDiwqz9YKwUjPUolMy+QDnnyPyv3P4RR21HsFiXiv0nyjeuA7 4ZIq8TxjtZug== X-IronPort-AV: E=McAfee;i="6000,8403,9862"; a="175602623" X-IronPort-AV: E=Sophos;i="5.79,344,1602572400"; d="scan'208";a="175602623" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2021 02:32:29 -0800 IronPort-SDR: 0hv5x4G4l4P+9N22s+mQ/qH7woQDnnd/BIFOjcfjhAovsQtotd5MUfDyOhHo+y4QwIPx+PIjm7 z7Ekpm5thE0g== X-IronPort-AV: E=Sophos;i="5.79,344,1602572400"; d="scan'208";a="363839664" 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 02:32:16 -0800 To: Andrew Rybchenko , Steve Yang , dev@dpdk.org Cc: wenzhuo.lu@intel.com, beilei.xing@intel.com, bernard.iremonger@intel.com, asomalap@amd.com, rahul.lakkireddy@chelsio.com, hemant.agrawal@nxp.com, sachin.saxena@oss.nxp.com, jia.guo@intel.com, haiyue.wang@intel.com, 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, oulijun@huawei.com, jingjing.wu@intel.com, qiming.yang@intel.com, qi.z.zhang@intel.com, rosen.xu@intel.com, 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, mczekaj@marvell.com, thomas@monjalon.net, ivan.boule@6wind.com, konstantin.ananyev@intel.com, 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, helin.zhang@intel.com, yanglong.wu@intel.com, xiaolong.ye@intel.com, ting.xu@intel.com, xiaoyun.li@intel.com, dan.wei@intel.com, andy.pei@intel.com, vattunuru@marvell.com, skori@marvell.com, sony.chacko@qlogic.com, bruce.richardson@intel.com, ivan.malov@oktetlabs.ru, rad@semihalf.com, slawomir.rosek@semihalf.com, kamil.rytarowski@caviumnetworks.com, wei.zhao1@intel.com, junyux.jiang@intel.com, 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> From: Ferruh Yigit Message-ID: <00150f49-8778-579d-e6f2-bb2b09fdf243@intel.com> Date: Wed, 13 Jan 2021 10:32:12 +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 12/28/2020 2:51 PM, Andrew Rybchenko wrote: > On 12/17/20 12:22 PM, Steve Yang 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. >> >> Fixes: 59d0ecdbf0e1 ("ethdev: MTU accessors") >> >> Signed-off-by: Steve Yang >> --- >> lib/librte_ethdev/rte_ethdev.c | 21 ++++++++++++++++++--- >> 1 file changed, 18 insertions(+), 3 deletions(-) >> >> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c >> index 17ddacc78d..ff6a1e675f 100644 >> --- a/lib/librte_ethdev/rte_ethdev.c >> +++ b/lib/librte_ethdev/rte_ethdev.c >> @@ -1292,6 +1292,7 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, >> struct rte_eth_dev *dev; >> struct rte_eth_dev_info dev_info; >> struct rte_eth_conf orig_conf; >> + uint16_t overhead_len; >> int diag; >> int ret; >> >> @@ -1323,6 +1324,15 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, >> if (ret != 0) >> goto rollback; >> >> + /* Get the real Ethernet overhead length */ >> + if (dev_info.max_mtu && > > First of all I'm not sure that we need to handle 0 value > separately. Or it should be checked separately and trigger > an error since it is a driver mis-behaviour. > Agree. Most probably we can drop it, "dev_info.max_mtu != UINT16_MAX" covers the case driver doesn't provide any value. > If kept, it should be compared vs 0 explicitly in accordance > with DPDK coding style. > >> + dev_info.max_mtu != UINT16_MAX && >> + dev_info.max_rx_pktlen && > > It should be compared vs 0 explicitly in accordance > with DPDK coding style. > >> + dev_info.max_rx_pktlen > dev_info.max_mtu) >> + overhead_len = dev_info.max_rx_pktlen - dev_info.max_mtu; >> + else >> + overhead_len = RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN; >> + >> /* If number of queues specified by application for both Rx and Tx is >> * zero, use driver preferred values. This cannot be done individually >> * as it is valid for either Tx or Rx (but not both) to be zero. >> @@ -1410,13 +1420,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, >> goto rollback; >> } >> } else { >> - if (dev_conf->rxmode.max_rx_pkt_len < RTE_ETHER_MIN_LEN || >> - dev_conf->rxmode.max_rx_pkt_len > RTE_ETHER_MAX_LEN) >> + uint16_t pktlen = dev_conf->rxmode.max_rx_pkt_len; >> + if (pktlen < RTE_ETHER_MIN_MTU + overhead_len || >> + pktlen > RTE_ETHER_MTU + overhead_len) > > Alignment looks misleading. Either two tabs or just 4 spaces. > >> /* Use default value */ >> dev->data->dev_conf.rxmode.max_rx_pkt_len = >> - RTE_ETHER_MAX_LEN; >> + RTE_ETHER_MTU + overhead_len; >> } >> >> + /* Scale the MTU size to adapt max_rx_pkt_len */ >> + dev->data->mtu = dev->data->dev_conf.rxmode.max_rx_pkt_len - >> + overhead_len; >> + > > Is it expected side effect that re-configure always resets > previously set MTU. I.e.: > configure -> set_mtu -> start -> stop -> re-configure > and set MTU is lost. > This is the problem of two APIs updating same/related values, when device re-configure with a given 'max_rx_pkt_len', can we know if the intentions is update to the value to new provided 'max_rx_pkt_len' or not? For this case if user want to keep the MTU value, can read the MTU from device first and set 'max_rx_pkt_len' according it. And we can reduce to updating the MTU in the configure() only when JUMBO frame offload is requested, that should be when the 'max_rx_pkt_len' is valid only. >> /* >> * If LRO is enabled, check that the maximum aggregated packet >> * size is supported by the configured device. >> >