Re: [dpdk-dev] [RFC v2] doc: announce max Rx packet len field deprecation

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 11/26/2020 11:28 AM, Andrew Rybchenko wrote:
> On 11/24/20 8:36 PM, Ferruh Yigit wrote:
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> 
> A couple of questions below, but anyway:
> 
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> 
>> ---
>> Cc: Thomas Monjalon <thomas@monjalon.net>
>> Cc: Andrew Rybchenko <arybchenko@solarflare.com>
>> Cc: Konstantin Ananyev <konstantin.ananyev@intel.com>
>> Cc: Matan Azrad <matan@nvidia.com>
>> Cc: Olivier Matz <olivier.matz@6wind.com>
>> Cc: Jerin Jacob <jerinj@marvell.com>
>>
>> v2:
>> * ``uint32_t mtu`` moved to ``struct rte_eth_conf``
>> * The "Driver is responsible from updating ``(struct
>>    rte_eth_dev)->data->mtu``" updated because ethdev layer also can do
>>    this. The intention there was both APIs should update the variable.
>>
>> Another open question is from Andrew, if we can remove the ``uint32_t
>> max_rx_pkt_len`` completely from the ``rte_eth_dev_configure()``.
>> This may force applications to have one more additional
>> ``rte_eth_dev_set_mtu()`` call for device initialization, but if
>> applications are OK with the default values most of times, agree that
>> removing is easier solution, please comment.
> 
> Still valid 

Yep, waiting for more comments for it.

> plus I'd remove JUMBO_FRAME offload since
> it is redundant. We have max_mtu and max_rx_pktlen in dev_info.
> 

Right, I missed that 'max_mtu' & 'max_rx_pktlen' can be used to detect jumbo 
frame capability. +1 to remove JUMBO_FRAME offload.

I don't know if should it be part of this deprecation notice, or a separate one.
It is related, but logically not exactly part of this deprecation notice.