Hi, > -----Original Message----- > From: Yigit, Ferruh <ferruh.yi...@intel.com> > Sent: Tuesday, October 12, 2021 7:54 > To: Jerin Jacob <jer...@marvell.com>; Li, Xiaoyun <xiaoyun...@intel.com>; > Chas Williams <ch...@att.com>; Min Hu (Connor) <humi...@huawei.com>; > Hemant Agrawal <hemant.agra...@nxp.com>; Sachin Saxena > <sachin.sax...@oss.nxp.com>; Zhang, Qi Z <qi.z.zh...@intel.com>; Wang, > Xiao W <xiao.w.w...@intel.com>; Matan Azrad <ma...@nvidia.com>; > Viacheslav Ovsiienko <viachesl...@nvidia.com>; Harman Kalra > <hka...@marvell.com>; Maciej Czekaj <mcze...@marvell.com>; Ray Kinsella > <m...@ashroe.eu>; Iremonger, Bernard <bernard.iremon...@intel.com>; > Ananyev, Konstantin <konstantin.anan...@intel.com>; Kiran Kumar K > <kirankum...@marvell.com>; Nithin Dabilpuram > <ndabilpu...@marvell.com>; Hunt, David <david.h...@intel.com>; > Mcnamara, John <john.mcnam...@intel.com>; Richardson, Bruce > <bruce.richard...@intel.com>; Igor Russkikh <irussk...@marvell.com>; > Steven Webster <steven.webs...@windriver.com>; Peters, Matt > <matt.pet...@windriver.com>; Somalapuram Amaranath > <asoma...@amd.com>; Rasesh Mody <rm...@marvell.com>; Shahed > Shaikh <shsha...@marvell.com>; Ajit Khaparde > <ajit.khapa...@broadcom.com>; Somnath Kotur > <somnath.ko...@broadcom.com>; Sunil Kumar Kori <sk...@marvell.com>; > Satha Rao <skotesh...@marvell.com>; Rahul Lakkireddy > <rahul.lakkire...@chelsio.com>; Wang, Haiyue <haiyue.w...@intel.com>; > Marcin Wojtas <m...@semihalf.com>; Michal Krawczyk <m...@semihalf.com>; > Shai Brandes <shaib...@amazon.com>; Evgeny Schemeilin > <evge...@amazon.com>; Igor Chauskin <igo...@amazon.com>; Gagandeep > Singh <g.si...@nxp.com>; Daley, John <johnd...@cisco.com>; Hyong Youb > Kim <hyon...@cisco.com>; Ziyang Xuan <xuanziya...@huawei.com>; > Xiaoyun Wang <cloud.wangxiao...@huawei.com>; Guoyang Zhou > <zhouguoy...@huawei.com>; Yisen Zhuang <yisen.zhu...@huawei.com>; > Lijun Ou <ouli...@huawei.com>; Xing, Beilei <beilei.x...@intel.com>; Wu, > Jingjing <jingjing...@intel.com>; Yang, Qiming <qiming.y...@intel.com>; > Andrew Boyer <abo...@pensando.io>; Xu, Rosen <rosen...@intel.com>; > Shijith Thotton <sthot...@marvell.com>; Srisivasubramanian Srinivasan > <sriniva...@marvell.com>; Zyta Szpak <z...@semihalf.com>; Liron Himi > <lir...@marvell.com>; Heinrich Kuhn <heinrich.k...@corigine.com>; > Devendra Singh Rawat <dsinghra...@marvell.com>; Andrew Rybchenko > <andrew.rybche...@oktetlabs.ru>; Wiles, Keith <keith.wi...@intel.com>; > Jiawen Wu <jiawe...@trustnetic.com>; Jian Wang > <jianw...@trustnetic.com>; Maxime Coquelin > <maxime.coque...@redhat.com>; Xia, Chenbo <chenbo....@intel.com>; > Chautru, Nicolas <nicolas.chau...@intel.com>; Van Haaren, Harry > <harry.van.haa...@intel.com>; Dumitrescu, Cristian > <cristian.dumitre...@intel.com>; Nicolau, Radu <radu.nico...@intel.com>; > Akhil Goyal <gak...@marvell.com>; Kantecki, Tomasz > <tomasz.kante...@intel.com>; Doherty, Declan <declan.dohe...@intel.com>; > Pavan Nikhilesh <pbhagavat...@marvell.com>; Rybalchenko, Kirill > <kirill.rybalche...@intel.com>; Singh, Jasvinder > <jasvinder.si...@intel.com>; Thomas Monjalon <tho...@monjalon.net> > Cc: Yigit, Ferruh <ferruh.yi...@intel.com>; dev@dpdk.org; Huisong Li > <lihuis...@huawei.com> > Subject: [PATCH v6 1/6] ethdev: fix max Rx packet length > > 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 <ferruh.yi...@intel.com> > Acked-by: Ajit Khaparde <ajit.khapa...@broadcom.com> > Acked-by: Somnath Kotur <somnath.ko...@broadcom.com> > Acked-by: Huisong Li <lihuis...@huawei.com> > --- > Cc: Min Hu (Connor) <humi...@huawei.com> > > v2: > * Converted to explicit checks for zero/non-zero > * fixed hns3 checks > * fixed some sample app rxmode.mtu value > * fixed some sample app max-pkt-len argument and updated doc for it > > v3: > * rebased > > v4: > * fix typos in commit logs > > v5: > * fix testpmd '--max-pkt-len=###' parameter for DTS jumbo frame test > > v6: > * uint32_t type used in 'eth_dev_get_overhead_len()' helper function > ---
Acked-by: Rosen Xu <rosen...@intel.com>
