From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id AC8701B7F0
 for <dev@dpdk.org>; Wed, 31 Jan 2018 17:45:31 +0100 (CET)
Received: from lfbn-lil-1-110-231.w90-45.abo.wanadoo.fr ([90.45.197.231]
 helo=droids-corp.org)
 by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.89) (envelope-from <olivier.matz@6wind.com>)
 id 1egvW0-0006Ve-TH; Wed, 31 Jan 2018 17:45:42 +0100
Received: by droids-corp.org (sSMTP sendmail emulation);
 Wed, 31 Jan 2018 17:45:29 +0100
Date: Wed, 31 Jan 2018 17:45:29 +0100
From: Olivier Matz <olivier.matz@6wind.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: dev@dpdk.org
Message-ID: <20180131164529.laku7jdh3hgriall@platinum>
References: <1511539591-20966-1-git-send-email-arybchenko@solarflare.com>
 <1516713372-10572-1-git-send-email-arybchenko@solarflare.com>
 <1516713372-10572-5-git-send-email-arybchenko@solarflare.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1516713372-10572-5-git-send-email-arybchenko@solarflare.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [dpdk-dev] [RFC v2 04/17] mempool: add op to populate objects
 using provided memory
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://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: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jan 2018 16:45:31 -0000

On Tue, Jan 23, 2018 at 01:15:59PM +0000, Andrew Rybchenko wrote:
> The callback allows to customize how objects are stored in the
> memory chunk. Default implementation of the callback which simply
> puts objects one by one is available.
> 
> Suggested-by: Olivier Matz <olivier.matz@6wind.com>
> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>

...

>  
> +int
> +rte_mempool_populate_one_by_one(struct rte_mempool *mp, unsigned int max_objs,
> +		void *vaddr, rte_iova_t iova, size_t len,
> +		rte_mempool_populate_obj_cb_t *obj_cb)

We shall find a better name for this function.
Unfortunatly rte_mempool_populate_default() already exists...

I'm also wondering if having a file rte_mempool_ops_default.c
with all the default behaviors would make sense?

...

> @@ -466,16 +487,13 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
>  	else
>  		off = RTE_PTR_ALIGN_CEIL(vaddr, RTE_CACHE_LINE_SIZE) - vaddr;
>  
> -	while (off + total_elt_sz <= len && mp->populated_size < mp->size) {
> -		off += mp->header_size;
> -		if (iova == RTE_BAD_IOVA)
> -			mempool_add_elem(mp, (char *)vaddr + off,
> -				RTE_BAD_IOVA);
> -		else
> -			mempool_add_elem(mp, (char *)vaddr + off, iova + off);
> -		off += mp->elt_size + mp->trailer_size;
> -		i++;
> -	}
> +	if (off > len)
> +		return -EINVAL;
> +
> +	i = rte_mempool_ops_populate(mp, mp->size - mp->populated_size,
> +		(char *)vaddr + off,
> +		(iova == RTE_BAD_IOVA) ? RTE_BAD_IOVA : (iova + off),
> +		len - off, mempool_add_elem);

My initial idea was to provide populate_iova(), populate_virt(), ...
as mempool ops. I don't see any strong requirement for doing it now, but
on the other hand it would break the API to do it later. What's
your opinion?

Also, I see that mempool_add_elem() is passed as a callback to
rte_mempool_ops_populate(). Instead, would it make sense to
export mempool_add_elem() and let the implementation of populate()
ops to call it?