[dpdk-dev] Inconsistent behaviour of rte_eth_dev_set_mtu API between ixgbe and i40e

[dpdk-dev] Inconsistent behaviour of rte_eth_dev_set_mtu API between ixgbe and i40e

[Kavanagh, Mark B]

Hi,

In OvS-DPDK, we support single mbuf-segment jumbo frames.

To date, we've supported this by creating a mempool containing mbufs of size "~user-defined-MTU", and configured the NIC by crafting an rte_eth_conf structure with jumbo_frame mode enabled, and the device's max_rx_pkt_len set accordingly.
e.g.
<snip>
static int
dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int n_rxq, int n_txq)
{
                ...
                                struct rte_eth_conf conf = port_conf;

    if (dev->mtu > ETHER_MTU) {
                conf.rxmode.jumbo_frame = 1;
                conf.rxmode.max_rx_pkt_len = dev->max_packet_len;
    } else {
                conf.rxmode.jumbo_frame = 0;
                conf.rxmode.max_rx_pkt_len = 0;
}
</snip>


In an attempt to clean this up somewhat, I recently wrote a patch for OvS-DPDK that introduced the rte_eth_dev_set_mtu API, in place of the  rte_eth_conf manipulation. This worked fine for Fortville/i40e PMD, but when tested on Niantic/ixgbe, it was observed that the latter balks when a non-standard MTU is specified.

Examining the driver's source code, the source of the Niantic issue is traced to the following:

<snip>
static int
ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
{
...
    struct rte_eth_rxmode *rx_conf = &dev->data->dev_conf.rxmode;

...

    /* refuse mtu that requires the support of scattered packets when this
     * feature has not been enabled before.
     */
    if (!rx_conf->enable_scatter &&
                (frame_size + 2 * IXGBE_VLAN_TAG_SIZE >
                                dev->data->min_rx_buf_size - RTE_PKTMBUF_HEADROOM))
        return -EINVAL;
</snip>

In summary, there is an additional configuration requirement for scattered_rx mode on Niantic; this is problematic from an application perspective, as the rte_eth_dev_set_mtu API's behaviour is inconsistent across disparate NICs/PMDs. Should this be classified as a bug in DPDK?

Thanks in advance,
Mark