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.yi...@intel.com>
> >> Acked-by: Konstantin Ananyev <konstantin.anan...@intel.com>
> >
> > A couple of questions below, but anyway:
> >
> > Acked-by: Andrew Rybchenko <andrew.rybche...@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 <tho...@monjalon.net>
Applied, thanks
