Re: [dpdk-dev] DPDK2.1 (rc3 & rc4) major performance drop.

["Mcnamara, John" <john.mcnamara@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Weglicki, MichalX
> Sent: Tuesday, August 11, 2015 11:40 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] DPDK2.1 (rc3 & rc4) major performance drop.
> 
> Hello,
> 
> Currently I'm integrating OVS head with DPDK 2.1. Based on my tests
> performance in all scenarios (confirmed on Phy2Phy and Vhostuser) has
> dropped about 10%. Please find example results below:

Also:

> Michal:
> It seems I can fix it on OVS side by passing old hardcoded 
> size(2048 + RTE_PKTMBUF_HEADROOM) as argument instead of NULL.

Hi,

In commit 1d493a49490fa the bahaviour of rte_pktmbuf_pool_init() changed:

    commit 1d493a49490fa90e09689d49280cff0d51d0193e
    Author: Olivier Matz <olivier.matz@6wind.com>
    Date:   Wed Apr 22 11:57:18 2015 +0200

        mbuf: fix data room size calculation in pool init

Previously passing opaque_arg == NULL initialized mbuf_data_room_size = 2048 + RTE_PKTMBUF_HEADROOM.

Now it is set as follows:

+       /* if no structure is provided, assume no mbuf private area */
+       user_mbp_priv = opaque_arg;
+       if (user_mbp_priv == NULL) {
+               default_mbp_priv.mbuf_priv_size = 0;
+               if (mp->elt_size > sizeof(struct rte_mbuf))
+                       roomsz = mp->elt_size - sizeof(struct rte_mbuf);
+               else
+                       roomsz = 0;
+               default_mbp_priv.mbuf_data_room_size = roomsz;
+               user_mbp_priv = &default_mbp_priv;
+       }

A workaround, for OVS, would be to pass the new opaque_arg struct with the required default set. However, perhaps this should be fixed in DPDK.

The updated doc in the same patch says:

+DPDK 2.0 to DPDK 2.1
+--------------------
+
+*   The second argument of rte_pktmbuf_pool_init(mempool, opaque) is now a
+    pointer to a struct rte_pktmbuf_pool_private instead of a uint16_t
+    casted into a pointer. Backward compatibility is preserved when the
+    argument was NULL which is the majority of use cases, but not if the
+    opaque pointer was not NULL, as it is not technically feasible. In
+    this case, the application has to be modified to properly fill a
+    rte_pktmbuf_pool_private structure and pass it to
+    rte_pktmbuf_pool_init().
+

I think the OVS issue shows that backward compatibility isn't preserved (in the strictest sense).

Should this be fixed? Opinions?

John.
--