diff mbox

[dpdk-dev,v4,2/7] mempool: add mempool arg in xmem size and usage

Message ID 20170815060743.21076-3-santosh.shukla@caviumnetworks.com (mailing list archive)
State Superseded, archived
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Santosh Shukla Aug. 15, 2017, 6:07 a.m. UTC 
  xmem_size and xmem_usage need to know the status of mp->flag.
Following patch will make use of that.

Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
---
 drivers/net/xenvirt/rte_mempool_gntalloc.c |  5 +++--
 lib/librte_mempool/rte_mempool.c           | 10 ++++++----
 lib/librte_mempool/rte_mempool.h           |  8 ++++++--
 test/test/test_mempool.c                   |  4 ++--
 4 files changed, 17 insertions(+), 10 deletions(-)

Comments

Olivier Matz Sept. 4, 2017, 2:22 p.m. UTC | #1 
On Tue, Aug 15, 2017 at 11:37:38AM +0530, Santosh Shukla wrote:
> xmem_size and xmem_usage need to know the status of mp->flag.
> Following patch will make use of that.
> 
> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
> ---
>  drivers/net/xenvirt/rte_mempool_gntalloc.c |  5 +++--
>  lib/librte_mempool/rte_mempool.c           | 10 ++++++----
>  lib/librte_mempool/rte_mempool.h           |  8 ++++++--
>  test/test/test_mempool.c                   |  4 ++--
>  4 files changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c b/drivers/net/xenvirt/rte_mempool_gntalloc.c
> index 73e82f808..ee0bda459 100644
> --- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
> +++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
> @@ -114,7 +114,7 @@ _create_mempool(const char *name, unsigned elt_num, unsigned elt_size,
>  	pg_shift = rte_bsf32(pg_sz);
>  
>  	rte_mempool_calc_obj_size(elt_size, flags, &objsz);
> -	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift);
> +	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift, NULL);
>  	pg_num = sz >> pg_shift;
>  
>  	pa_arr = calloc(pg_num, sizeof(pa_arr[0]));

What is the meaning of passing NULL to rte_mempool_xmem_size()?
Does it mean that flags are ignored?

Wouldn't it be better to pass the mempool flags instead of the mempool
pointer?
Santosh Shukla Sept. 4, 2017, 2:33 p.m. UTC | #2 
On Monday 04 September 2017 07:52 PM, Olivier MATZ wrote:
> On Tue, Aug 15, 2017 at 11:37:38AM +0530, Santosh Shukla wrote:
>> xmem_size and xmem_usage need to know the status of mp->flag.
>> Following patch will make use of that.
>>
>> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
>> ---
>>  drivers/net/xenvirt/rte_mempool_gntalloc.c |  5 +++--
>>  lib/librte_mempool/rte_mempool.c           | 10 ++++++----
>>  lib/librte_mempool/rte_mempool.h           |  8 ++++++--
>>  test/test/test_mempool.c                   |  4 ++--
>>  4 files changed, 17 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c b/drivers/net/xenvirt/rte_mempool_gntalloc.c
>> index 73e82f808..ee0bda459 100644
>> --- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
>> +++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
>> @@ -114,7 +114,7 @@ _create_mempool(const char *name, unsigned elt_num, unsigned elt_size,
>>  	pg_shift = rte_bsf32(pg_sz);
>>  
>>  	rte_mempool_calc_obj_size(elt_size, flags, &objsz);
>> -	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift);
>> +	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift, NULL);
>>  	pg_num = sz >> pg_shift;
>>  
>>  	pa_arr = calloc(pg_num, sizeof(pa_arr[0]));
> What is the meaning of passing NULL to rte_mempool_xmem_size()?
> Does it mean that flags are ignored?

Yes that mean flags are ignored.

> Wouldn't it be better to pass the mempool flags instead of the mempool
> pointer?

Keeping mempool as param rather flag useful in case user want to do/refer more
thing in future for xmem_size/usage() api. Otherwise he has append one more param
to api and send out deprecation notice.. Btw, its const param so won;t hurt right?

However if you still want to restrict param to mp->flags then pl. suggest.

