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>
---
Cc: Thomas Monjalon <tho...@monjalon.net>
Cc: Andrew Rybchenko <arybche...@solarflare.com>
Cc: Konstantin Ananyev <konstantin.anan...@intel.com>
Cc: Matan Azrad <ma...@nvidia.com>
Cc: Olivier Matz <olivier.m...@6wind.com>
Cc: Jerin Jacob <jer...@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.
