From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id EF4712B9E for ; Mon, 22 Feb 2016 15:51:27 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 22 Feb 2016 06:49:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,484,1449561600"; d="scan'208";a="908637838" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga001.fm.intel.com with ESMTP; 22 Feb 2016 06:49:38 -0800 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 22 Feb 2016 06:49:36 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 22 Feb 2016 06:49:36 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.249]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.196]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 22:49:34 +0800 From: "Xie, Huawei" To: Olivier MATZ , Panu Matilainen , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API Thread-Index: AQHRXqe5goBJK/BsE0CGoql1zgn6kQ== Date: Mon, 22 Feb 2016 14:49:33 +0000 Message-ID: References: <1450049754-33635-1-git-send-email-huawei.xie@intel.com> <1453827815-56384-1-git-send-email-huawei.xie@intel.com> <1453827815-56384-2-git-send-email-huawei.xie@intel.com> <56A8CCA3.7060302@redhat.com> <56B237AD.1040209@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.4.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dprovan@bivio.net" Subject: Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API 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: Mon, 22 Feb 2016 14:51:28 -0000 On 2/4/2016 1:24 AM, Olivier MATZ wrote:=0A= > Hi,=0A= >=0A= > On 01/27/2016 02:56 PM, Panu Matilainen wrote:=0A= >>=0A= >> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of= =0A= >> the library ABI and should not be listed in the version map.=0A= >>=0A= >> I assume its inline for performance reasons, but then you lose the=0A= >> benefits of dynamic linking such as ability to fix bugs and/or improve= =0A= >> itby just updating the library. Since the point of having a bulk API is= =0A= >> to improve performance by reducing the number of calls required, does it= =0A= >> really have to be inline? As in, have you actually measured the=0A= >> difference between inline and non-inline and decided its worth all the= =0A= >> downsides?=0A= >=0A= > Agree with Panu. It would be interesting to compare the performance=0A= > between inline and non inline to decide whether inlining it or not.=0A= =0A= Will update after i gathered more data. inline could show obvious=0A= performance difference in some cases.=0A= =0A= >=0A= > Also, it would be nice to have a simple test function in=0A= > app/test/test_mbuf.c. For instance, you could update=0A= > test_one_pktmbuf() to take a mbuf pointer as a parameter and remove=0A= > the mbuf allocation from the function. Then it could be called with=0A= > a mbuf allocated with rte_pktmbuf_alloc() (like before) and with=0A= > all the mbufs of rte_pktmbuf_alloc_bulk().=0A= >=0A= > Regards,=0A= > Olivier=0A= >=0A= =0A=