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 B95FDA0548; Tue, 11 Oct 2022 22:26:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A490340687; Tue, 11 Oct 2022 22:26:16 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 3C74140146 for ; Tue, 11 Oct 2022 22:26:15 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E9C3E1A056 for ; Tue, 11 Oct 2022 22:26:14 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E87801A055; Tue, 11 Oct 2022 22:26:14 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -3.0 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 330011A1C9; Tue, 11 Oct 2022 22:26:11 +0200 (CEST) Message-ID: <4a8e9496-17ac-d58a-9744-00630c4b7412@lysator.liu.se> Date: Tue, 11 Oct 2022 22:26:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v8 7/9] memarea: support backup memory mechanism To: Dmitry Kozlyuk , Chengwen Feng Cc: david.marchand@redhat.com, mb@smartsharesystems.com, anatoly.burakov@intel.com, jerinjacobk@gmail.com, thomas@monjalon.net, dev@dpdk.org References: <20220721044648.6817-1-fengchengwen@huawei.com> <20221011121720.2657-1-fengchengwen@huawei.com> <20221011121720.2657-8-fengchengwen@huawei.com> <20221011185832.4aaffcc5@sovereign> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: <20221011185832.4aaffcc5@sovereign> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 On 2022-10-11 17:58, Dmitry Kozlyuk wrote: > 2022-10-11 12:17 (UTC+0000), Chengwen Feng: >> This patch adds a memarea backup mechanism, where an allocation request >> which cannot be met by the current memarea is deferred to its backup >> memarea. > > This is a controversial feature. > > 1. It violates memarea property of freeing all allocated objects > at once when the memarea itself is destroyed. Objects allocated > in the backup memarea through the destroyed one will remain. > > 2. If there was an API to check that the object belongs to a memarea > (the check from rte_memarea_update_refcnt() in this patch), > it would be trivial to implement this feature on top of memarea API. > > Nit: "Deferred" is about time -> "forwarded", "delegated", or "handled over". > > A general note about this series. > IMO, libraries should have limited scope and allow composition > rather than accumulate features and control their use via options. > The core idea of memarea is an allocator within a memory region, > a fast one and with low overhead, usable to free all objects at once. > What's a typical use case for a memory region? In a packet processing context. The ability to instantiate a variable number of heaps/regions seems useful, although it's not clear to me if the application should order that to happen on a per-lcore basis, on a per-NUMA node basis, a per--basis, or something else entirely. It seems to me that DPDK is lacking a variable-size memory allocator which is efficient and safe to use from lcore threads. My impression is that glibc malloc() and rte_malloc() are too slow for the packet processing threads, and involves code paths taking locks shared with non-EAL threads. > This is orthogonal to the question from where the memory comes from. > HEAP and LIBC sources could be built on top of USER source, > which means that the concept of source is less relevant. > Backup mechanism could instead be a way to add memory to the area, > in which case HEAP and LIBC memarea would also be expandable. > Memarea API could be defined as a structure with callbacks, > and different types of memarea could be combined, > for example, interlocked memarea on top of expandable memarea on top of > memarea with a particular memory management algorithm. > > I'm not saying we should immediately build all this complexity. The part with implementing runtime polymorphism using a struct with function pointers, instead of the enum+switch-based-type-test approach, doesn't sound like something that would add complexity. Rather the opposite. Also, having a clear-cut separation of concern between the-thing-that-allocates-and-frees-the-region and the region-internal memory manager (what's called an algorithm in this patchset) also seems like something that would simplify the code. > On the contrary, I would merge the basic things first, > then try to _stack_ new features on top, > then look if interfaces emerge that can be used for composition.