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 73E8EA052A; Mon, 25 Jan 2021 13:41:49 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 61A40140F27; Mon, 25 Jan 2021 13:41:49 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id D3A94140EB6 for ; Mon, 25 Jan 2021 13:41:47 +0100 (CET) IronPort-SDR: p3WKgvKu0y81WYiG4gTPylch0TMOdAzd0uMi99v9wYJSG9lfTAM8/p/dIqs1CLe9e6bHKH/n2c OpsimamYLpkg== X-IronPort-AV: E=McAfee;i="6000,8403,9874"; a="179797112" X-IronPort-AV: E=Sophos;i="5.79,373,1602572400"; d="scan'208";a="179797112" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2021 04:41:46 -0800 IronPort-SDR: ItXgllojOJGlwqQsJqqGUif5dQGUaNU/dw/NHoXY+zMqzqU3ZJmY0ZJe05F7+ljWUpG3GjJN+R GQhRjlLMn7Cg== X-IronPort-AV: E=Sophos;i="5.79,373,1602572400"; d="scan'208";a="361478371" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.243.89]) ([10.213.243.89]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2021 04:41:44 -0800 To: Steve Yang , dev@dpdk.org Cc: wenzhuo.lu@intel.com, xiaoyun.li@intel.com, bernard.iremonger@intel.com, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, qiming.yang@intel.com References: <20210122090110.50453-1-stevex.yang@intel.com> <20210125083202.38267-1-stevex.yang@intel.com> <20210125083202.38267-2-stevex.yang@intel.com> From: Ferruh Yigit Message-ID: <2a9c547c-d052-f1b1-323e-e1b9a650cfbc@intel.com> Date: Mon, 25 Jan 2021 12:41:43 +0000 MIME-Version: 1.0 In-Reply-To: <20210125083202.38267-2-stevex.yang@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 1/2] ethdev: fix MTU doesn't update when jumbo frame disabled 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/25/2021 8:32 AM, Steve Yang wrote: > The MTU value should be updated to 'max_rx_pkt_len - overhead' > no matter if the JUMBO FRAME offload enabled. If not update this MTU, > use will get the wrong MTU info via some command. > E.g.: 'show port info all' in testpmd tool. > > Actually, the 'max_rx_pkt_len' has been used for other purposes in many > places now, even though the 'max_rx_pkt_len' is expected 'Only used if > JUMBO_FRAME enabled'. > > For examples, > 'max_rx_pkt_len' perhaps can be used as the 'rx_ctx.rxmax' in i40e. > > Fixes: bf0f90d92d30 ("ethdev: fix max Rx packet length check") > > Signed-off-by: Steve Yang > --- > lib/librte_ethdev/rte_ethdev.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > index daf5f24f7e..42857e3b67 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -1421,10 +1421,6 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, > ret = -EINVAL; > goto rollback; > } > - > - /* Scale the MTU size to adapt max_rx_pkt_len */ > - dev->data->mtu = dev->data->dev_conf.rxmode.max_rx_pkt_len - > - overhead_len; > } else { > uint16_t pktlen = dev_conf->rxmode.max_rx_pkt_len; > if (pktlen < RTE_ETHER_MIN_MTU + overhead_len || > @@ -1434,6 +1430,10 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, > 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; > + > /* > * If LRO is enabled, check that the maximum aggregated packet > * size is supported by the configured device. > This will cause 'max_rx_pkt_len' taken into account even 'JUMBO_FRAME' is not set, this is against the API documentation. PMD can ignore the 'max_rx_pkt_len' when 'JUMBO_FRAME' is not set, so updating the 'max_rx_pkt_len' is relatively harmless, but updating 'MTU' can have affect. Instead what do you think explicitly call 'rte_eth_dev_set_mtu()' in the testpmd when the MTU of the port needs to be changed because of "port config all max-pkt-len" command?