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 6CD93A00C3; Tue, 20 Sep 2022 14:06:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1550540DFB; Tue, 20 Sep 2022 14:06:50 +0200 (CEST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id 63EC64069B for ; Tue, 20 Sep 2022 14:06:48 +0200 (CEST) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.53]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4MX0ZM1vgszHp88; Tue, 20 Sep 2022 20:03:55 +0800 (CST) Received: from [10.34.207.201] (10.34.207.201) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 20 Sep 2022 20:06:03 +0800 Message-ID: Date: Tue, 20 Sep 2022 20:06:03 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH 1/8] memarea: introduce memory area library To: Dmitry Kozlyuk CC: , , , References: <20220721044648.6817-1-fengchengwen@huawei.com> <20220920034643.55476-1-fengchengwen@huawei.com> <20220920034643.55476-2-fengchengwen@huawei.com> <20220920143013.7624f36d@sovereign> Content-Language: en-US From: fengchengwen In-Reply-To: <20220920143013.7624f36d@sovereign> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.34.207.201] X-ClientProxiedBy: dggpeml500003.china.huawei.com (7.185.36.200) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected 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 Hi Dmitry, On 2022/9/20 19:30, Dmitry Kozlyuk wrote: > 2022-09-20 03:46 (UTC+0000), Chengwen Feng: >> 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 features are as follows: >> a) it facilitate alloc and free of memory with low overhead. > Yet, the overhead is 64B per element, just like rte_malloc. > >> b) it provides refcnt feature which could be useful in some scenes. > Are you sure refcnt should be in this library? > I've expressed my concerns here: > > https://inbox.dpdk.org/dev/CAEYuUWBpC-9dCqKJ0LZi6RkCUwyeYEghLRBMBUBtUx4Ljg+pAQ@mail.gmail.com > > There are more unanswered questions in that mail, > it would be good to clarify them before reviewing these patches > in order to understand all the intentions. Sorry to forgot reply it. We have the following scene which used refcnt:     nic-rx  ->  decoder ->  process                                    |                                   ->  recording as above show, the process and recording module both use the decoder's output, the are just reader. so in this case, the refcnt is useful. > >> +static int >> +memarea_check_param(const struct rte_memarea_param *init) >> +{ >> + size_t len; >> + >> + len = strnlen(init->name, RTE_MEMAREA_NAMESIZE); >> + if (len == 0 || len >= RTE_MEMAREA_NAMESIZE) { >> + RTE_LOG(ERR, MEMAREA, "memarea name invalid!\n"); >> + return -EINVAL; >> + } > Please check init->name == NULL first. No need checking because name is an array. Maybe I should check init == NULL here. > >> +struct rte_memarea * >> +rte_memarea_create(const struct rte_memarea_param *init) >> +{ > [...] >> + RTE_LOG(ERR, MEMAREA, "malloc memarea management obj fail!\n"); > In all error messages, it would be useful to provide details: > the name of the area, what size was requested, etc. will fix in v2. > >> +/** >> + * Memarea memory source. >> + */ >> +enum rte_memarea_source { >> + /** Memory source comes from system API (e.g. malloc). */ >> + RTE_MEMAREA_SOURCE_SYSTEM_API, >> + /** Memory source comes from user-provided address. */ >> + RTE_MEMAREA_SOURCE_USER_ADDR, >> + /** Memory source comes from user-provided memarea. */ >> + RTE_MEMAREA_SOURCE_USER_MEMAREA, >> + >> + RTE_MEMAREA_SOURCE_BUTT > DPDK enumerations must not include an item to hold the element count, > because it is harmful for ABI (e.g. developers create arrays of this size > and when a new item is added in a new DPDK version, the array overflows). > > If it's supposed to mean "the end of item list", > the proper word would be "last" or "max" BTW :) will fix in v2 > >> +}; >> + >> +struct rte_memarea { >> + void *private_data; /**< private management data pointer. */ >> +}; > Jerin and Stephen suggested to make the structure opaque, > i.e. only declare the struct and define it privately. > It would reduce ABI and simplify allocation. > Any justification to expose it? do you mean the rte_memarea just void * ? it just (void *)(memarea_private *)priv ? It's another popular type to impl ABI compatiable. It's more simpler, will fix in v2