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 <[email protected]>
Acked-by: Konstantin Ananyev <[email protected]>
A couple of questions below, but anyway:
Acked-by: Andrew Rybchenko <[email protected]>
---
Cc: Thomas Monjalon <[email protected]>
Cc: Andrew Rybchenko <[email protected]>
Cc: Konstantin Ananyev <[email protected]>
Cc: Matan Azrad <[email protected]>
Cc: Olivier Matz <[email protected]>
Cc: Jerin Jacob <[email protected]>
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.
