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 F2558A0548; Tue, 11 Oct 2022 17:58:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D3D3942E74; Tue, 11 Oct 2022 17:58:35 +0200 (CEST) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by mails.dpdk.org (Postfix) with ESMTP id 7CF2542E71 for ; Tue, 11 Oct 2022 17:58:34 +0200 (CEST) Received: by mail-lf1-f48.google.com with SMTP id b2so21796121lfp.6 for ; Tue, 11 Oct 2022 08:58:34 -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=+vIRyWQn4a0vXzKSDtguk2fpzy9/iC/uGGkZsFDDlYY=; b=o0kaKIMNisVYU8CvBoLBCDpWAxZqKcDEIC/+rLZJcIv3+vGGHLRaxtwT49jlWVq1M7 wOMi0n5AaRe9z/wjRt2gRRQkw7zuYgzF27Au747/FHqllMZnotvHZPdzFz6mnWK7UktI maTZTcPFRUr1e3qLpuPS8AHkw0amwfJ/gqfapa6JGtk9+qcnQHKWDyALrMw8XHM+xrkc suTPV2ASHkIIvViOxWriDoKKlvXO8mpdPo26PHPPYbBjPkzObb8W1brJ/AmFzdhxUr+x D0IqUDAQ0pjufz6zvZp6kEBDjyVYi8gOMGCLIkOtsjo6miLxFR8EKQ0MtB6hfp8FF6p7 rGqA== 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=+vIRyWQn4a0vXzKSDtguk2fpzy9/iC/uGGkZsFDDlYY=; b=u0kHT/uxBQJPyRfa6goMG4x5+ScHBfnvZUnpjp7uhKs1RJ4y4kTlcvLUVcT+DMMD1p OZwkfMLsq6r3JRa+C8laNyA0kcHeAiRuxrfZFKzulBDkmtAQ9r6KkSntzaYWqjkzWcVb 9RZ3NbUNprioikFwb3lLPdUENRSipcSSdZTXdTZYtUGp2fBCCRhzr4diIlIXGbKC+dYe XvIekVM+kVmPsNq8XUn5xCuApGfNdhoQwp8eHMeXsXeHSKBLykEbQhD0x1j8sYtaPahq Aa0tP+BnIOyEyfe8tr5BN/+OnqAzY9mdIkDG4Z3TZaq2Oc/IbKknbr/4OcwOxDqn6+hY e9kQ== X-Gm-Message-State: ACrzQf0eolh/fpkX5Ymf8sdzmb08Yfu1Ea/n/5NiS30WkRBJTDc7vgZ3 WokQaUPj0B7txTnj4sO4VoQ= X-Google-Smtp-Source: AMsMyM43CCzqt7iv/EhCRRu6FILdM1zXWeDthxEAq/WC+svHhSIURZ6OrdOH4xhisDuAf2Zwxf4a/A== X-Received: by 2002:a05:6512:11e9:b0:49d:7909:ff9b with SMTP id p9-20020a05651211e900b0049d7909ff9bmr8338562lfs.568.1665503913967; Tue, 11 Oct 2022 08:58:33 -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 9-20020ac25f49000000b0049771081b10sm1909410lfz.31.2022.10.11.08.58.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Oct 2022 08:58:33 -0700 (PDT) Date: Tue, 11 Oct 2022 18:58:32 +0300 From: Dmitry Kozlyuk To: Chengwen Feng Cc: , , , , , , Subject: Re: [PATCH v8 7/9] memarea: support backup memory mechanism Message-ID: <20221011185832.4aaffcc5@sovereign> In-Reply-To: <20221011121720.2657-8-fengchengwen@huawei.com> References: <20220721044648.6817-1-fengchengwen@huawei.com> <20221011121720.2657-1-fengchengwen@huawei.com> <20221011121720.2657-8-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: > 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. 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. 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.