[dpdk-dev] [PATCH v7 1/6] ethdev: fix max Rx packet length

Ferruh Yigit ferruh.yigit at intel.com
Fri Nov 5 15:39:13 CET 2021


On 11/5/2021 2:19 PM, Xueming(Steven) Li wrote:
> On Mon, 2021-10-18 at 18:31 +0100, Ferruh Yigit wrote:
>> On 10/18/2021 2:48 PM, 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 <ferruh.yigit at intel.com>
>>> Acked-by: Ajit Khaparde <ajit.khaparde at broadcom.com>
>>> Acked-by: Somnath Kotur <somnath.kotur at broadcom.com>
>>> Acked-by: Huisong Li <lihuisong at huawei.com>
>>> Acked-by: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
>>> Acked-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
>>> Acked-by: Rosen Xu <rosen.xu at intel.com>
>>> Acked-by: Hyong Youb Kim <hyonkim at cisco.com>
>>
>> Series applied to dpdk-next-net/main, thanks.
>>
> 
> Hi Ferruh,
> 
> I noticed that no cc stable in this this "fix" patch, do you expect it
> to be part of LTS?
> 

Hi Xueming,

I didn't put it intentionally, patch changes how frame size / MTU configured,
not exactly a fix, I think not suitable for backport.



More information about the dev mailing list