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 B28C9A0C47; Tue, 12 Oct 2021 08:02:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6EAA04067C; Tue, 12 Oct 2021 08:02:15 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id AB09540150 for ; Tue, 12 Oct 2021 08:02:13 +0200 (CEST) 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)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 0EB807F50A; Tue, 12 Oct 2021 09:02:13 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 0EB807F50A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634018533; bh=tSAfajL3x5s63lPGIV+uGj/CayKBH1noGAQyNZ7iMKM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=kH4Y+yFbshW5oDige+5DrT69WS4+vRthxGGJ7XPx+PWclPGk28gagtZcELZQWK7BF QrabFKFjAWY+8fS/f0PiD8nh49kyDMtUB805x/D2cAnhrZ5q5mdnyaoDCXXq/AeXh0 VHs90lkFTdu/3geoAyomcKn27SDjWBA9cEcZKPYE= To: Ferruh Yigit , Jerin Jacob , Xiaoyun Li , Chas Williams , "Min Hu (Connor)" , Hemant Agrawal , Sachin Saxena , Qi Zhang , Xiao Wang , Matan Azrad , Viacheslav Ovsiienko , Harman Kalra , Maciej Czekaj , Ray Kinsella , Bernard Iremonger , Konstantin Ananyev , Kiran Kumar K , Nithin Dabilpuram , David Hunt , John McNamara , Bruce Richardson , Igor Russkikh , Steven Webster , Matt Peters , Somalapuram Amaranath , Rasesh Mody , Shahed Shaikh , Ajit Khaparde , Somnath Kotur , Sunil Kumar Kori , Satha Rao , Rahul Lakkireddy , Haiyue Wang , Marcin Wojtas , Michal Krawczyk , Shai Brandes , Evgeny Schemeilin , Igor Chauskin , Gagandeep Singh , John Daley , Hyong Youb Kim , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , Yisen Zhuang , Lijun Ou , Beilei Xing , Jingjing Wu , Qiming Yang , Andrew Boyer , Rosen Xu , Shijith Thotton , Srisivasubramanian Srinivasan , Zyta Szpak , Liron Himi , Heinrich Kuhn , Devendra Singh Rawat , Keith Wiles , Jiawen Wu , Jian Wang , Maxime Coquelin , Chenbo Xia , Nicolas Chautru , Harry van Haaren , Cristian Dumitrescu , Radu Nicolau , Akhil Goyal , Tomasz Kantecki , Declan Doherty , Pavan Nikhilesh , Kirill Rybalchenko , Jasvinder Singh , Thomas Monjalon Cc: dev@dpdk.org, Huisong Li References: <20211001143624.3744505-1-ferruh.yigit@intel.com> <20211011235345.851742-1-ferruh.yigit@intel.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <93f2dfcb-7238-0dc4-ac72-1f9171abd00e@oktetlabs.ru> Date: Tue, 12 Oct 2021 09:02:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211011235345.851742-1-ferruh.yigit@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 1/6] 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 10/12/21 2:53 AM, Ferruh Yigit wrote: > 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' field 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 having two different method for a related > functionality 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, and this overhead 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. > > Additional clarification done on scattered Rx configuration, in > relation to MTU and Rx buffer size. > MTU is used to configure the device for physical Rx/Tx size limitation, > Rx buffer is where to store Rx packets, many PMDs use mbuf data buffer > size as Rx buffer size. > PMDs compare MTU against Rx buffer size to decide enabling scattered Rx > or not. If scattered Rx is not supported by device, MTU bigger than Rx > buffer size should fail. > > Signed-off-by: Ferruh Yigit > Acked-by: Ajit Khaparde > Acked-by: Somnath Kotur > Acked-by: Huisong Li Acked-by: Andrew Rybchenko