[dpdk-dev] DPDK2.1 (rc3 & rc4) major performance drop.
Mcnamara, John
john.mcnamara at intel.com
Tue Aug 11 15:10:10 CEST 2015
> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Weglicki, MichalX
> Sent: Tuesday, August 11, 2015 11:40 AM
> To: dev at 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 at 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.
--
More information about the dev
mailing list