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

[Thomas Monjalon <thomas@monjalon.net>]

26/11/2020 13:34, Ferruh Yigit:
> 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>
> > 
> >> 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.

In general, I am in favor of
	- avoiding redundancy in API
	- have more specific functions in API
So yes, no need to keep a field for rte_eth_dev_configure()
if the same can be done with rte_eth_dev_set_mtu().

> > 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.

If we can manage without this (strange) offload flag,
I am for dropping it.

> I don't know if should it be part of this deprecation notice, or a separate one.

Let's keep this first notice in 20.11 to show the direction.

> It is related, but logically not exactly part of this deprecation notice.

We can update or add more notices during next year.

Acked-by: Thomas Monjalon <thomas@monjalon.net>

Applied, thanks