On 2/27/2019 9:45 PM, Ian Stokes wrote:
> From: Stephen Hemminger <step...@networkplumber.org>
>
> This addresses the usability issue raised by OVS at DPDK Userspace
> summit. It adds general min/max mtu into device info. For compatiablity,
> and to save space, it fits in a hole in existing structure.
>
> The initial version sets max mtu to normal Ethernet, it is up to
> PMD to set larger value if it supports Jumbo frames.
>
> Also remove the deprecation notice introduced in 18.11 regarding this
> change and bump ethdev ABI version.
>
> Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
> Signed-off-by: Ian Stokes <ian.sto...@intel.com>
> Acked-by: Andrew Rybchenko <arybche...@solarflare.com>
> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct
> rte_eth_dev_info *dev_info)
> dev_info->rx_desc_lim = lim;
> dev_info->tx_desc_lim = lim;
> dev_info->device = dev->device;
> + dev_info->min_mtu = ETHER_MIN_MTU;
> + dev_info->max_mtu = UINT16_MAX;
Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
doxygen documentation, the default values that API sets?
>
> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
> @@ -2587,12 +2589,17 @@ int
> rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
> {
> int ret;
> + struct rte_eth_dev_info dev_info;
> struct rte_eth_dev *dev;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> dev = &rte_eth_devices[port_id];
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
>
> + rte_eth_dev_info_get(port_id, &dev_info);
If we rely on 'rte_eth_dev_info_get()', we should add a check if "dev_infos_get"
is supported before calling it, like [1]. Unfortunately 'rte_eth_dev_info_get()'
return type is 'void', so we can't know if the struct has valid values or not
otherwise.
Or perhaps if port doesn't support "dev_infos_get", we can skip the mtu check
instead of returning error.
[1]
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get, -ENOTSUP);
> + if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
> + return -EINVAL;
> +
Should we document this behavior change in the function comment in header file?
Update when -EINVAL returned, etc..
