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 7F1074387B; Wed, 10 Jan 2024 02:38:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0D88440298; Wed, 10 Jan 2024 02:38:21 +0100 (CET) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 0E79E40269 for ; Wed, 10 Jan 2024 02:38:19 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4T8r4q755rzvQgZ; Wed, 10 Jan 2024 09:36:59 +0800 (CST) Received: from dggpeml500024.china.huawei.com (unknown [7.185.36.10]) by mail.maildlp.com (Postfix) with ESMTPS id AF1AF1404F1; Wed, 10 Jan 2024 09:38:16 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) 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.2507.35; Wed, 10 Jan 2024 09:38:16 +0800 Subject: Re: [PATCH] ethdev: add dump regs for telemetry To: Ferruh Yigit , Jie Hai , , Thomas Monjalon , Andrew Rybchenko , Bruce Richardson CC: , References: <20231214015650.3738578-1-haijie1@huawei.com> <8632690b-5e85-43fb-9121-a8910074726d@amd.com> <359de0d6-90c4-aaea-f186-574d04a31c2a@huawei.com> <33d1d451-95ea-48fe-a6ec-b86976ba5130@amd.com> From: fengchengwen Message-ID: Date: Wed, 10 Jan 2024 09:38:16 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <33d1d451-95ea-48fe-a6ec-b86976ba5130@amd.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpeml500024.china.huawei.com (7.185.36.10) 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 Ferruh, On 2024/1/10 2:06, Ferruh Yigit wrote: > On 1/9/2024 2:19 AM, Jie Hai wrote: >> On 2023/12/14 20:49, Ferruh Yigit wrote: >>> On 12/14/2023 1:56 AM, Jie Hai wrote: >>>> The ethdev library now registers a telemetry command for >>>> dump regs. >>>> >>>> An example usage is shown below: >>>> --> /ethdev/regs,test >>>> { >>>>    "/ethdev/regs": { >>>>      "regs_offset": 0, >>>>      "regs_length": 3192, >>>>      "regs_width": 4, >>>>      "device_version": "0x1080f00", >>>>      "regs_file": "port_0_regs_test" >>>>    } >>>> } >> >>> >>> Above code writes register data to a file. >>> >>> I am not sure about this kind of usage of telemetry command, that it >>> cause data to be written to a file. >>> >>> My understanding is, telemetry usage is based on what telemetry client >>> receives. >>> What do you think just keep the 'reg_info' fields excluding data to the >>> file? >>> >>> .Hi, Ferruh >> >> I tried to write all register information to telemetry data, >> but gave up because some drivers had too many registers (eg.ixgbe) >> to carry. Therefore, the writing data to file approach is selected. >> >> When we query a register, the register content is the key. >> The information such as the width and length is only auxiliary >> information. If the register data cannot be obtained, the auxiliary >> information is optional. So I don't think register data should be removed. >> >> In my opinion, writing a file is a more appropriate way to do it. >> I wonder if there's a better way. >> >> > > Is there a usecase to get register information from telemetry interface? Among the available tools: 1, ethtool/proc-info: should use multi-process mechanism to connect to the main process 2, telemetry: easier, lighter load, and it don't need re-probe the ethdev in the secondary process, and also cost more resource, like hugepage, cores. >From our users, they prefer use the second 'telemetry', so I think we should move more status-query-points to telemetry. As for this question, I think it's okay to get register info from telemetry. Another question, we have some internal registers, which: 1. Is not suitable expose by xstats, because they may includes configuration 2. Is not suitable expose by dumps, because this dumps is hard to understand (because it only has value). So we plan to add some telemetry points in the driver itself, so we could display them like xstats: "xxxx" : 0x1234 "yyyy" : 0x100 Will the community accept this kind of telemetry points which limit one driver ? Thanks. > > . >