From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 120965953 for ; Tue, 11 Aug 2015 15:10:24 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 11 Aug 2015 06:10:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,652,1432623600"; d="scan'208";a="746378341" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga001.jf.intel.com with ESMTP; 11 Aug 2015 06:10:12 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.149]) by IRSMSX151.ger.corp.intel.com ([169.254.4.151]) with mapi id 14.03.0224.002; Tue, 11 Aug 2015 14:10:11 +0100 From: "Mcnamara, John" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] DPDK2.1 (rc3 & rc4) major performance drop. Thread-Index: AdDUIJILli1pwEzxS6eR7qv8/17P2AAFOMsQ Date: Tue, 11 Aug 2015 13:10:10 +0000 Message-ID: References: <1AFA2937E172CD4DB2FD9318443C060ED9BDC6@IRSMSX103.ger.corp.intel.com> In-Reply-To: <1AFA2937E172CD4DB2FD9318443C060ED9BDC6@IRSMSX103.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] DPDK2.1 (rc3 & rc4) major performance drop. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 13:10:25 -0000 > -----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. >=20 > Hello, >=20 > 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=20 > 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 Date: Wed Apr 22 11:57:18 2015 +0200 mbuf: fix data room size calculation in pool init Previously passing opaque_arg =3D=3D NULL initialized mbuf_data_room_size = =3D 2048 + RTE_PKTMBUF_HEADROOM. Now it is set as follows: + /* if no structure is provided, assume no mbuf private area */ + user_mbp_priv =3D opaque_arg; + if (user_mbp_priv =3D=3D NULL) { + default_mbp_priv.mbuf_priv_size =3D 0; + if (mp->elt_size > sizeof(struct rte_mbuf)) + roomsz =3D mp->elt_size - sizeof(struct rte_mbuf); + else + roomsz =3D 0; + default_mbp_priv.mbuf_data_room_size =3D roomsz; + user_mbp_priv =3D &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. --=20