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 B51E4A0542; Thu, 4 Aug 2022 08:37:05 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5A9AA4069C; Thu, 4 Aug 2022 08:37:05 +0200 (CEST) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by mails.dpdk.org (Postfix) with ESMTP id 2ECC34068E for ; Thu, 4 Aug 2022 08:37:04 +0200 (CEST) Received: by mail-qk1-f174.google.com with SMTP id c24so14402189qkm.4 for ; Wed, 03 Aug 2022 23:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=75eosSm8pmMDSroV5VD+EHQCghkPW4f4aQFy1oxchWM=; b=joK03GIrvfftRu8lkbDGKSsHQSyWBgqd6mSAkMH5xyB0g8afSVb02JUXdd10xRmdfC cfvzJ3Ca8ZZJiVanrK9NI/eA97D7aUtrClqcRyCeBh3sFhQ8SQHGRH8/9whZuTBeFCTg GacgZJIJiSYijBe53daJl5v3d1QVHLAZKC1CGREVxd9B0um/LKO8AvBobOFSEtyJutaz uO/D8cwfIUnSUb+RqwH08796djnitfIlaavb/wCF1RqcWF6dldzsohFanBbbl+UC47vX 6WYXMC8fpFg0jzWw7NqJPVtskkoWqdB+/NkGuJjAVAsv9Fktdn2O4PihEWLcI9/HObVO KXrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=75eosSm8pmMDSroV5VD+EHQCghkPW4f4aQFy1oxchWM=; b=4GohsN3O2dR7XkRJBONpENv/RNChECVy28KiN6Cf+B1/srdvYxggAyxBD+M983LJi2 L0GuloxgXmOosbiVuxlbzIbIuG5DoDnPprinRvNY2cmG3XpzCDVTEc8cA1z3jHg07tKy XewwISO92it33b4QX3Uq7ME1FdTJ95SCli+Uq90efAWvZrwuX1DxgtqxzuV7Y5zOyfLo PNJtUyEGdB6Kt+ypfrtCNS4OqtrnW1wOHjma30ADKBOzlDckPhSVjUQwWqRXivi8VvzP No15RtQAZ0VUvgXJbX096LXno+uu8DKi6ZekLwg733ALGcFBtZTDxJ5eAqVIS3LhFiXZ n2+Q== X-Gm-Message-State: ACgBeo1I9a4YKjfCR9OA5iHj6fmS3nKdX9hu2ZNwlw7AYgjWmIHCm5cS ezaeQRNhMn95B4KopMxi/6xFvDOVaaMBxjlrx78= X-Google-Smtp-Source: AA6agR5W+22hx+OMmrAZIsN7s34cjS65OSauRUOayTfHhb+deOsURc6/tWHX/HglZYeS6np0KvxfxbjGAkb0WIcLmpg= X-Received: by 2002:a05:620a:424c:b0:6aa:cdf8:f6f3 with SMTP id w12-20020a05620a424c00b006aacdf8f6f3mr300807qko.26.1659595023262; Wed, 03 Aug 2022 23:37:03 -0700 (PDT) MIME-Version: 1.0 References: <20220721044648.6817-1-fengchengwen@huawei.com> In-Reply-To: <20220721044648.6817-1-fengchengwen@huawei.com> From: Jerin Jacob Date: Thu, 4 Aug 2022 12:06:37 +0530 Message-ID: Subject: Re: [RFC] memarea: introduce memory area library To: Chengwen Feng Cc: Thomas Monjalon , dpdk-dev Content-Type: text/plain; charset="UTF-8" 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 Thu, Jul 21, 2022 at 10:23 AM Chengwen Feng wrote: > > The memarea library is an allocator of variable-size object. It is a > collection of allocated objects that can be efficiently alloc or free > all at once, the main feature are as follows: > a) it facilitate alloc and free of memory with low overhead. > > b) it provides refcnt feature which could be useful in some scenes. > > c) it supports MT-safe as long as it's specified at creation time. > > d) it's memory source could comes from: > d.1) system API: malloc in C library. > d.2) user provided address: it can be from the rte_malloc API series > or extended memory as long as it is available. > d.3) user provided memarea: it can be from another memarea. > > Note: > a) the memarea is oriented towards the application layer, which could > provides 'region-based memory management' [1] function. > b) the eal library also provide memory zone/heap management, but these > are tied to huge pages management. > > [1] https://en.wikipedia.org/wiki/Region-based_memory_management > Looks like a good feature to add to DPDK . > Signed-off-by: Chengwen Feng > --- > lib/memarea/meson.build | 10 ++ > lib/memarea/rte_memarea.c | 52 ++++++++++ > lib/memarea/rte_memarea.h | 205 ++++++++++++++++++++++++++++++++++++++ > lib/memarea/version.map | 16 +++ > lib/meson.build | 1 + > 5 files changed, 284 insertions(+) > create mode 100644 lib/memarea/meson.build > create mode 100644 lib/memarea/rte_memarea.c > create mode 100644 lib/memarea/rte_memarea.h > create mode 100644 lib/memarea/version.map > > diff --git a/lib/memarea/rte_memarea.h b/lib/memarea/rte_memarea.h > new file mode 100644 > index 0000000000..dfbe845595 > --- /dev/null > +++ b/lib/memarea/rte_memarea.h > @@ -0,0 +1,205 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2022 HiSilicon Limited > + */ > + > +#ifndef RTE_MEMAREA_H > +#define RTE_MEMAREA_H > + > +/** > + * @file > + * RTE Memarea. > + * > + * A memory area is an allocator of variable-size object. It is identified > + * by its name. > + * > + * The memarea is a collection of allocated objects that can be efficiently > + * alloc or free all at once, the main feature are as follows: > + * a) it facilitate alloc and free of memory with low overhead. > + * b) it provides refcnt feature which could be useful in some scenes. > + * c) it supports MT-safe as long as it's specified at creation time. > + * d) it's memory source could comes from: > + * d.1) system API: malloc in C library. > + * d.2) user provided address: it can be from the rte_malloc API series > + * or extended memory as long as it is available. > + * d.3) user provided memarea: it can be from another memarea. So we can > + * build the following memory management structure: > + * memarea-1 > + * | > + * v > + * ------------------------ > + * | | | > + * v v v > + * memarea-2 memarea-3 obj > + * > + */ > + > +#include > +#include > +#include > + > +#include > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +#define RTE_MEMAREA_NAMESIZE 64 > + > +/** > + * Memarea memory source. > + */ > +enum rte_memarea_source { > + /** Memory source comes from sys api (e.g. malloc) */ > + RTE_MEMAREA_SOURCE_SYSAPI, > + /** Memory source comes from user-provided address */ > + RTE_MEMAREA_SOURCE_USER_ADDR, > + /** Memory source comes from user-provided memarea */ > + RTE_MEMAREA_SOURCE_USER_MEMAREA, > +}; > + > +struct rte_memarea; > + > +struct rte_memarea_param { > + char name[RTE_MEMAREA_NAMESIZE]; /**< Name of memarea */ > + enum rte_memarea_source source; /**< Memory source of memarea */ > + uint64_t size; /**< Size (byte) of memarea */ > + uint32_t align; /**< Align of allocated object */ > + /** Indicates whether the memarea should be MT-safe */ > + bool mt_safe; > + /** Indicates whether the memarea is visible to multiple process. > + * If the memory source is RTE_MEMAREA_SOURCE_USER_ADDR, this filed > + * depends on user settings and must be set. > + * If the memory source is RTE_MEMAREA_SOURCE_SYSAPI or > + * RTE_MEMAREA_SOURCE_USER_MEMAREA, this filed does not need to be set. > + */ > + bool mp_visible; > + /** User provided address, this field is valid only when source > + * is set to RTE_MEMAREA_SOURCE_USER_ADDR. > + */ > + void *user_addr; > + /** User provided memarea, this field is valid only when source > + * is set to RTE_MEMAREA_SOURCE_MEMAREA. > + */ > + struct rte_memarea *user_memarea; Above two can be in union as it is based on enum rte_memarea_source. > +}; > + > +struct rte_memarea { > + void *private_data; /**< private management data pointer*/ > + struct rte_memarea_param init; > +}; Make it opaque to application. Also, In Terms of features, good to have following items 1)Stats 2)Detects the memory leak.