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 9EF0E42D1C; Thu, 22 Jun 2023 17:29:52 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8A02640DDA; Thu, 22 Jun 2023 17:29:52 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 9827C406BA for ; Thu, 22 Jun 2023 17:29:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687447790; x=1718983790; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=s4Fvn+602Qx5+ERsS6+jmSbAG+vBi+3ffuP2lgZ8IUs=; b=TTbkl0309pZVvPPcxk2Kmrn0WzlEpQtl74sdp4+HyyM2CSWcaR0sfdnR cJerN0GWPsAb5fNXFPN50dovIG1M/y7m1yfSb+YbvEUlluzaAxbb6mPvb H4O3oNjUf9wEOleW8fvT545w3TsnBmyR/jBlcpTVAW5QGUu74yBRSHhU/ kxA5rl/QVi4cuVHL/t8XuMyLNyDDkXkoUmrwZL5A+6WLAHn5Voh9nyNCm cjM0RarN7nIYDgQqE4FJ+FeClIjFPTPnA1qb/C5Dv+TfVmVe72jg7UT5+ KIn1m0iLGc3IwuMexKdSz4nX0oYSgNA3t1BTf3Bldl/n2SBoBxZ9AkcJx w==; X-IronPort-AV: E=McAfee;i="6600,9927,10749"; a="390285790" X-IronPort-AV: E=Sophos;i="6.01,149,1684825200"; d="scan'208";a="390285790" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2023 08:29:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10749"; a="889087434" X-IronPort-AV: E=Sophos;i="6.01,149,1684825200"; d="scan'208";a="889087434" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga005.jf.intel.com with ESMTP; 22 Jun 2023 08:29:32 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 22 Jun 2023 08:29:32 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) 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; Thu, 22 Jun 2023 08:29:32 -0700 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.46) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Thu, 22 Jun 2023 08:29:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iSKi4VuE3wpoQXuYd2DSGBsVBWVT+NJW4s8yRte8mu79uR5gQmeh2WjrjdaBQ6R/+kRdzP/A8qBrQLtWoFcNeIYUwOLnB+4p5UevhB57pTh5BAZwG/Fj2BQYYfqhemNYzp7TgQyIi3rYZMmlNQoVMnbit9coy8Fk20xYHeWzW/cqPuAe5JB36+AQFTzRVlHVDjKMNYGVFSfcdMN2DzTihFuzQBaX/LQZELz0PesF7gWFK2oESShd0bCjQoVIdZ3grRC/TEmLtXbZUWr+TTAlf0uGzak9xN1jhduPwlP89ACtHj3VfYnDHw6T2CpkbuVhte9zqAIulP82wEYBfxzbKQ== 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=RAmEplc4qOPYYi3pK8nVbL//Tg5JM6RM83x13U3H0IU=; b=m4MkpTTlU7g2LVHztaAsDaKVBRvRZXkNjx3S59djyMiwwONLMphgOP6hs1NPD4M5AjYR7hOwQzv4ngCh3mpXXyAWF6queXsnYjeXM4tPfjv/9WHVIT+55fceCua3CEuaWQmNuZoQhrr45LgDTmuA0nPGD2LZ9uY7bXz3ycBg25V16pfEnxvzfycC0OUVO0saPz+XAo9vFsBvQYyFoa0N2/Ft1DmjOwY+IpZg59HcIm87RjhrhZHLVoTAsCoFuSVFoAxgqCGoJFjFAvQxBHqwAwrsPnHyI/NKcRYHwLYCAzSierjA3ZCRq6zNkosLuct+gUW1qcLXkK90Zu0XOvwsGw== 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 DM6PR11MB4545.namprd11.prod.outlook.com (2603:10b6:5:2ae::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6521.26; Thu, 22 Jun 2023 15:29:29 +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; Thu, 22 Jun 2023 15:29:29 +0000 Message-ID: <3e32afa5-827e-04ac-4fd2-70d6cd9352a4@intel.com> Date: Thu, 22 Jun 2023 16:29:23 +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 3/6] memarea: support alloc and free API Content-Language: en-US To: Chengwen Feng , , CC: , , , , , References: <20220721044648.6817-1-fengchengwen@huawei.com> <20230209063610.35501-1-fengchengwen@huawei.com> <20230209063610.35501-4-fengchengwen@huawei.com> From: "Burakov, Anatoly" In-Reply-To: <20230209063610.35501-4-fengchengwen@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0238.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a7::9) To DM4PR11MB6502.namprd11.prod.outlook.com (2603:10b6:8:89::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR11MB6502:EE_|DM6PR11MB4545:EE_ X-MS-Office365-Filtering-Correlation-Id: c4f78723-d73e-4bf3-0b74-08db73357860 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 25j2dkN37Sqnen5IX5+SL39Kk9iA/gvBJxVlGJa1sRhWz/6CB/GvLmWz9PgNavsMu5c2rwYR2vyf0q3peFAZPNQdRmMAxjq0o4nb3VlTKCb3rNAaFsZISt3/wOTI2tEXETJ6oFgKud+vBpe2arjm/nDEcdF3eDr8ZnfqZ433lVT2SI2Kjs30qiA2Brb4CoJrk0NRay8mJ9+Yx8Sj5wjBpb66hJi1kNSndOsEQGt1qs+IgoTfMqE5DHl1h3BF1dwnxwNkSzTOWT/hFXhndJcu+vuWuEv7xmzXIfnfMfe0eSoZ7mfvoqelqZGYmlbEMHVPfjZGobRlVflgUG3vunorropFLuTtinfE5gm4JhXZzVB7+FYOKT1nkBRpLCA/sRmWdfYAfCtG0tHggLpMx2GfGU1vTSfbQNP/TvIHKJ71BsDZTaLZy2UXBqSuKtKbfXIOWhM4xh0VI+IGp6g9VJa9ejJoyp2INrwdVXJ1ymHmhfcianWNRJ2fNpe1Psw0Jv3J9TPFffi8BTMOieOmsAObAI9xWxCcKN+WhZA7YG3NSyp8HM8eaoIYEuhpKhBQUcr/WqRa1A2RDRq/u9jwHjxM2qtbsWCcp7JAM68AJrzzLK9QNHykSvM+BMwvy4PeSEUKZHa9B/MRGworm+3hwLkZfw== 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)(376002)(136003)(366004)(346002)(39860400002)(396003)(451199021)(31686004)(6666004)(53546011)(6512007)(6506007)(186003)(6486002)(478600001)(82960400001)(2616005)(86362001)(31696002)(66476007)(66946007)(4326008)(66556008)(83380400001)(41300700001)(66574015)(316002)(5660300002)(2906002)(26005)(38100700002)(36756003)(8936002)(8676002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S2E0RUF5cmJrWjVacGRyejFVUXVMamhhQzV0cUFXR09wcGZDK2tXdmVTcE1N?= =?utf-8?B?TWFNWkhwTUFUM1ZwY0YrTEdlMmdkc2JaWnlGcGV4VU9yR0s3dkppaklxZ2Jx?= =?utf-8?B?ODNHYzlqQ0VrN1FtZktsNjV6dlRxYWxiamZaY21WN0ZtSk5PSGdjQm5IbXB0?= =?utf-8?B?WVhMalVHT1BuRzUzSFFOc1VkWXVYQU9tNStDRFJUeFJxcjZmYTNrc1JoQTJ1?= =?utf-8?B?cThvQ1dyRHRjRG1GWjlMZ3JJUVZob1Z6VUlZQmthd04zVmtaMW1IeDROTFlL?= =?utf-8?B?Q05EenRaKzk2Rm9DaHhmT1J3MnprU01sTFBUQ3Fmc2wwMnF5dGZiS3VpdjZv?= =?utf-8?B?VjdVM3pMOUxOK2NYeldGeWdZWDhUNm5Gdk8xVWhEQXl2c0x1Z0tGTTVhNDJk?= =?utf-8?B?Vy9DVlJCYkVIcTZEcGdwNlIrdEVkTVZyUjV4aVRZaTRXZzhjTHYxWlpmeGht?= =?utf-8?B?cXRCQ2l6WUd5b2FhMXFabjVTUU43OHVTV1YrcUhXczg3N3I0dWpqTUd1UitQ?= =?utf-8?B?NGUvTVdENkRDU0ZCSmNkQzRjeUduUTlTK2FrVUpYVEtQZ3JrdjFOazhRa3Ez?= =?utf-8?B?U3ROSnhsR3o3VGtGZXBpdWc1ckZPbjlRU3VmTDRrRlVPTWZ3cHpyNnI2alNE?= =?utf-8?B?SkN2NnlJaE90alZOQUlPTDVnOUNlZUFIY2RWZnpsS01neVg5SE5wUC9EMW5p?= =?utf-8?B?SkpkMUtQdTNOazZCTlA0K0pkNU51Vk0wdzNuRGpmMFN5VjV2OG9MMmp6SzVY?= =?utf-8?B?b21xZ2xCVGV5RDVRNjdrdUFQMytNcGNlNURnTmpMZWZKYnl5SGozVG5KNXd3?= =?utf-8?B?WDNUVVJrMkhicHVUTzRaU1JaakYrUzl4MFlvNVJ6dW8wb0dUbHJVUERJREdn?= =?utf-8?B?NmtBUGRoV1hiN2J0MlpWbTJubGsvWVV4aVhmOHpNTXN5dWZIdlFqQnFOaE1m?= =?utf-8?B?T0pzelpOTHRjemsraXJmVFpXbTcyUFYxY2x3aGkzMlVpZVNJa3ZDN1NqNmwz?= =?utf-8?B?UmlpSnduUjJtN21oanRydE5yeWhpREk0ZHRadHpuTitBQW5LM09iTjByRWNG?= =?utf-8?B?WTk5RHA2bkZabWlKSG5pYWdBdmd2c2NacHZkS29mQTBFcFZUM284Ri8wbUlk?= =?utf-8?B?S2IwblBtRWIwR2lXSnY1ZEt2UHdoZEswM2FKcW1LOVNwV091SzQ0ZXVqamN0?= =?utf-8?B?WE85a1VxMy9GMlc2eFVQTUxKSncxV2s5NWRseE1PYlU3bFdsSURVZ2FFSC9E?= =?utf-8?B?NTNJeHdFTVFlVlRiOWdMOFRrWERxVitXUnNublYxd1VxV2RQRWViZDN4VjI1?= =?utf-8?B?NmJ4Wk5SSTY4a3lkN3F5SU56cGF1eVc2WGNLZDlDSDZTK1hmcm01d3FISXFZ?= =?utf-8?B?Y3FVYUVEbUxBSTgzZW5ENFFjdEpSc21PV09HTHkrRXgxb3dVODVWV1ZHVkM1?= =?utf-8?B?aTRMaXo5QTJqSmhvRFVhb3V2TlMxZnFrbDhzaUVtcU1PS0hxc2ZvOHpPTkRC?= =?utf-8?B?RklVR1pvUUVhT2tnV1BVUmZMbG1OTEdXU0NtMnAzNnhqSGpKcHpXNjJLdk8z?= =?utf-8?B?VVdSbDVSWFZKTFRGcHZLQUdGZzNROUdpRC9xSTlUa1hRK2h5dkhuYjhPV09M?= =?utf-8?B?TTBhWThoQTl5M0RKNHEvRVJ1c3FMZmM4aHBGT2lzQ2c1UERxNVE0NTBBMzAw?= =?utf-8?B?TnpWWXJUeDJkTUdKb3pWaEJwSjl3UlpNTDN2eXQ5S0JnTjdKOHcrNzU2UThw?= =?utf-8?B?azJLdXhYSFNkcmVEakVDMTIrMXJ2WEVxam5uZExybDJYN0tweW5OcjZnNjdW?= =?utf-8?B?UVcwVXJPM1VKRXJVdy9ldnlNMDBPOElHTEdad0pIUm9Bam54T1JUaVJ5Mzdm?= =?utf-8?B?amRWUjNCdVlFVEY0aXUrZXRINHVBRmlLeEhYRllFajlXUXIrQmVGK0lwdHNM?= =?utf-8?B?b25sTFMxd3lEUjB2KzBCMHJCZGNscUx2d21zYW4rcUFzd3JPakdCMDNoOE15?= =?utf-8?B?bnA3SHdlMmhjbm0xMTJWcUZseU1ocDlkZzAyanlENElxc0FrUDczUVFIR3VJ?= =?utf-8?B?Z2ttamhEUWl3ejVXelcrb2lKU2E0dGlDTWQwS0pHaXYrandCSXdzUGJlOXd5?= =?utf-8?B?UDBPYUUyWWJ3NVZwMTlCQ3c0MEx1UGtzY2M3TUYybkY0RStwWkEyNTdTbDll?= =?utf-8?B?SEE9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: c4f78723-d73e-4bf3-0b74-08db73357860 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6502.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2023 15:29:29.4590 (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: rwtW+Lagfu0kB3dWoO8UE4iDcQHgouxmLx+9mbMOJBAsF9i12WBymvcvgLz++tk9lRczak3nKZUYADbaqfow+yGjzJd3cO2OmjMIZOXoNw0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4545 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: > This patch supports rte_memarea_alloc() and rte_memarea_free() API. > > Signed-off-by: Chengwen Feng > Reviewed-by: Dongdong Liu > Acked-by: Morten Brørup > --- General note: this patchset could benefit from a bit more comments. I don't suggest commenting every line, but at least more comments denoting various logical steps (like you have in `rte_memarea_free`) would be nice to have. > #include > #include > @@ -88,6 +90,8 @@ memarea_alloc_area(const struct rte_memarea_param *init) > init->numa_socket); > else if (init->source == RTE_MEMAREA_SOURCE_LIBC) > ptr = memarea_alloc_from_libc(init->total_sz); > + else if (init->source == RTE_MEMAREA_SOURCE_MEMAREA) > + ptr = rte_memarea_alloc(init->src_ma, init->total_sz); Why `if` not `switch`? > > return ptr; > } > @@ -99,6 +103,8 @@ memarea_free_area(const struct rte_memarea_param *init, void *ptr) > rte_free(ptr); > else if (init->source == RTE_MEMAREA_SOURCE_LIBC) > free(ptr); > + else if (init->source == RTE_MEMAREA_SOURCE_MEMAREA) > + rte_memarea_free(init->src_ma, ptr); Similarly here: why `if` not `switch`? > +static inline void > +memarea_add_node(struct rte_memarea *ma, struct memarea_objhdr *hdr, size_t alloc_sz) > +{ > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + struct memarea_objtlr *cur_tlr; > +#endif > + struct memarea_objhdr *new_hdr; > + > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + cur_tlr = RTE_PTR_ADD(hdr, sizeof(struct memarea_objhdr) + alloc_sz); > + cur_tlr->cookie = MEMAREA_OBJECT_TRAILER_COOKIE; > + new_hdr = RTE_PTR_ADD(cur_tlr, sizeof(struct memarea_objtlr)); > + new_hdr->cookie = MEMAREA_OBJECT_HEADER_AVAILABLE_COOKIE; > +#else > + new_hdr = RTE_PTR_ADD(hdr, sizeof(struct memarea_objhdr) + alloc_sz); > +#endif > + TAILQ_INSERT_AFTER(&ma->obj_list, hdr, new_hdr, obj_next); > + TAILQ_INSERT_AFTER(&ma->avail_list, hdr, new_hdr, avail_next); > +} It seems to me that this function isn't "adding" node but rather is splitting the `hdr` into two nodes. This is nitpicking, but I feel like this part could be clearer semantically (splitting the function, adding comments, some other way...). > + > +void * > +rte_memarea_alloc(struct rte_memarea *ma, size_t size) > +{ > + size_t align_sz = RTE_ALIGN(size, MEMAREA_OBJECT_SIZE_ALIGN); > + struct memarea_objhdr *hdr; > + size_t avail_sz; > + void *ptr = NULL; > + > + if (unlikely(ma == NULL || size == 0 || align_sz < size)) > + return ptr; It would be nice if API also set rte_errno to indicate what kind of error has happened. > + > + memarea_lock(ma); > + TAILQ_FOREACH(hdr, &ma->avail_list, avail_next) { > + memarea_check_cookie(ma, hdr, 0); > + avail_sz = MEMAREA_OBJECT_GET_SIZE(hdr); > + if (avail_sz < align_sz) > + continue; > + if (memarea_whether_add_node(avail_sz, align_sz)) > + memarea_add_node(ma, hdr, align_sz); I didn't get this at first, which means it needs comments :) Specifically, it seems to me that we're only "adding" a node when we can comfortably split it. So, in addition to comments documenting the above, perhaps the above functions should also be called differently? Like `memarea_can_split()` and `memarea_split`? IMO it'd communicate the intent better (unless I misunderstood the intent, that is!). > + TAILQ_REMOVE(&ma->avail_list, hdr, avail_next); > + MEMAREA_OBJECT_MARK_ALLOCATED(hdr); > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + hdr->cookie = MEMAREA_OBJECT_HEADER_ALLOCATED_COOKIE; > +#endif > + ptr = RTE_PTR_ADD(hdr, sizeof(struct memarea_objhdr)); > + break; > + } > + memarea_unlock(ma); > + > + return ptr; It seems that it's possible to reach the end of the loop and return NULL as `ptr`, without any error. I would suggest setting rte_errno to `ENOMEM` initially, and clearing it when we find a suitable element. > +} > + > +static inline void > +memarea_merge_node(struct rte_memarea *ma, struct memarea_objhdr *curr, > + struct memarea_objhdr *next) > +{ > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + struct memarea_objtlr *tlr; > +#endif > + RTE_SET_USED(curr); > + TAILQ_REMOVE(&ma->obj_list, next, obj_next); > + TAILQ_REMOVE(&ma->avail_list, next, avail_next); > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + next->cookie = 0; > + tlr = RTE_PTR_SUB(next, sizeof(struct memarea_objtlr)); > + tlr->cookie = 0; > +#endif > +} > + > +void > +rte_memarea_free(struct rte_memarea *ma, void *ptr) > +{ > + struct memarea_objhdr *hdr, *prev, *next; > + > + if (unlikely(ma == NULL || ptr == NULL)) > + return; > + > + hdr = RTE_PTR_SUB(ptr, sizeof(struct memarea_objhdr)); > + if (unlikely(!MEMAREA_OBJECT_IS_ALLOCATED(hdr))) { Here and above - I question the value of using `unlikely` here. Are there any numbers to prove these are useful? > + RTE_MEMAREA_LOG(ERR, "detect invalid object in %s!", ma->init.name); > + return; > + } > + memarea_check_cookie(ma, hdr, 1); > + > + memarea_lock(ma); > + > + /** 1st: add to avail list. */ > +#ifdef RTE_LIBRTE_MEMAREA_DEBUG > + hdr->cookie = MEMAREA_OBJECT_HEADER_AVAILABLE_COOKIE; > +#endif > + TAILQ_INSERT_HEAD(&ma->avail_list, hdr, avail_next); > + > + /** 2nd: merge if previous object is avail. */ > + prev = TAILQ_PREV(hdr, memarea_objhdr_list, obj_next); > + if (prev != NULL && !MEMAREA_OBJECT_IS_ALLOCATED(prev)) { > + memarea_check_cookie(ma, prev, 0); > + memarea_merge_node(ma, prev, hdr); > + hdr = prev; > + } > + > + /** 3rd: merge if next object is avail. */ > + next = TAILQ_NEXT(hdr, obj_next); > + if (next != NULL && !MEMAREA_OBJECT_IS_ALLOCATED(next)) { > + memarea_check_cookie(ma, next, 0); > + memarea_merge_node(ma, hdr, next); > + } > + > + memarea_unlock(ma); > +} This function is an example of how I would like to see other functions: good comments to denote logical blocks, clear and concise. -- Thanks, Anatoly