Thanks.
Olivier Matz Sept. 4, 2017, 2:46 p.m. UTC | #3 
On Mon, Sep 04, 2017 at 08:03:53PM +0530, santosh wrote:
> 
> 
> On Monday 04 September 2017 07:52 PM, Olivier MATZ wrote:
> > On Tue, Aug 15, 2017 at 11:37:38AM +0530, Santosh Shukla wrote:
> >> xmem_size and xmem_usage need to know the status of mp->flag.
> >> Following patch will make use of that.
> >>
> >> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
> >> ---
> >>  drivers/net/xenvirt/rte_mempool_gntalloc.c |  5 +++--
> >>  lib/librte_mempool/rte_mempool.c           | 10 ++++++----
> >>  lib/librte_mempool/rte_mempool.h           |  8 ++++++--
> >>  test/test/test_mempool.c                   |  4 ++--
> >>  4 files changed, 17 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c b/drivers/net/xenvirt/rte_mempool_gntalloc.c
> >> index 73e82f808..ee0bda459 100644
> >> --- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
> >> +++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
> >> @@ -114,7 +114,7 @@ _create_mempool(const char *name, unsigned elt_num, unsigned elt_size,
> >>  	pg_shift = rte_bsf32(pg_sz);
> >>  
> >>  	rte_mempool_calc_obj_size(elt_size, flags, &objsz);
> >> -	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift);
> >> +	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift, NULL);
> >>  	pg_num = sz >> pg_shift;
> >>  
> >>  	pa_arr = calloc(pg_num, sizeof(pa_arr[0]));
> > What is the meaning of passing NULL to rte_mempool_xmem_size()?
> > Does it mean that flags are ignored?
> 
> Yes that mean flags are ignored.

But the flags change the return value of rte_mempool_xmem_size(), right?
So, correct me if I'm wrong, but if we don't pass the proper flags, the
returned value won't be the one we expect.

> 
> > Wouldn't it be better to pass the mempool flags instead of the mempool
> > pointer?
> 
> Keeping mempool as param rather flag useful in case user want to do/refer more
> thing in future for xmem_size/usage() api. Otherwise he has append one more param
> to api and send out deprecation notice.. Btw, its const param so won;t hurt right?
> 
> However if you still want to restrict param to mp->flags then pl. suggest.
> 
> Thanks. 
> 
>
Santosh Shukla Sept. 4, 2017, 2:58 p.m. UTC | #4 
On Monday 04 September 2017 08:16 PM, Olivier MATZ wrote:
> On Mon, Sep 04, 2017 at 08:03:53PM +0530, santosh wrote:
>>
>> On Monday 04 September 2017 07:52 PM, Olivier MATZ wrote:
>>> On Tue, Aug 15, 2017 at 11:37:38AM +0530, Santosh Shukla wrote:
>>>> xmem_size and xmem_usage need to know the status of mp->flag.
>>>> Following patch will make use of that.
>>>>
>>>> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
>>>> ---
>>>>  drivers/net/xenvirt/rte_mempool_gntalloc.c |  5 +++--
>>>>  lib/librte_mempool/rte_mempool.c           | 10 ++++++----
>>>>  lib/librte_mempool/rte_mempool.h           |  8 ++++++--
>>>>  test/test/test_mempool.c                   |  4 ++--
>>>>  4 files changed, 17 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c b/drivers/net/xenvirt/rte_mempool_gntalloc.c
>>>> index 73e82f808..ee0bda459 100644
>>>> --- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
>>>> +++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
>>>> @@ -114,7 +114,7 @@ _create_mempool(const char *name, unsigned elt_num, unsigned elt_size,
>>>>  	pg_shift = rte_bsf32(pg_sz);
>>>>  
>>>>  	rte_mempool_calc_obj_size(elt_size, flags, &objsz);
>>>> -	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift);
>>>> +	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift, NULL);
>>>>  	pg_num = sz >> pg_shift;
>>>>  
>>>>  	pa_arr = calloc(pg_num, sizeof(pa_arr[0]));
>>> What is the meaning of passing NULL to rte_mempool_xmem_size()?
>>> Does it mean that flags are ignored?
>> Yes that mean flags are ignored.
> But the flags change the return value of rte_mempool_xmem_size(), right?

no, It won't change.

> So, correct me if I'm wrong, but if we don't pass the proper flags, the
> returned value won't be the one we expect.

passing flag value other than MEMPOOL_F_POOL_BLK_SZ_ALIGNED, wont impact return value.

