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 65923A0548; Tue, 11 Oct 2022 17:58:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 466D842DE1; Tue, 11 Oct 2022 17:58:09 +0200 (CEST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id 5E4CF42B7D for ; Tue, 11 Oct 2022 17:58:07 +0200 (CEST) Received: by mail-lj1-f181.google.com with SMTP id q7so14905602ljp.3 for ; Tue, 11 Oct 2022 08:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=837hFb0oaiURz5chjavFpEFKgNBfytCRkX75oIL7GKA=; b=E0BKCc/3RLcIsCQZWhIdkCPh9SEspNfgJjKEi5xLXcT35jDoqnb2ONcdCX1tRq+asO KOl1TSqEZR5PrKoDzIwBaWMi4+Qd0JpXdax9tHrItAfD5gYNdZwhAaRvrv/a9z86mp29 hp8XrhSGAVnmT8qTq0UzjZxdC3PLTtHLvdM+MR+BaHfczZNMTW+Ai4TP8OdsBKtqTQ70 cFWZKZ4tpnW3uYWvkPPrH2cJ56HOrFAPwXKnZ/W6iUqF6bSx9kKEFstFwyE1VeuF9m/f loqmLp/+gHEYFKvOn+96KtLyJXthRhNK6EL0xZ8XkBbzvdQj0wttdsG/HAJ0oUX1S1uP HSgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=837hFb0oaiURz5chjavFpEFKgNBfytCRkX75oIL7GKA=; b=KzPZNj2dg6MCfr5KGsFRL96xRIuTLUgtbJHa+meYrXVcl3AnBp0/hNfKpuVSCOhzUb 3FwvuHwUoHxjCT0g/YqJfsSVEPj2dQ9IK3tyw6W/FRw6I2ooP0eTrzr0iPTvte+12woU lvaHuSWEN2AvTCFtS9aDmWQG+JYoj55sKeV0uiSYVd3iXamj9NUX0fJKVQsPNTq+kGaO GXCYVR1G2xqQoRoEUFC5/+D0M1Aw3S1irU9G5JZGnOUV1o+lfTZ/X/QHTUD4L2D8ePBr d3/i5lA7KZv94wuZ4NBFOyfNSZveyq9C/gw4JH6uRAZ4GRHYlTyPIZEgopq2aTll2zV7 Eiiw== X-Gm-Message-State: ACrzQf1p4YhyvR3KzAP576LfM4RXUv8CvoKDmh2uXUx+m4VIBF7vA0wX P+JZkKnDmKE0ziUfCmAvHUg= X-Google-Smtp-Source: AMsMyM5KWaRI70ZcjC9Waivgv0M/biqXYXUM7b+pDcXp0iLfANCAhZyokmUxsn0t0FAXHFY8cFgmgg== X-Received: by 2002:a05:651c:1141:b0:261:6ea9:ac97 with SMTP id h1-20020a05651c114100b002616ea9ac97mr9552198ljo.434.1665503886646; Tue, 11 Oct 2022 08:58:06 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id k11-20020a05651210cb00b004947a12232bsm1902098lfg.275.2022.10.11.08.58.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Oct 2022 08:58:06 -0700 (PDT) Date: Tue, 11 Oct 2022 18:58:05 +0300 From: Dmitry Kozlyuk To: Chengwen Feng Cc: , , , , , , Subject: Re: [PATCH v8 1/9] memarea: introduce memarea library Message-ID: <20221011185805.4692c00b@sovereign> In-Reply-To: <20221011121720.2657-2-fengchengwen@huawei.com> References: <20220721044648.6817-1-fengchengwen@huawei.com> <20221011121720.2657-1-fengchengwen@huawei.com> <20221011121720.2657-2-fengchengwen@huawei.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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? > + > +* 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. > + > +* 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" > + > * **Added support for multiple mbuf pools per ethdev Rx queue.** > > The capability allows application to provide many mempools [...]