[ovs-dev] [PATCH v3 1/5] netdev-dpdk: fix mempool management with vhu client.

[Róbert Mulik]

Hi Antonio,

Last week I run into this mempool issue during the development of a new feature. I have made a bugfix, but then we saw yours too, so I tested if it solves my problem. It did, but I realized another problem with it. The mempool name generation is partly based on the MTU size, which is handled in 1024 bytes long ranges. For example MTU 1000 and 1500 are in the same range, 2000 and 2500 are in a different range. So I tested this patch and got the following.

# ovs-vsctl list interface dpdk0 |grep mtu
mtu                 : 2500
mtu_request         : 2500
# ovs-vsctl set interface dpdk0 mtu_request=2000
# ovs-vsctl list interface dpdk0 |grep mtu
mtu                 : 2500
mtu_request         : 2000 
# ovs-vsctl set interface dpdk0 mtu_request=1500
# ovs-vsctl list interface dpdk0 |grep mtu
mtu                 : 1500
mtu_request         : 1500
# ovs-vsctl set interface dpdk0 mtu_request=1000
# ovs-vsctl list interface dpdk0 |grep mtu
mtu                 : 1500
mtu_request         : 1000
# ovs-vsctl set interface dpdk0 mtu_request=2000
# ovs-vsctl list interface dpdk0 |grep mtu
mtu                 : 2000
mtu_request         : 2000
# ovs-vsctl set interface dpdk0 mtu_request=1000
# ovs-vsctl list interface dpdk0 |grep mtu
mtu                 : 1000
mtu_request         : 1000
# ovs-vsctl set interface dpdk0 mtu_request=1500
# ovs-vsctl list interface dpdk0 |grep mtu
mtu                 : 1000
mtu_request         : 1500
# service openvswitch-switch restart
# ovs-vsctl list interface dpdk0 |grep mtu
mtu                 : 1500
mtu_request         : 1500


This was my setup:
    Bridge br-prv
        Port bond-prv
            Interface "dpdk0"
                type: dpdk
                options: {dpdk-devargs="0000:05:00.0", n_rxq_desc="1024", n_txq_desc="1024"}
    ovs_version: "2.8.90"

And I used DPDK v17.08.


So, as it can be see from the example above, with the patch applied when a new mtu_request is in the same range as the previously set MTU, then it has no effect until service restart. The mtu_request has immediate effect when it is in different range as the previously set MTU. Or did I miss something during the testing?

My patch what I used last week does the following. During reconfiguration the mempool is always deleted before a new one is created. It solved the problem without side effects, but it is not optimized (always recreates the mempool when this function is called).
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index c60f46f..de38f95 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -621,6 +621,7 @@ netdev_dpdk_mempool_configure(struct netdev_dpdk *dev)
     uint32_t buf_size = dpdk_buf_size(dev->requested_mtu);
     struct dpdk_mp *mp;

+    dpdk_mp_put(dev->dpdk_mp);
     mp = dpdk_mp_get(dev, FRAME_LEN_TO_MTU(buf_size));
     if (!mp) {
         VLOG_ERR("Failed to create memory pool for netdev "
@@ -629,7 +630,6 @@ netdev_dpdk_mempool_configure(struct netdev_dpdk *dev)
                  rte_strerror(rte_errno));
         return rte_errno;
     } else {
-        dpdk_mp_put(dev->dpdk_mp);
         dev->dpdk_mp = mp;
         dev->mtu = dev->requested_mtu;
         dev->socket_id = dev->requested_socket_id;


What do you think about this solution?

Regards,
Robert