>>> Wouldn't it be better to pass the mempool flags instead of the mempool
>>> pointer?
>> Keeping mempool as param rather flag useful in case user want to do/refer more
>> thing in future for xmem_size/usage() api. Otherwise he has append one more param
>> to api and send out deprecation notice.. Btw, its const param so won;t hurt right?
>>
>> However if you still want to restrict param to mp->flags then pl. suggest.
>>
>> Thanks. 
>>
>>
Olivier Matz Sept. 4, 2017, 3:23 p.m. UTC | #5 
On Mon, Sep 04, 2017 at 08:28:36PM +0530, santosh wrote:
> 
> On Monday 04 September 2017 08:16 PM, Olivier MATZ wrote:
> > On Mon, Sep 04, 2017 at 08:03:53PM +0530, santosh wrote:
> >>
> >> On Monday 04 September 2017 07:52 PM, Olivier MATZ wrote:
> >>> On Tue, Aug 15, 2017 at 11:37:38AM +0530, Santosh Shukla wrote:
> >>>> xmem_size and xmem_usage need to know the status of mp->flag.
> >>>> Following patch will make use of that.
> >>>>
> >>>> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
> >>>> ---
> >>>>  drivers/net/xenvirt/rte_mempool_gntalloc.c |  5 +++--
> >>>>  lib/librte_mempool/rte_mempool.c           | 10 ++++++----
> >>>>  lib/librte_mempool/rte_mempool.h           |  8 ++++++--
> >>>>  test/test/test_mempool.c                   |  4 ++--
> >>>>  4 files changed, 17 insertions(+), 10 deletions(-)
> >>>>
> >>>> diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c b/drivers/net/xenvirt/rte_mempool_gntalloc.c
> >>>> index 73e82f808..ee0bda459 100644
> >>>> --- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
> >>>> +++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
> >>>> @@ -114,7 +114,7 @@ _create_mempool(const char *name, unsigned elt_num, unsigned elt_size,
> >>>>  	pg_shift = rte_bsf32(pg_sz);
> >>>>  
> >>>>  	rte_mempool_calc_obj_size(elt_size, flags, &objsz);
> >>>> -	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift);
> >>>> +	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift, NULL);
> >>>>  	pg_num = sz >> pg_shift;
> >>>>  
> >>>>  	pa_arr = calloc(pg_num, sizeof(pa_arr[0]));
> >>> What is the meaning of passing NULL to rte_mempool_xmem_size()?
> >>> Does it mean that flags are ignored?
> >> Yes that mean flags are ignored.
> > But the flags change the return value of rte_mempool_xmem_size(), right?
> 
> no, It won't change.
> 
> > So, correct me if I'm wrong, but if we don't pass the proper flags, the
> > returned value won't be the one we expect.
> 
> passing flag value other than MEMPOOL_F_POOL_BLK_SZ_ALIGNED, wont impact return value.

That's the case today with your patches.

But if someone else wants to add another flag, this may change.
And you do not describe in the help that mp can be NULL, why it would
occur, and what does that mean.

> >>> Wouldn't it be better to pass the mempool flags instead of the mempool
> >>> pointer?
> >> Keeping mempool as param rather flag useful in case user want to do/refer more
> >> thing in future for xmem_size/usage() api. Otherwise he has append one more param
> >> to api and send out deprecation notice.. Btw, its const param so won;t hurt right?
> >>
> >> However if you still want to restrict param to mp->flags then pl. suggest.

