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 0D10E41BB9; Fri, 3 Feb 2023 08:28:09 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9BFF64067B; Fri, 3 Feb 2023 08:28:08 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 162564021E for ; Fri, 3 Feb 2023 08:28:07 +0100 (CET) Received: from kwepemi500020.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4P7RzM6Z6pzJqrC; Fri, 3 Feb 2023 15:26:23 +0800 (CST) Received: from [10.67.103.42] (10.67.103.42) by kwepemi500020.china.huawei.com (7.221.188.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 3 Feb 2023 15:28:00 +0800 Message-ID: Date: Fri, 3 Feb 2023 15:28:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v3 2/2] ring: add ring info telemetry cmd To: Konstantin Ananyev , , CC: References: <20230117130333.8707-1-haijie1@huawei.com> <20230131022841.10775-1-haijie1@huawei.com> <20230131022841.10775-3-haijie1@huawei.com> From: Jie Hai In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.42] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemi500020.china.huawei.com (7.221.188.8) 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 On 2023/2/2 21:07, Konstantin Ananyev wrote: > 31/01/2023 02:28, Jie Hai пишет: >> This patch supports dump of the info of ring by its name. >> An example using this command is shown below: >> >> --> /ring/info,MP_mb_pool_0 >> { >>    "/ring/info": { >>      "name": "MP_mb_pool_0", >>      "socket": 0, >>      "flags": 0, >>      "producer_type": "MP", >>      "consumer_type": "MC", >>      "size": 262144, >>      "mask": 262143, >>      "capacity": 262143, >>      "used_count": 147173, >>      "consumer_tail": 8283, >>      "consumer_head": 8283, >>      "producer_tail": 155456, >>      "producer_head": 155456, >>      "mz_name": "RG_MP_mb_pool_0", >>      "mz_len": 2097920, >>      "mz_hugepage_sz": 1073741824, >>      "mz_socket_id": 0, >>      "mz_flags": 0 >>    } >> } >> >> Signed-off-by: Jie Hai >> +static int >> +ring_handle_info(const char *cmd __rte_unused, const char *params, >> +        struct rte_tel_data *d) >> +{ >> +    const struct rte_memzone *mz; >> +    struct rte_ring *r; >> + >> +    if (params == NULL || strlen(params) == 0 || >> +        strlen(params) >= RTE_RING_NAMESIZE) >> +        return -EINVAL; >> + >> +    r = rte_ring_lookup(params); >> +    if (r == NULL) >> +        return -EINVAL; > > thanks for the update, but I think there still a potential problem here: > as we release tailq_lock inside ring_lookup() and then grab it after again. > Between these two points we have sort of race condition. > We need a way not to release it in between. > Probably the simplest way - make this function to use ring_walk() > that you introduced in previous patch, instead of ring_lookup(). > Similar to what mempool_handle_info() is doing. > > Thanks for your comments, and I have learned a lot from it. That will be corrected in v4. > .