[PATCH v16 3/6] memarea: support alloc and free API

[Burakov, Anatoly]

On 7/10/2023 7:49 AM, Chengwen Feng wrote:
> This patch supports rte_memarea_alloc() and rte_memarea_free() API.
> 
> Signed-off-by: Chengwen Feng <fengchengwen at huawei.com>
> Reviewed-by: Dongdong Liu <liudongdong3 at huawei.com>
> Acked-by: Morten Brørup <mb at smartsharesystems.com>
> ---

Hi,

Kind of a general question: the allocation code doesn't seem to take 
into account that since we're potentially reusing memory between 
alloc/free calls, the memory may/will be dirty, and any subsequent 
alloc/free call may require memset(0) from the user. This is the kind of 
thing C programmers are familiar with already, so it's not a big deal, 
I'm just wondering what your intention was with this API: do you think 
it should be user's responsibility to erase memory before using it, or 
can we make it part of API guarantees? If it's the latter, then it would 
be good to have some sort of note in documentation explicitly mentioning 
that the memory returned is not guaranteed to be zeroed out?

> +static inline void
> +memarea_unlock(struct rte_memarea *ma)
> +{
> +	if (ma->init.mt_safe)
> +		rte_spinlock_unlock(&ma->lock);
> +}
> +
> +/**
> + * Check cookie or panic.
> + *
> + * @param status
> + *   - 0: object is supposed to be available.
> + *   - 1: object is supposed to be allocated.
> + *   - 2: just check that cookie is valid (available or allocated).
> + */

Same as with previous patches: I feel like it would've been better if 
status were #define'd somewhere, so that we don't use explicit numbers 
in code.

Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>

-- 
Thanks,
Anatoly