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 <fengcheng...@huawei.com>
Reviewed-by: Dongdong Liu <liudongdo...@huawei.com>
Acked-by: Morten Brørup <m...@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.bura...@intel.com>
--
Thanks,
Anatoly
