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 3D1DD42D13; Wed, 21 Jun 2023 12:53:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 271C0406BC; Wed, 21 Jun 2023 12:53:10 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 161074068E for ; Wed, 21 Jun 2023 12:53:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687344788; x=1718880788; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=S8Pfz/moKRlMwG6B5/UXNyIxHIinzOo4FgI4j15gRj8=; b=XmpxS7QFVFfkeKIiDIWKWHgTuDot3c5i4V+ytG9GL9S4Vg/zl9/YHIGJ pA4xhtq2fgIn3cgKevTIxll3WRPNycuWNSECjU1PR87Xm8kOQv7mpOJQn p7hcaimypyCJn0vSfvpUQisx+8eJuq+NyaAcSyg063khE8INsbcjg5279 K/D0PE0wVGmN5CjY7xxJBHxdFGPfCm7Z94lrQpg1E8rnwihINkBo3bIHf pTn4SKNFg46DpaHe1TLIKernOSdNanIMKOaVLiwDYLYQiEGBrsmz1+S77 K8D9z7G/utoPC3Lz4DwhRTrquctpZ1KJ5T24Lb1xUl6LO4SFDA3m3kZmk w==; X-IronPort-AV: E=McAfee;i="6600,9927,10747"; a="389607274" X-IronPort-AV: E=Sophos;i="6.00,260,1681196400"; d="scan'208";a="389607274" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2023 03:53:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10747"; a="714433361" X-IronPort-AV: E=Sophos;i="6.00,260,1681196400"; d="scan'208";a="714433361" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga002.jf.intel.com with ESMTP; 21 Jun 2023 03:53:06 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 21 Jun 2023 03:53:05 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23 via Frontend Transport; Wed, 21 Jun 2023 03:53:05 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.46) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Wed, 21 Jun 2023 03:53:05 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kMo7JJQKl3aGzxg4sKrezd6j+rkCLuTUw34kO11iynieNmjkuXP90Uenped6D8s6+7cobTw8tVWkbn6dASwF/1KnQhshKwuaAFfS3qycvhTMevsHTxqWdaISIt0811qMv4/OGMsoKYY/ZPevZU+UoPILztF0toVSTnfvVZdsVW54aUO7WH9NkFdVDQLXIPftLhfyMW9sJB0dtpKPGzm4q2Vd0RnYQeQFD1nFbytw/es5N1cE9NuPC7c3yy5j4Fzdfchf86UeGxqV7vxWzLBHPsnHdqsF2hlixjCVslYYc0YP/RJFd2qnx+lws8ex3wYbGLUY9JSVQxoGda+Ht6DpVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c2qDwevl/KErIKsmoXeZFIs4CQ+YWBfKIc0RuPQEvP4=; b=iRYsjofCQqYj6vd0BHxlRWXMSbccVuil3dAKxdlXmYOtGKVUrHN6Y8xhi24EfixqeS+z/JXNn8Uirll1Z48CEnXOx7/FWe8KFNqky+UE0qJetX7T3+C1MPqg0PwofhnXUQGsPUfYmj8R5DIRRlpJlKqm8QlYfs8djyer8oie3G0HJ0P04PgxJOdHTfL3XXCMSs143nTdERQADO5dCIe1y5U3Q8yBwS1qC0F+skJCxNzxZMcR+G5XwZB/HCGwEi2yK6+CaLJmmKd+dlytjL88VM7UZ75UUklM+js4pju/b71eLQc2v00GexJTnfqcBP6LgDvVfnFJQ5W8pcMDZTIppw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DM4PR11MB6502.namprd11.prod.outlook.com (2603:10b6:8:89::7) by MN6PR11MB8104.namprd11.prod.outlook.com (2603:10b6:208:46c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6500.39; Wed, 21 Jun 2023 10:53:03 +0000 Received: from DM4PR11MB6502.namprd11.prod.outlook.com ([fe80::49c0:aa4c:e5b4:e718]) by DM4PR11MB6502.namprd11.prod.outlook.com ([fe80::49c0:aa4c:e5b4:e718%7]) with mapi id 15.20.6521.023; Wed, 21 Jun 2023 10:53:03 +0000 Message-ID: <11437550-b6d6-f727-13d5-a2993855781b@intel.com> Date: Wed, 21 Jun 2023 11:52:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.12.0 Subject: Re: [PATCH v14 1/6] memarea: introduce memarea library To: Chengwen Feng , , CC: , , , , , References: <20220721044648.6817-1-fengchengwen@huawei.com> <20230209063610.35501-1-fengchengwen@huawei.com> <20230209063610.35501-2-fengchengwen@huawei.com> Content-Language: en-US From: "Burakov, Anatoly" In-Reply-To: <20230209063610.35501-2-fengchengwen@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DUZPR01CA0047.eurprd01.prod.exchangelabs.com (2603:10a6:10:469::16) To DM4PR11MB6502.namprd11.prod.outlook.com (2603:10b6:8:89::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR11MB6502:EE_|MN6PR11MB8104:EE_ X-MS-Office365-Filtering-Correlation-Id: 310669b0-f990-4db3-f591-08db7245af60 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZUzXJdFutlA7tQ2tNWuXV4PSBF6eFFTkKsFeikhZTnxThk+9Ow4qGXHZKSqKrcLQulhoTghuL5+2aLjqU+wcZ3HDuIieyRcTq8W8wBEgKHaEjbxUf4ndQTFA+KePCte3z8uBYx/OHy2+KHwIbV/ZgTp9JnIqq1OYRCULDC2cgvGlrU6gqq+P1auaTj3I059biUgTTGH1Sw4bwuSk5adwNlWxHZmQ1C7JRUO/EdWoi3+Ny9RVhM5I9Dq1XDKScby9DNEZ+MEgCiCpW3zVUs9I+8c7trYts9uNuZNOQrZrxDAcyyxPK2TV+R3WEumHqGezFWStoJKDa6G5zq7NsCwM1izWS00OcSRCe3Poc7L9CdxQhggbk82BJFwTM4ZJ9gUBrDP54Ghe6pIPUiXrEyguJAR1VgwcmoQAcvQV3NUNXHBPso7xr4TVoXcrPbmIjbWUYv4Phq8xFL3yg0KoyfBaCplgu10KZnz+esK6Qp/vihqH1IOv8DmmQd5kqQw99bC5RxgWGA6wDrxJ/9s6sp8xhU3KmMzUTJzRwR1YjkyUcGZ6urR2X6l0l2Og81UwNN9+LLQrXmBm4EtTAzx5HZ/Vl4d6cdVIwbM0zJrz6mkL0RWFLlzGTUGu1lhY7KFAhYKFda8+KVUT3y39syYPbrnaKQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB6502.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(346002)(366004)(396003)(376002)(136003)(39860400002)(451199021)(82960400001)(38100700002)(53546011)(66574015)(26005)(6512007)(6506007)(83380400001)(186003)(2616005)(2906002)(41300700001)(5660300002)(8676002)(8936002)(36756003)(6666004)(6486002)(478600001)(4326008)(66476007)(66556008)(66946007)(316002)(31696002)(86362001)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bmhReTRxWmFMdUUweXh2LzVUakxoZkVPakxNWUlSdGdZdzEzSVhvWkdrUDcv?= =?utf-8?B?SCtJaTd0ZEhGYnBZTy9NNEFqTlJqcUJGL3BTcEEvRzJSNTIxVWpLOXhsY0hT?= =?utf-8?B?UGxQMklPS201VDNWN3NxU3dHZkViNEJlNWU1d2hNN1ZDVXl1ODlpaU8yaEho?= =?utf-8?B?WEo2aFdNb2JpeCtUdHExRGRWN1FOeStkckR4NlZSMlIrakxCdGlhZGl1TnRy?= =?utf-8?B?R1AzMjc3aktsN0JPN1lPNHhDcldpaDRORzVReFNIbUZod1lJSFdDV2E3d1B1?= =?utf-8?B?N0NDc3ZrVnBocHpvS3FPakxmYTJkTldxK3REcDFHUFoxd05sZHRSOU1rV25I?= =?utf-8?B?OXo3Q1FxUTgwN3RlMGx2SDlBcFRxc0RRUEdHVEhna1ZvaFhyenhqOVNaSlM1?= =?utf-8?B?eFNXMCtidUgxcHZ5SEVqTUQ2SUJQeFdYSHorOTNVUFBYdGdIRHhMS2JkbjhO?= =?utf-8?B?WW9oWmF5TzI2aGVJVWI0T0UwVU1FNDgrU3F5NXV5LzN0eXZ4bUN1T0NsdldW?= =?utf-8?B?bXV4dDJwZUtPOFJvNzZ1Z2NrRERXdnBFNlZSQm1kMTlLZWFlY0t6aTkwS1p5?= =?utf-8?B?S2Z3MG9XYnR6M0JULzdJTTh4d2RpbjNKVXUvQ2dPcC9GMGJTNlhueTJwTmZB?= =?utf-8?B?d2ZHM0QvWFVVb1loWTNNQTQ4aGRDSFBrMzRIUG1CK05xSlF6bHVLVlNvbm1J?= =?utf-8?B?NGtjSEdUQ2VNZkVGRkdzTTRhQ2FVekRWNDdqK2RuWGdhcXhQM2NHaTRyMXJs?= =?utf-8?B?bEpDb0o2TmNncUpkb0dRT2oxQ1RWZG9CbkdNU0dZSTFnZ01JSXpVNVRvbUhS?= =?utf-8?B?NFMyV2J4Vlg1b055QmxEM2FaQUp5Q2pPVmFOTTRYdTNueTFPSFprcUVLL1M3?= =?utf-8?B?T0xEWk4vZTdtTnlqejRpeUZweFRMNmxsOElqaUJjSmhnTnQ1eStuZlZyTEQz?= =?utf-8?B?NzhzZU9vcTNSMDRNVEwrYXlPajc1SnY1V0IvZjBlZFRIRDZ2U29JektmZytE?= =?utf-8?B?NG9RYktLdE8yNzZ1MmVDY0ZNRjV0WGU0VUwzeVVlSlF6QTJXU0NtN3JNSnc5?= =?utf-8?B?SzdjQVU4S0lOejdaUlNKQWRoVG1Za2JYeHM0eEtnZmJaajhWZVYzMkI3WlN5?= =?utf-8?B?bkVJQ2lYZEpsTDRqMGZ4Um5odUpNOG1VRXRLSGVEQVVwNkFPMDVsMTRyVnFQ?= =?utf-8?B?RTNrR1BQSDV6RzNucW4rNkcxWW85dHhSb2tJdEVYeVNDM205VHlrSW5XSnVk?= =?utf-8?B?Ny9RWXcycGNJdnF6R1NBMFZEdzN5VzYzbVoxTzNrZGt5TTIrYSt2NE9iVkR6?= =?utf-8?B?WlN6OWJSVGNWM1cvRzFHQjI0ZnFrd2I3QlM5OTd2aDFwK2tVZHE0SzV2WTdF?= =?utf-8?B?ajdyREpLRDlKN1FMS2xoZTFNSUVCVDJtWHVsR2oxbUQrWHJNUmQxbmpqZ3lo?= =?utf-8?B?R2JTbWRYT3RvU0Jkc3pHVnUwRmZsRW45Wnc5WTY3QnBZaHgyRExLVmxzMmdN?= =?utf-8?B?b3BuVU1NM216d1ZTekEzU0FENnZvcTY3N3hyS0dBSHRVcnpWc2NaenUvblk2?= =?utf-8?B?M1prYnlraVZVcDQ2SXF2MS9Qc2xaSnR6UEErdVJNZlh2U3pxZkVteXJZNUJB?= =?utf-8?B?SGRBZ0Q0Nnh0NFFPTFFGeWlOdXhFUk0xaUl2SFEzcUJTMXBac0t1NVFZa1Qr?= =?utf-8?B?WEc5UmJ2Q2x3SU5kalNXQThFUEJ1NXNZUGVkY0RGQkJRSnE4YllRVzZzL1oy?= =?utf-8?B?MWUzVmNNWHZaVS9rZFFQZnlUaDRmdkIxMTFCUE1jc0ZWUkZlbHBycGFlaWZu?= =?utf-8?B?NWlmN3BRYUlQc1dpUVZzNytnbytQd1kzVHg3QXpLYmZzcGZ1aXYxSTdCb2VZ?= =?utf-8?B?cWRibVVKdkh0NTN0d0xTU2wrMjRHVWMvS245ZEY2RnpKUnkrNnJERGtETk1J?= =?utf-8?B?bkJ2cy8vc1Q0Vjg1dGREenhWUmZPa2FKWGRvZFNuVFh2Wm9GZ0c5STVRVjZI?= =?utf-8?B?Q0JOWWtjK2I3eC9TekVpL251QjJLbDd6dXEzbEwyRzVPeUUwYU8zOGJad2I4?= =?utf-8?B?UmlZY1BwaGplTk85R2RBcXdCVElDN08vRXZpVHg2c2ZjbXBqOU9RUHRIWGVN?= =?utf-8?B?OEY2bldCYVp3OTIrQlRURXNGcUk4ZUprM2xPTVNEaUFaeEluZWNvamdxMUR6?= =?utf-8?B?dUE9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 310669b0-f990-4db3-f591-08db7245af60 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6502.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2023 10:53:02.7927 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hKlyGL7v+Jwan9W4VtcLvlR/8utEBQZ/e2jU3lhqqTV8U4bg5DOUmiHGVrHrwmLUNMdtveaPgdPq7YtoASvJs+UiMxkMQi/7Zqdc2Nm7Hbw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR11MB8104 X-OriginatorOrg: intel.com 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 2/9/2023 6:36 AM, Chengwen Feng wrote: > The memarea library is an allocator of variable-size object which based > on a memory region. > > This patch provides rte_memarea_create() and rte_memarea_destroy() API. > > Signed-off-by: Chengwen Feng > Reviewed-by: Dongdong Liu > Acked-by: Morten Brørup > --- > +#include "memarea_private.h" > + > +RTE_LOG_REGISTER_DEFAULT(rte_memarea_logtype, INFO); > +#define RTE_MEMAREA_LOG(level, fmt, args...) \ > + rte_log(RTE_LOG_ ## level, rte_memarea_logtype, \ > + "MEMAREA: %s(): " fmt "\n", __func__, ## args) > + > +static int > +memarea_check_param(const struct rte_memarea_param *init) > +{ > +#define MEMAREA_MIN_SIZE 1024 I don't see this limitation being documented anywhere? This probably should either be moved to `rte_memarea.h`, or at least called out in the API documentation. > + size_t len; > + > + if (init == NULL) { > + RTE_MEMAREA_LOG(ERR, "init param is NULL!"); > + return -EINVAL; > + } > + > + len = strnlen(init->name, RTE_MEMAREA_NAMESIZE); > + if (len == 0 || len >= RTE_MEMAREA_NAMESIZE) { > + RTE_MEMAREA_LOG(ERR, "name size: %zu invalid!", len); > + return -EINVAL; > + } > + > + if (init->source != RTE_MEMAREA_SOURCE_HEAP && > + init->source != RTE_MEMAREA_SOURCE_LIBC && > + init->source != RTE_MEMAREA_SOURCE_MEMAREA) { > + RTE_MEMAREA_LOG(ERR, "%s source: %d not supported!", > + init->name, init->source); > + return -EINVAL; > + } > + > + if (init->total_sz < MEMAREA_MIN_SIZE) { > + RTE_MEMAREA_LOG(ERR, "%s total-size: %zu too small!", > + init->name, init->total_sz); > + return -EINVAL; > + } > + > + if (init->source == RTE_MEMAREA_SOURCE_MEMAREA && init->src_ma == NULL) { > + RTE_MEMAREA_LOG(ERR, "%s source memarea is NULL!", init->name); > + return -EINVAL; > + } > + > + if (init->alg != RTE_MEMAREA_ALGORITHM_NEXTFIT) { > + RTE_MEMAREA_LOG(ERR, "%s algorithm: %d not supported!", > + init->name, init->alg); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static void * > +memarea_alloc_from_libc(size_t size) > +{ > +#ifdef RTE_EXEC_ENV_WINDOWS > + return _aligned_malloc(size, RTE_CACHE_LINE_SIZE); > +#else > + void *ptr = NULL; > + int ret; > + ret = posix_memalign(&ptr, RTE_CACHE_LINE_SIZE, size); > + if (ret) > + return NULL; Would `ptr` not be NULL if ret wasn't 0? > +struct rte_memarea * > +rte_memarea_create(const struct rte_memarea_param *init) > +{ > + struct memarea_objhdr *hdr, *guard_hdr; > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + struct memarea_objtlr *tlr; > +#endif > + struct rte_memarea *ma; > + size_t align_sz; > + void *ptr; > + int ret; > + > + ret = memarea_check_param(init); > + if (ret) > + return NULL; > + > + ptr = memarea_alloc_area(init); > + if (ptr == NULL) { > + RTE_MEMAREA_LOG(ERR, "%s alloc memory area fail!", init->name); > + return NULL; > + } > + > + ma = rte_zmalloc(NULL, sizeof(struct rte_memarea), RTE_CACHE_LINE_SIZE); > + if (ma == NULL) { > + memarea_free_area(init, ptr); > + RTE_MEMAREA_LOG(ERR, "%s alloc management object fail!", init->name); > + return NULL; > + } > + > + hdr = ptr; > + align_sz = RTE_ALIGN_FLOOR(init->total_sz, MEMAREA_OBJECT_SIZE_ALIGN); > + guard_hdr = RTE_PTR_ADD(ptr, align_sz - sizeof(struct memarea_objhdr)); > + > + ma->init = *init; > + rte_spinlock_init(&ma->lock); > + ma->area_base = ptr; > + ma->guard_hdr = guard_hdr; > + TAILQ_INIT(&ma->obj_list); > + TAILQ_INIT(&ma->avail_list); > + > + TAILQ_INSERT_TAIL(&ma->obj_list, hdr, obj_next); > + TAILQ_INSERT_TAIL(&ma->avail_list, hdr, avail_next); > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + hdr->cookie = MEMAREA_OBJECT_HEADER_AVAILABLE_COOKIE; > + tlr = RTE_PTR_SUB(guard_hdr, sizeof(struct memarea_objtlr)); > + tlr->cookie = MEMAREA_OBJECT_TRAILER_COOKIE; > +#endif > + > + memset(guard_hdr, 0, sizeof(struct memarea_objhdr)); > + TAILQ_INSERT_AFTER(&ma->obj_list, hdr, guard_hdr, obj_next); > + MEMAREA_OBJECT_MARK_ALLOCATED(guard_hdr); > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + guard_hdr->cookie = MEMAREA_OBJECT_HEADER_ALLOCATED_COOKIE; > + /* The guard object have no trailer cookie. */ > +#endif Nitpicking, but can we move the #ifdef-ery into functions? E.g. have something like set_header_cookie(hdr); ... set_trailer_cookie(guard_hdr); and have them just be noops if RTE_LIBRTE_MEMAREA_DEBUG is not defined? > + > + return ma; > +} > + > +void > +rte_memarea_destroy(struct rte_memarea *ma) > +{ > + if (ma == NULL) > + return; > + memarea_free_area(&ma->init, ma->area_base); > + rte_free(ma); > +} > diff --git a/lib/memarea/rte_memarea.h b/lib/memarea/rte_memarea.h > new file mode 100644 > index 0000000000..435dca293f > --- /dev/null > +++ b/lib/memarea/rte_memarea.h > @@ -0,0 +1,122 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2023 HiSilicon Limited > + */ > + > +#ifndef RTE_MEMAREA_H > +#define RTE_MEMAREA_H > + > +/** > + * @file > + * RTE Memarea. > + * > + * The memarea is an allocator of variable-size object which based on a memory > + * region. It has the following features: > + * > + * - The memory region can be initialized from the following memory sources: > + * 1. HEAP: e.g. invoke rte_malloc_socket. > + * 2. LIBC: e.g. invoke posix_memalign. > + * 3. Another memarea: it can be allocated from another memarea. > + * > + * - It supports MT-safe as long as it's specified at creation time. If not > + * specified, all the functions of the memarea API are lock-free, and assume > + * to not be invoked in parallel on different logical cores to work on the > + * same memarea. I think it would be nice to explicitly mention three things here: 1) that the alignment is always on cache line boundary 2) that the memory is not intended for DMA purposes 3) that secondary processes are not supported Also, *technically*, "another memarea" is only supported starting at commit 3, so I would suggest either adding stubs to support it in this commit, or not add it to the enums. > + */ > + > +#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 rte memory. */ DPDK memory? rte_malloc memory? I don't think we use the term "rte" to refer to DPDK anywhere outside of legacy usages > + RTE_MEMAREA_SOURCE_HEAP, > + /** Memory source comes from libc. */ > + RTE_MEMAREA_SOURCE_LIBC, > + /** Memory source comes from another memarea. */ > + RTE_MEMAREA_SOURCE_MEMAREA, See above note about this not being supported in this commit. > +}; > + > +/** > + * Memarea memory management algorithm. > + */ > +enum rte_memarea_algorithm { > + /** The default management algorithm is a variant of the next fit > + * algorithm. It uses a free-list to apply for memory and uses an > + * object-list in ascending order of address to support merging > + * upon free. > + */ > + RTE_MEMAREA_ALGORITHM_NEXTFIT, > +}; > + > +struct rte_memarea; > + > +/** > + * Memarea creation parameters. > + */ > +struct rte_memarea_param { > + char name[RTE_MEMAREA_NAMESIZE]; /**< Name of memarea. */ > + enum rte_memarea_source source; /**< Memory source of memarea. */ > + enum rte_memarea_algorithm alg; /**< Memory management algorithm. */ > + size_t total_sz; /**< Total size (bytes) of memarea. */ > + /** Indicates whether the memarea API should be MT-safe. */ > + uint32_t mt_safe : 1; > + union { > + /** Numa socket from which to apply for memarea's memory, this > + * field is valid only when the source is set to be > + * RTE_MEMAREA_SOURCE_HEAP. > + */ > + int numa_socket; > + /** Source memarea, this field is valid only when the source is > + * set to be RTE_MEMAREA_SOURCE_MEMAREA. > + */ > + struct rte_memarea *src_ma; Wouldn't it be better to have these fields inside structs indicating relevant modes? E.g. param->heap.numa_socket as opposed to param->numa_socket - I think this will be more self-explanatory in code. Also, I think the convention around DPDK is to refer to NUMA sockets as `socket_id` rather than `numa_socket` so for consistency I think it would be nice if this was the case here as well. -- Thanks, Anatoly