From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 35F30A09FF; Mon, 28 Dec 2020 15:51:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 77CCAC9FA; Mon, 28 Dec 2020 15:51:22 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id 4396CC9F2 for ; Mon, 28 Dec 2020 15:51:20 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 767107F527; Mon, 28 Dec 2020 17:51:18 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 767107F527 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1609167078; bh=HJVA+KQKGqVSsTjN4o83+m8fyb4LyV/uj6qU2WXMeBw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=RJ9di3FAkAEYPUM7VMksSsO9BnKFxhRRMMksGwQ78Dz2Eedkn8eeCk+JxTWnctljA Mdk20dbYW5Q28fIgZjUCunJR5zwm7P5rBlBN6STTXHuGrDvlYCbeGMu96v0Kpc6dTP 3Pa1MTXnsmhH4On3+skYyVY8GebHrv14vk3VMmTU= To: 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, ferruh.yigit@intel.com, 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: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Mon, 28 Dec 2020 17:51:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20201217092312.27033-2-stevex.yang@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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.15 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/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. 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. > /* > * If LRO is enabled, check that the maximum aggregated packet > * size is supported by the configured device. >