From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 65B4D4242B; Fri, 20 Jan 2023 09:21:01 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1C5A240150; Fri, 20 Jan 2023 09:21:01 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 6F59A400D5 for ; Fri, 20 Jan 2023 09:20:59 +0100 (CET) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Nysq744bczJrr7; Fri, 20 Jan 2023 16:19:31 +0800 (CST) Received: from [10.67.100.224] (10.67.100.224) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 20 Jan 2023 16:20:56 +0800 Subject: Re: [PATCH v12 1/6] memarea: introduce memarea library To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , , , , , , CC: , References: <20220721044648.6817-1-fengchengwen@huawei.com> <20230114114944.42194-1-fengchengwen@huawei.com> <20230114114944.42194-2-fengchengwen@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35D87672@smartserver.smartshare.dk> From: fengchengwen Message-ID: Date: Fri, 20 Jan 2023 16:20:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87672@smartserver.smartshare.dk> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Morten, On 2023/1/15 15:58, Morten Brørup wrote: >> From: Chengwen Feng [mailto:fengchengwen@huawei.com] >> Sent: Saturday, 14 January 2023 12.50 >> >> The memarea library is an allocator of variable-size object which based >> on a memory region. >> >> This patch provides rte_memarea_create() and rte_memarea_destroy() API. >> >> Signed-off-by: Chengwen Feng >> Reviewed-by: Dongdong Liu >> --- > > [...] > >> +struct memarea_obj { >> + TAILQ_ENTRY(memarea_obj) obj_node; >> + TAILQ_ENTRY(memarea_obj) free_node; >> + size_t size; >> + size_t alloc_size; >> + uint32_t magic; >> +}; > > The magic cookie is for debug purposes only, and should be enclosed by #ifdef RTE_LIBRTE_MEMAREA_DEBUG, like in the mempool library [1]. In the mempool the cookie mechanism is under debug macro, the main reason should be performance considerations. And community recommends that compilation macro be used as little as possible. So I think we could add the following new API like: /* * Enable audit in alloc/free/audit. */ rte_memarea_audit_enable(struct rte_memarea *ma) /* * Disable audit in alloc/free/audit. */ rte_memarea_audit_disable(struct rte_memarea *ma) /* * if ptr is NULL, then audit the all objects. * else, only audit the object which the ptr pointers. * if audit fail, will return an error code, and the error log will emit. * * The audit is performed only when the audit function is enabled for the memarea. */ int rte_memarea_audit_object(struct rte_memarea *ma, void *ptr) So for an application, it can invoke rte_memarea_audit() in its code without macro control. If it considers that memory corruption may occur in a certain scenario, the audit function can be enabled, so could find it by error log or retcode. This method causes slight performance loss. But it's guaranteed that there's no need to recompile, and a binary can be done. > > [1]: https://elixir.bootlin.com/dpdk/latest/source/lib/mempool/rte_mempool.h#L154 > > With that added: > > Series-acked-by: Morten Brørup > > > . >