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 0A095A00C2; Thu, 13 Oct 2022 12:45:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DFE8F42E66; Thu, 13 Oct 2022 12:45:11 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 0F322410F2 for ; Thu, 13 Oct 2022 12:45:10 +0200 (CEST) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Mp5kn5vKHzHtd9; Thu, 13 Oct 2022 18:45:05 +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.31; Thu, 13 Oct 2022 18:45:07 +0800 Subject: Re: [PATCH v8 1/9] memarea: introduce memarea library From: fengchengwen To: Dmitry Kozlyuk CC: , , , , , , References: <20220721044648.6817-1-fengchengwen@huawei.com> <20221011121720.2657-1-fengchengwen@huawei.com> <20221011121720.2657-2-fengchengwen@huawei.com> <20221011185805.4692c00b@sovereign> Message-ID: <1efcf6d9-358f-5fe3-738d-4905b5164e3d@huawei.com> Date: Thu, 13 Oct 2022 18:45:07 +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: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) 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 Sorry to self-reply. On 2022/10/12 12:06, fengchengwen wrote: > Hi Dmitry, > > On 2022/10/11 23:58, Dmitry Kozlyuk wrote: >> 2022-10-11 12:17 (UTC+0000), Chengwen Feng: >> [...] >>> diff --git a/doc/guides/prog_guide/memarea_lib.rst b/doc/guides/prog_guide/memarea_lib.rst >>> new file mode 100644 >>> index 0000000000..85ad57145f >>> --- /dev/null >>> +++ b/doc/guides/prog_guide/memarea_lib.rst >>> @@ -0,0 +1,39 @@ >>> +.. SPDX-License-Identifier: BSD-3-Clause >>> + Copyright(c) 2022 HiSilicon Limited >>> + >>> +Memarea Library >>> +=============== >>> + >>> +Introduction >>> +------------ >>> + >>> +The memarea library provides an allocator of variable-size objects, it is >>> +oriented towards the application layer, which could provides 'region-based >>> +memory management' function [1]. >>> + >>> +The main features are as follows: >>> + >>> +* The allocated object aligned at ``RTE_CACHE_LINE_SIZE`` default. >> >> Isn't this an implementation detail? >> Stating it in the API description limits optimization opportunities. >> Cache line alignment is good in many cases, >> but it can also be a waste of space, >> e.g. for a thread-unsafe region for small objects. >> Can this limitation only (temporarily?) apply to user memory? >> Or can the minimal alignment be a property of memarea? > > You are right, to be more general, I'll add the align parameter to rte_memarea_alloc instead of stating it here. The memarea is targeted to not so general usage, so v9 doesn't add align parameter to rte_memarea_alloc, at least from the internal feedback. We could add rte_memarea_align_alloc() if the align requirement does exist. > >> >>> + >>> +* The memory region can be initialized from the following memory sources: >>> + a) HEAP: e.g. invoke ``rte_malloc_socket``. b) LIBC: e.g. invoke >>> + posix_memalign to obtain. c) User memory: it can be from e.g. rte_extmem_xxx >>> + as long as it is available. d) Another memarea: it can be allocated from >>> + another memarea. >> >> I think mentioning rte_extmem_xxx() is bogus >> because user memory does not need to be registered with DPDK >> (I understand it's an example, but still an unrelated reference). >> Please format as a list. > > okay > >> >>> + >>> +* It provides refcnt feature which could be useful in multi-reader scenario. >>> + >>> +* It supports MT-safe as long as it's specified at creation time. >>> + >>> +Library API Overview >>> +-------------------- >>> + >>> +The ``rte_memarea_create()`` function is used to create a memarea, the function >>> +returns the pointer to the created memarea or ``NULL`` if the creation failed. >>> + >>> +The ``rte_memarea_destroy()`` function is used to destroy a memarea. >>> + >>> +Reference >>> +--------- >>> + >>> +[1] https://en.wikipedia.org/wiki/Region-based_memory_management >>> diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst >>> index 2da8bc9661..f5a67cec7b 100644 >>> --- a/doc/guides/rel_notes/release_22_11.rst >>> +++ b/doc/guides/rel_notes/release_22_11.rst >>> @@ -63,6 +63,12 @@ New Features >>> In theory this implementation should work with any target based on >>> ``LoongArch`` ISA. >>> >>> +* **Added memarea library.** >>> + >>> + The memarea library is an allocator of variable-size objects, it is oriented >>> + towards the application layer, which could provides 'region-based memory >>> + management' function. >> >> "which could provides" -> "providing" > > okay > >> >>> + >>> * **Added support for multiple mbuf pools per ethdev Rx queue.** >>> >>> The capability allows application to provide many mempools >> [...] >> . >> > > . >