Hi, > -----Original Message----- > From: Yigit, Ferruh <[email protected]> > Sent: Tuesday, October 12, 2021 7:54 > To: Jerin Jacob <[email protected]>; Li, Xiaoyun <[email protected]>; > Chas Williams <[email protected]>; Min Hu (Connor) <[email protected]>; > Hemant Agrawal <[email protected]>; Sachin Saxena > <[email protected]>; Zhang, Qi Z <[email protected]>; Wang, > Xiao W <[email protected]>; Matan Azrad <[email protected]>; > Viacheslav Ovsiienko <[email protected]>; Harman Kalra > <[email protected]>; Maciej Czekaj <[email protected]>; Ray Kinsella > <[email protected]>; Iremonger, Bernard <[email protected]>; > Ananyev, Konstantin <[email protected]>; Kiran Kumar K > <[email protected]>; Nithin Dabilpuram > <[email protected]>; Hunt, David <[email protected]>; > Mcnamara, John <[email protected]>; Richardson, Bruce > <[email protected]>; Igor Russkikh <[email protected]>; > Steven Webster <[email protected]>; Peters, Matt > <[email protected]>; Somalapuram Amaranath > <[email protected]>; Rasesh Mody <[email protected]>; Shahed > Shaikh <[email protected]>; Ajit Khaparde > <[email protected]>; Somnath Kotur > <[email protected]>; Sunil Kumar Kori <[email protected]>; > Satha Rao <[email protected]>; Rahul Lakkireddy > <[email protected]>; Wang, Haiyue <[email protected]>; > Marcin Wojtas <[email protected]>; Michal Krawczyk <[email protected]>; > Shai Brandes <[email protected]>; Evgeny Schemeilin > <[email protected]>; Igor Chauskin <[email protected]>; Gagandeep > Singh <[email protected]>; Daley, John <[email protected]>; Hyong Youb > Kim <[email protected]>; Ziyang Xuan <[email protected]>; > Xiaoyun Wang <[email protected]>; Guoyang Zhou > <[email protected]>; Yisen Zhuang <[email protected]>; > Lijun Ou <[email protected]>; Xing, Beilei <[email protected]>; Wu, > Jingjing <[email protected]>; Yang, Qiming <[email protected]>; > Andrew Boyer <[email protected]>; Xu, Rosen <[email protected]>; > Shijith Thotton <[email protected]>; Srisivasubramanian Srinivasan > <[email protected]>; Zyta Szpak <[email protected]>; Liron Himi > <[email protected]>; Heinrich Kuhn <[email protected]>; > Devendra Singh Rawat <[email protected]>; Andrew Rybchenko > <[email protected]>; Wiles, Keith <[email protected]>; > Jiawen Wu <[email protected]>; Jian Wang > <[email protected]>; Maxime Coquelin > <[email protected]>; Xia, Chenbo <[email protected]>; > Chautru, Nicolas <[email protected]>; Van Haaren, Harry > <[email protected]>; Dumitrescu, Cristian > <[email protected]>; Nicolau, Radu <[email protected]>; > Akhil Goyal <[email protected]>; Kantecki, Tomasz > <[email protected]>; Doherty, Declan <[email protected]>; > Pavan Nikhilesh <[email protected]>; Rybalchenko, Kirill > <[email protected]>; Singh, Jasvinder > <[email protected]>; Thomas Monjalon <[email protected]> > Cc: Yigit, Ferruh <[email protected]>; [email protected]; Huisong Li > <[email protected]> > 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 <[email protected]> > Acked-by: Ajit Khaparde <[email protected]> > Acked-by: Somnath Kotur <[email protected]> > Acked-by: Huisong Li <[email protected]> > --- > Cc: Min Hu (Connor) <[email protected]> > > 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 <[email protected]>