Yes, it looks better to pass the flags instead of the mempool pointer.
Santosh Shukla Sept. 4, 2017, 3:52 p.m. UTC | #6 
On Monday 04 September 2017 08:53 PM, Olivier MATZ wrote:
> On Mon, Sep 04, 2017 at 08:28:36PM +0530, santosh wrote:
>> On Monday 04 September 2017 08:16 PM, Olivier MATZ wrote:
>>> On Mon, Sep 04, 2017 at 08:03:53PM +0530, santosh wrote:
>>>> On Monday 04 September 2017 07:52 PM, Olivier MATZ wrote:
>>>>> On Tue, Aug 15, 2017 at 11:37:38AM +0530, Santosh Shukla wrote:
>>>>>> xmem_size and xmem_usage need to know the status of mp->flag.
>>>>>> Following patch will make use of that.
>>>>>>
>>>>>> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
>>>>>> ---
>>>>>>  drivers/net/xenvirt/rte_mempool_gntalloc.c |  5 +++--
>>>>>>  lib/librte_mempool/rte_mempool.c           | 10 ++++++----
>>>>>>  lib/librte_mempool/rte_mempool.h           |  8 ++++++--
>>>>>>  test/test/test_mempool.c                   |  4 ++--
>>>>>>  4 files changed, 17 insertions(+), 10 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c b/drivers/net/xenvirt/rte_mempool_gntalloc.c
>>>>>> index 73e82f808..ee0bda459 100644
>>>>>> --- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
>>>>>> +++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
>>>>>> @@ -114,7 +114,7 @@ _create_mempool(const char *name, unsigned elt_num, unsigned elt_size,
>>>>>>  	pg_shift = rte_bsf32(pg_sz);
>>>>>>  
>>>>>>  	rte_mempool_calc_obj_size(elt_size, flags, &objsz);
>>>>>> -	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift);
>>>>>> +	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift, NULL);
>>>>>>  	pg_num = sz >> pg_shift;
>>>>>>  
>>>>>>  	pa_arr = calloc(pg_num, sizeof(pa_arr[0]));
>>>>> What is the meaning of passing NULL to rte_mempool_xmem_size()?
>>>>> Does it mean that flags are ignored?
>>>> Yes that mean flags are ignored.
>>> But the flags change the return value of rte_mempool_xmem_size(), right?
>> no, It won't change.
>>
>>> So, correct me if I'm wrong, but if we don't pass the proper flags, the
>>> returned value won't be the one we expect.
>> passing flag value other than MEMPOOL_F_POOL_BLK_SZ_ALIGNED, wont impact return value.
> That's the case today with your patches.
>
> But if someone else wants to add another flag, this may change.

trying to understand your point of view here:
- We have 64B wide flag and if new flag introduced, considering new flag
sets bit in 2^x order then 'if' condition in xmem_size() will fail and elt_num won;t increment
thus won;t impact return type, right?

> And you do not describe in the help that mp can be NULL, why it would
> occur, and what does that mean.

agree, It meant flag ignored in below particular case where upper xen driver API
ie.. __create_mempool() is calling _xmem_size() before pool create (valid case though). 


>>>>> Wouldn't it be better to pass the mempool flags instead of the mempool
>>>>> pointer?
>>>> Keeping mempool as param rather flag useful in case user want to do/refer more
>>>> thing in future for xmem_size/usage() api. Otherwise he has append one more param
>>>> to api and send out deprecation notice.. Btw, its const param so won;t hurt right?
>>>>
>>>> However if you still want to restrict param to mp->flags then pl. suggest.
> Yes, it looks better to pass the flags instead of the mempool pointer.

ok, queued for v5. Thanks.
diff mbox

Patch

diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c b/drivers/net/xenvirt/rte_mempool_gntalloc.c
index 73e82f808..ee0bda459 100644
--- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
+++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
@@ -114,7 +114,7 @@  _create_mempool(const char *name, unsigned elt_num, unsigned elt_size,
 	pg_shift = rte_bsf32(pg_sz);
 
 	rte_mempool_calc_obj_size(elt_size, flags, &objsz);
-	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift);
+	sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift, NULL);
 	pg_num = sz >> pg_shift;
 
 	pa_arr = calloc(pg_num, sizeof(pa_arr[0]));
