From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier MATZ <olivier.matz@6wind.com>
Subject: Re: [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk
 API
Date: Fri, 26 Feb 2016 10:18:15 +0100
Message-ID: <56D01857.1060808@6wind.com>
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>
 <C37D651A908B024F974696C65296B57B4C5EE961@SHSMSX101.ccr.corp.intel.com>
 <C37D651A908B024F974696C65296B57B4C5F0655@SHSMSX101.ccr.corp.intel.com>
 <56D012EF.9090507@6wind.com>
 <C37D651A908B024F974696C65296B57B4C61002C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "dprovan@bivio.net" <dprovan@bivio.net>
To: "Xie, Huawei" <huawei.xie@intel.com>,
 Panu Matilainen <pmatilai@redhat.com>, "dev@dpdk.org" <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 920B02C6E
 for <dev@dpdk.org>; Fri, 26 Feb 2016 10:18:23 +0100 (CET)
In-Reply-To: <C37D651A908B024F974696C65296B57B4C61002C@SHSMSX101.ccr.corp.intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Huawei,

On 02/26/2016 10:07 AM, Xie, Huawei wrote:
> On 2/26/2016 4:56 PM, Olivier MATZ wrote:
>> test_one_pktmbuf(struct rte_mbuf *m)
>> {
>> 	/* same as before without the allocation/free */
>> }
>>
>> test_pkt_mbuf(void)
>> {
>> 	m = rte_pktmbuf_alloc(pool);
>> 	test_one_pktmbuf(m);
>> 	rte_pktmbuf_free(m);
>>
>> 	ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
>> 	for (i = 0; i < BULK_CNT; i++) {
>> 		m = mtab[i];
>> 		test_one_pktmbuf(m);
>> 		rte_pktmbuf_free(m);
>> 	}
>> }
> 
> This is to test the functionality.
> Let us also have the case like the following?
>         cycles_start = rte_get_timer_cycles();
>         while(rounds--) {
> 
> 		ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
> 		for (i = 0; i < BULK_CNT; i++) {
> 			m = mtab[i];
> 			/* some work if needed */
> 			rte_pktmbuf_free(m);
> 		}
>         }
> 	cycles_end = rte_get_timer_cycles();
> 
> to compare with
>        cycles_start = rte_get_timer_cycles();
>        while(rounds--) {
>                 for (i = 0; i < BULK_CNT; i++)
>                     mtab[i] = rte_pktmbuf_alloc(...);
> 
> 		ret = rte_pktmbuf_alloc_bulk(pool, mtab, BULK_CNT)
> 		for (i = 0; i < BULK_CNT; i++) {
> 			m = mtab[i];
> 			/* some work if needed */
> 			rte_pktmbuf_free(m);
> 		}
>         }
> 	cycles_end = rte_get_timer_cycles();

In my opinion, it's already quite obvious that the bulk allocation
will be faster than the non-bulk (and we already have some mempool
benchmarks showing it). So I would say that functional testing is
enough.

On the other hand, it would be good to see if some examples
applications could be updated to take advantage of the new API (as
you did for the librte_vhost).

What do you think?