From: Ferruh Yigit <ferruh.yigit@amd.com>
To: fengchengwen <fengchengwen@huawei.com>,
Jie Hai <haijie1@huawei.com>,
dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Bruce Richardson <bruce.richardson@intel.com>
Cc: lihuisong@huawei.com, liudongdong3@huawei.com
Subject: Re: [PATCH] ethdev: add dump regs for telemetry
Date: Wed, 10 Jan 2024 12:15:19 +0000 [thread overview]
Message-ID: <1dfc96a4-9471-4f2a-a835-72da95e6273e@amd.com> (raw)
In-Reply-To: <c4e01687-327c-8f89-bc58-1ec4e464ed0a@huawei.com>
On 1/10/2024 1:38 AM, fengchengwen wrote:
> 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 ?
>
Hi Chengwen,
I see there is a usecase/requirement.
With this patch, even using file, only register values are dumped and
isn't it hard to find value of specific register?
("xxxx" : 0x1234) approach looks better, but instead of making this
telemetry support for specific driver, what about making it in two steps.
First add new dev_ops, (or update existing one), to get registers with
"name: value" format, (in a way to allow empty name), or even perhaps
"name: offset, value" format.
And in second stage add telemetry support around it.
(Name being optional lets us wrap exiting 'get_reg' dev_ops with new one)
When adding dev_ops, it may get an additional 'filter' parameter, to get
only subset of regs, like "mac*" to get regs name staring with "mac",
this may help for the cases there are too many registers you mentioned.
Anyway, we can discuss more about its design, but what do you think
about first having a dev_ops for this?
next prev parent reply other threads:[~2024-01-10 12:15 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 1:56 Jie Hai
2023-12-14 12:49 ` Ferruh Yigit
2024-01-09 2:19 ` Jie Hai
2024-01-09 2:41 ` Jie Hai
2024-01-09 18:06 ` Ferruh Yigit
2024-01-10 1:38 ` fengchengwen
2024-01-10 12:15 ` Ferruh Yigit [this message]
2024-01-10 14:09 ` Thomas Monjalon
2024-01-10 15:48 ` Ferruh Yigit
2024-01-11 1:55 ` fengchengwen
2024-01-11 11:11 ` Ferruh Yigit
2024-01-11 12:43 ` fengchengwen
2024-02-05 10:51 ` [PATCH v2 0/7] support dump reigser names and filter them Jie Hai
2024-02-05 10:51 ` [PATCH v2 1/7] ethdev: support report register names and filter Jie Hai
2024-02-07 17:00 ` Ferruh Yigit
2024-02-20 8:43 ` Jie Hai
2024-02-05 10:51 ` [PATCH v2 2/7] ethdev: add telemetry cmd for registers Jie Hai
2024-02-07 17:03 ` Ferruh Yigit
2024-02-22 9:01 ` Jie Hai
2024-02-05 10:51 ` [PATCH v2 3/7] net/hns3: fix dump counter of registers Jie Hai
2024-02-05 10:51 ` [PATCH v2 4/7] net/hns3: remove dump format " Jie Hai
2024-02-05 10:51 ` [PATCH v2 5/7] net/hns3: add names for registers Jie Hai
2024-02-05 10:51 ` [PATCH v2 6/7] net/hns3: support filter directly accessed registers Jie Hai
2024-02-05 10:51 ` [PATCH v2 7/7] net/hns3: support filter dump of registers Jie Hai
2024-02-20 10:58 ` [PATCH v3 0/7] support dump reigser names and filter them Jie Hai
2024-02-20 10:58 ` [PATCH v3 1/7] ethdev: support report register names and filter Jie Hai
2024-02-20 15:09 ` Stephen Hemminger
2024-02-26 2:33 ` Jie Hai
2024-02-20 15:13 ` Stephen Hemminger
2024-02-26 2:41 ` Jie Hai
2024-02-20 15:14 ` Stephen Hemminger
2024-02-26 2:57 ` Jie Hai
2024-02-20 15:14 ` Stephen Hemminger
2024-02-26 2:33 ` Jie Hai
2024-02-20 10:58 ` [PATCH v3 2/7] ethdev: add telemetry cmd for registers Jie Hai
2024-02-20 10:58 ` [PATCH v3 3/7] net/hns3: fix dump counter of registers Jie Hai
2024-02-20 10:58 ` [PATCH v3 4/7] net/hns3: remove dump format " Jie Hai
2024-02-20 10:58 ` [PATCH v3 5/7] net/hns3: add names for registers Jie Hai
2024-02-20 10:58 ` [PATCH v3 6/7] net/hns3: support filter directly accessed registers Jie Hai
2024-02-20 10:58 ` [PATCH v3 7/7] net/hns3: support filter dump of registers Jie Hai
2024-02-26 3:07 ` [PATCH v4 0/7] support dump reigser names and filter them Jie Hai
2024-02-26 3:07 ` [PATCH v4 1/7] ethdev: support report register names and filter Jie Hai
2024-02-26 8:01 ` fengchengwen
2024-03-06 7:22 ` Jie Hai
2024-02-29 9:52 ` Thomas Monjalon
2024-03-05 7:45 ` Jie Hai
2024-02-26 3:07 ` [PATCH v4 2/7] ethdev: add telemetry cmd for registers Jie Hai
2024-02-26 9:09 ` fengchengwen
2024-03-06 7:18 ` Jie Hai
2024-02-26 3:07 ` [PATCH v4 3/7] net/hns3: fix dump counter of registers Jie Hai
2024-02-26 3:07 ` [PATCH v4 4/7] net/hns3: remove dump format " Jie Hai
2024-02-26 3:07 ` [PATCH v4 5/7] net/hns3: add names for registers Jie Hai
2024-02-26 3:07 ` [PATCH v4 6/7] net/hns3: support filter directly accessed registers Jie Hai
2024-02-26 3:07 ` [PATCH v4 7/7] net/hns3: support filter dump of registers Jie Hai
2024-03-07 3:02 ` [PATCH v5 0/7] support dump reigser names and filter them Jie Hai
2024-03-07 3:02 ` [PATCH v5 1/7] ethdev: support report register names and filter Jie Hai
2024-03-08 8:09 ` lihuisong (C)
2024-03-07 3:02 ` [PATCH v5 2/7] ethdev: add telemetry cmd for registers Jie Hai
2024-03-08 8:48 ` lihuisong (C)
2024-03-07 3:02 ` [PATCH v5 3/7] net/hns3: fix dump counter of registers Jie Hai
2024-03-08 8:49 ` lihuisong (C)
2024-03-07 3:02 ` [PATCH v5 4/7] net/hns3: remove dump format " Jie Hai
2024-03-08 9:17 ` lihuisong (C)
2024-03-07 3:02 ` [PATCH v5 5/7] net/hns3: add names for registers Jie Hai
2024-03-08 9:41 ` lihuisong (C)
2024-03-08 10:24 ` lihuisong (C)
2024-03-07 3:02 ` [PATCH v5 6/7] net/hns3: support filter directly accessed registers Jie Hai
2024-03-08 9:41 ` lihuisong (C)
2024-03-07 3:02 ` [PATCH v5 7/7] net/hns3: support filter dump of registers Jie Hai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1dfc96a4-9471-4f2a-a835-72da95e6273e@amd.com \
--to=ferruh.yigit@amd.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=haijie1@huawei.com \
--cc=lihuisong@huawei.com \
--cc=liudongdong3@huawei.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).