@@ -162,7 +162,8 @@  _create_mempool(const char *name, unsigned elt_num, unsigned elt_size,
 	 * Check that allocated size is big enough to hold elt_num
 	 * objects and a calcualte how many bytes are actually required.
 	 */
-	usz = rte_mempool_xmem_usage(va, elt_num, objsz.total_size, pa_arr, pg_num, pg_shift);
+	usz = rte_mempool_xmem_usage(va, elt_num, objsz.total_size, pa_arr,
+				     pg_num, pg_shift, NULL);
 	if (usz < 0) {
 		mp = NULL;
 		i = pg_num;
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 237665c65..f95c01c00 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -238,7 +238,8 @@  rte_mempool_calc_obj_size(uint32_t elt_size, uint32_t flags,
  * Calculate maximum amount of memory required to store given number of objects.
  */
 size_t
-rte_mempool_xmem_size(uint32_t elt_num, size_t total_elt_sz, uint32_t pg_shift)
+rte_mempool_xmem_size(uint32_t elt_num, size_t total_elt_sz, uint32_t pg_shift,
+		      __rte_unused const struct rte_mempool *mp)
 {
 	size_t obj_per_page, pg_num, pg_sz;
 
@@ -264,13 +265,14 @@  rte_mempool_xmem_size(uint32_t elt_num, size_t total_elt_sz, uint32_t pg_shift)
 ssize_t
 rte_mempool_xmem_usage(__rte_unused void *vaddr, uint32_t elt_num,
 	size_t total_elt_sz, const phys_addr_t paddr[], uint32_t pg_num,
-	uint32_t pg_shift)
+	uint32_t pg_shift, __rte_unused const struct rte_mempool *mp)
 {
 	uint32_t elt_cnt = 0;
 	phys_addr_t start, end;
 	uint32_t paddr_idx;
 	size_t pg_sz = (size_t)1 << pg_shift;
 
+
 	/* if paddr is NULL, assume contiguous memory */
 	if (paddr == NULL) {
 		start = 0;
@@ -543,7 +545,7 @@  rte_mempool_populate_default(struct rte_mempool *mp)
 
 	total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;
 	for (mz_id = 0, n = mp->size; n > 0; mz_id++, n -= ret) {
-		size = rte_mempool_xmem_size(n, total_elt_sz, pg_shift);
+		size = rte_mempool_xmem_size(n, total_elt_sz, pg_shift, mp);
 
 		ret = snprintf(mz_name, sizeof(mz_name),
 			RTE_MEMPOOL_MZ_FORMAT "_%d", mp->name, mz_id);
@@ -600,7 +602,7 @@  get_anon_size(const struct rte_mempool *mp)
 	pg_sz = getpagesize();
 	pg_shift = rte_bsf32(pg_sz);
 	total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;
-	size = rte_mempool_xmem_size(mp->size, total_elt_sz, pg_shift);
+	size = rte_mempool_xmem_size(mp->size, total_elt_sz, pg_shift, mp);
 
 	return size;
 }
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index bd7be2319..74e91d34f 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -1476,11 +1476,13 @@  uint32_t rte_mempool_calc_obj_size(uint32_t elt_size, uint32_t flags,
  *   by rte_mempool_calc_obj_size().
  * @param pg_shift
  *   LOG2 of the physical pages size. If set to 0, ignore page boundaries.
+ * @param mp
+ *  A pointer to the mempool structure.
  * @return
  *   Required memory size aligned at page boundary.
  */
 size_t rte_mempool_xmem_size(uint32_t elt_num, size_t total_elt_sz,
-	uint32_t pg_shift);
+	uint32_t pg_shift, const struct rte_mempool *mp);
 
 /**
  * Get the size of memory required to store mempool elements.
@@ -1503,6 +1505,8 @@  size_t rte_mempool_xmem_size(uint32_t elt_num, size_t total_elt_sz,
  *   Number of elements in the paddr array.
  * @param pg_shift
  *   LOG2 of the physical pages size.
+ * @param mp
+ *  A pointer to the mempool structure.
  * @return
  *   On success, the number of bytes needed to store given number of
  *   objects, aligned to the given page size. If the provided memory
@@ -1511,7 +1515,7 @@  size_t rte_mempool_xmem_size(uint32_t elt_num, size_t total_elt_sz,
  */
 ssize_t rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num,
 	size_t total_elt_sz, const phys_addr_t paddr[], uint32_t pg_num,
-	uint32_t pg_shift);
+	uint32_t pg_shift, const struct rte_mempool *mp);
 
 /**
  * Walk list of all memory pools
diff --git a/test/test/test_mempool.c b/test/test/test_mempool.c
index 47dc3ac5f..1eb81081c 100644
--- a/test/test/test_mempool.c
+++ b/test/test/test_mempool.c
@@ -485,10 +485,10 @@  test_mempool_xmem_misc(void)
 
 	elt_num = MAX_KEEP;
 	total_size = rte_mempool_calc_obj_size(MEMPOOL_ELT_SIZE, 0, NULL);
-	sz = rte_mempool_xmem_size(elt_num, total_size, MEMPOOL_PG_SHIFT_MAX);
+	sz = rte_mempool_xmem_size(elt_num, total_size, MEMPOOL_PG_SHIFT_MAX, NULL);
 
 	usz = rte_mempool_xmem_usage(NULL, elt_num, total_size, 0, 1,
-		MEMPOOL_PG_SHIFT_MAX);
+		MEMPOOL_PG_SHIFT_MAX, NULL);
 
 	if (sz != (size_t)usz)  {
 		printf("failure @ %s: rte_mempool_xmem_usage(%u, %u) "