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
