app/testpmd: dump private info in 'show port info'
Checks
Commit Message
This patch adds dump private info in 'show port info [port_id]' cmd.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
app/test-pmd/config.c | 5 +++++
1 file changed, 5 insertions(+)
Comments
On 3/15/2023 8:03 AM, Chengwen Feng wrote:
> This patch adds dump private info in 'show port info [port_id]' cmd.
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Aman Singh <aman.deep.singh@intel.com>
> ---
> app/test-pmd/config.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index 018536f177..ab5199f223 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -938,6 +938,11 @@ port_infos_display(portid_t port_id)
> printf("unknown\n");
> break;
> }
> + printf("Device private info:\n");
> + ret = rte_eth_dev_priv_dump(port_id, stdout);
> + if (ret < 0)
> + fprintf(stderr, " Failed to dump private info with error (%d): %s\n",
> + ret, strerror(-ret));
> }
>
> void
On 3/15/2023 2:33 AM, Chengwen Feng wrote:
> This patch adds dump private info in 'show port info [port_id]' cmd.
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
> app/test-pmd/config.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index 018536f177..ab5199f223 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -938,6 +938,11 @@ port_infos_display(portid_t port_id)
> printf("unknown\n");
> break;
> }
> + printf("Device private info:\n");
Not all drivers support device private info, above should print only
when it is supported.
> + ret = rte_eth_dev_priv_dump(port_id, stdout);
> + if (ret < 0)
> + fprintf(stderr, " Failed to dump private info with error (%d): %s\n",
> + ret, strerror(-ret));
Similarly, if driver doesn't support '.eth_dev_priv_dump' it shouldn't
print the above error log.
On 2023/3/15 18:12, Ferruh Yigit wrote:
> On 3/15/2023 2:33 AM, Chengwen Feng wrote:
>> This patch adds dump private info in 'show port info [port_id]' cmd.
>>
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>> ---
>> app/test-pmd/config.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
>> index 018536f177..ab5199f223 100644
>> --- a/app/test-pmd/config.c
>> +++ b/app/test-pmd/config.c
>> @@ -938,6 +938,11 @@ port_infos_display(portid_t port_id)
>> printf("unknown\n");
>> break;
>> }
>> + printf("Device private info:\n");
>
> Not all drivers support device private info, above should print only
> when it is supported.
>
>> + ret = rte_eth_dev_priv_dump(port_id, stdout);
>> + if (ret < 0)
>> + fprintf(stderr, " Failed to dump private info with error (%d): %s\n",
>> + ret, strerror(-ret));
>
> Similarly, if driver doesn't support '.eth_dev_priv_dump' it shouldn't
> print the above error log.
>
Because we have no API to know the PMD whether impl specific ops, we could only knowed by invoking.
Except above impl, I also consider the other two:
1. just invoke rte_eth_dev_priv_dump without previous printf("Device private info") and later error printf.
and I think people may curious about the extra output without a prompt just like "Device private info".
2. use fmemopen (the below code), this way will perfect process the PMD which not imp ops.
FILE *f = fmemopen(buf, max-size(e.g. 128KB));
ret = rte_eth_dev_priv_dump(port_id, f);
if (ret == 0) {
printf("Device private info:\n");
printf("%s", buf);
}
But the windows platform don't support fmemopen.
Hope for more feedback.
Thanks
> .
>
16/03/2023 02:10, fengchengwen:
> On 2023/3/15 18:12, Ferruh Yigit wrote:
> > On 3/15/2023 2:33 AM, Chengwen Feng wrote:
> >> This patch adds dump private info in 'show port info [port_id]' cmd.
> >>
> >> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >> ---
> >> app/test-pmd/config.c | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> >> index 018536f177..ab5199f223 100644
> >> --- a/app/test-pmd/config.c
> >> +++ b/app/test-pmd/config.c
> >> @@ -938,6 +938,11 @@ port_infos_display(portid_t port_id)
> >> printf("unknown\n");
> >> break;
> >> }
> >> + printf("Device private info:\n");
> >
> > Not all drivers support device private info, above should print only
> > when it is supported.
> >
> >> + ret = rte_eth_dev_priv_dump(port_id, stdout);
> >> + if (ret < 0)
> >> + fprintf(stderr, " Failed to dump private info with error (%d): %s\n",
> >> + ret, strerror(-ret));
> >
> > Similarly, if driver doesn't support '.eth_dev_priv_dump' it shouldn't
> > print the above error log.
> >
>
> Because we have no API to know the PMD whether impl specific ops, we could only knowed by invoking.
> Except above impl, I also consider the other two:
> 1. just invoke rte_eth_dev_priv_dump without previous printf("Device private info") and later error printf.
> and I think people may curious about the extra output without a prompt just like "Device private info".
You can print the error only if the return is not ENOTSUP.
You can keep the first print and then print "none" if ENOTSUP.
> 2. use fmemopen (the below code), this way will perfect process the PMD which not imp ops.
> FILE *f = fmemopen(buf, max-size(e.g. 128KB));
> ret = rte_eth_dev_priv_dump(port_id, f);
> if (ret == 0) {
> printf("Device private info:\n");
> printf("%s", buf);
> }
> But the windows platform don't support fmemopen.
That's also a good solution but we need to support Windows.
On Thu, Mar 16, 2023 at 4:11 AM fengchengwen <fengchengwen@huawei.com> wrote:
> Because we have no API to know the PMD whether impl specific ops, we could only knowed by invoking.
> Except above impl, I also consider the other two:
> 1. just invoke rte_eth_dev_priv_dump without previous printf("Device private info") and later error printf.
> and I think people may curious about the extra output without a prompt just like "Device private info".
> 2. use fmemopen (the below code), this way will perfect process the PMD which not imp ops.
> FILE *f = fmemopen(buf, max-size(e.g. 128KB));
> ret = rte_eth_dev_priv_dump(port_id, f);
> if (ret == 0) {
> printf("Device private info:\n");
> printf("%s", buf);
> }
> But the windows platform don't support fmemopen.
>
> Hope for more feedback.
What if rte_eth_dev_priv_dump() was a documented no-op when "f == NULL"?
This can be implemented in ethdev layer:
1) if not implemented, return ENOTSUP
2) if f == NULL, return 0
3) else call PMD
Technically, even now a null device handle can be used, but this is
cumbersome and wastes resources for running the API twice.
On 2023/3/16 15:55, Thomas Monjalon wrote:
> 16/03/2023 02:10, fengchengwen:
>> On 2023/3/15 18:12, Ferruh Yigit wrote:
>>> On 3/15/2023 2:33 AM, Chengwen Feng wrote:
>>>> This patch adds dump private info in 'show port info [port_id]' cmd.
>>>>
>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>> ---
>>>> app/test-pmd/config.c | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
>>>> index 018536f177..ab5199f223 100644
>>>> --- a/app/test-pmd/config.c
>>>> +++ b/app/test-pmd/config.c
>>>> @@ -938,6 +938,11 @@ port_infos_display(portid_t port_id)
>>>> printf("unknown\n");
>>>> break;
>>>> }
>>>> + printf("Device private info:\n");
>>>
>>> Not all drivers support device private info, above should print only
>>> when it is supported.
>>>
>>>> + ret = rte_eth_dev_priv_dump(port_id, stdout);
>>>> + if (ret < 0)
>>>> + fprintf(stderr, " Failed to dump private info with error (%d): %s\n",
>>>> + ret, strerror(-ret));
>>>
>>> Similarly, if driver doesn't support '.eth_dev_priv_dump' it shouldn't
>>> print the above error log.
>>>
>>
>> Because we have no API to know the PMD whether impl specific ops, we could only knowed by invoking.
>> Except above impl, I also consider the other two:
>> 1. just invoke rte_eth_dev_priv_dump without previous printf("Device private info") and later error printf.
>> and I think people may curious about the extra output without a prompt just like "Device private info".
>
> You can print the error only if the return is not ENOTSUP.
> You can keep the first print and then print "none" if ENOTSUP.
Good idea, fix in v2, thanks.
>
>> 2. use fmemopen (the below code), this way will perfect process the PMD which not imp ops.
>> FILE *f = fmemopen(buf, max-size(e.g. 128KB));
>> ret = rte_eth_dev_priv_dump(port_id, f);
>> if (ret == 0) {
>> printf("Device private info:\n");
>> printf("%s", buf);
>> }
>> But the windows platform don't support fmemopen.
>
> That's also a good solution but we need to support Windows.
>
>
>
> .
>
On 2023/3/16 17:19, Dmitry Kozlyuk wrote:
> On Thu, Mar 16, 2023 at 4:11 AM fengchengwen <fengchengwen@huawei.com> wrote:
>> Because we have no API to know the PMD whether impl specific ops, we could only knowed by invoking.
>> Except above impl, I also consider the other two:
>> 1. just invoke rte_eth_dev_priv_dump without previous printf("Device private info") and later error printf.
>> and I think people may curious about the extra output without a prompt just like "Device private info".
>> 2. use fmemopen (the below code), this way will perfect process the PMD which not imp ops.
>> FILE *f = fmemopen(buf, max-size(e.g. 128KB));
>> ret = rte_eth_dev_priv_dump(port_id, f);
>> if (ret == 0) {
>> printf("Device private info:\n");
>> printf("%s", buf);
>> }
>> But the windows platform don't support fmemopen.
>>
>> Hope for more feedback.
>
> What if rte_eth_dev_priv_dump() was a documented no-op when "f == NULL"?
> This can be implemented in ethdev layer:
> 1) if not implemented, return ENOTSUP
> 2) if f == NULL, return 0
> 3) else call PMD
> Technically, even now a null device handle can be used, but this is
> cumbersome and wastes resources for running the API twice.
Thanks your advise.
V2 has sent which adopt Thomas's comment:
printf("Device private info:\n");
ret = rte_eth_dev_priv_dump(port_id, stdout);
if (ret == -ENOTSUP)
printf(" none\n");
else if (ret < 0)
fprintf(stderr, " Failed to dump private info with error (%d): %s\n",
ret, strerror(-ret));
which seem simpler.
> .
>
On 3/16/2023I 9:19 AM, Dmitry Kozlyuk wrote:
> On Thu, Mar 16, 2023 at 4:11 AM fengchengwen <fengchengwen@huawei.com> wrote:
>> Because we have no API to know the PMD whether impl specific ops, we could only knowed by invoking.
>> Except above impl, I also consider the other two:
>> 1. just invoke rte_eth_dev_priv_dump without previous printf("Device private info") and later error printf.
>> and I think people may curious about the extra output without a prompt just like "Device private info".
>> 2. use fmemopen (the below code), this way will perfect process the PMD which not imp ops.
>> FILE *f = fmemopen(buf, max-size(e.g. 128KB));
>> ret = rte_eth_dev_priv_dump(port_id, f);
>> if (ret == 0) {
>> printf("Device private info:\n");
>> printf("%s", buf);
>> }
>> But the windows platform don't support fmemopen.
>>
>> Hope for more feedback.
>
> What if rte_eth_dev_priv_dump() was a documented no-op when "f == NULL"?
> This can be implemented in ethdev layer:
> 1) if not implemented, return ENOTSUP
> 2) if f == NULL, return 0
> 3) else call PMD
> Technically, even now a null device handle can be used, but this is
> cumbersome and wastes resources for running the API twice.
Not sure about to overload "f == NULL" condition to detect the feature
support.
It may be good to have a generic way to detect the support.
One way is to add new set of APIs just to test the dev_ops, and return
boolean like:
'bool rte_eth_dev_is_priv_dump(uint16_t port_id);'
Another option can be introducing an enum, each enum item can represent
a dev_ops and a single API can be used to detect the support. This
requires more maintenance for long term, as app needs to know more,
not sure if I like this.
If there is no objection to add new APIs, I can own the task, to have
APIs like:
'bool rte_eth_dev_is_xxx(uint16_t port_id);'
16/03/2023 11:46, Ferruh Yigit:
> On 3/16/2023I 9:19 AM, Dmitry Kozlyuk wrote:
> > On Thu, Mar 16, 2023 at 4:11 AM fengchengwen <fengchengwen@huawei.com> wrote:
> >> Because we have no API to know the PMD whether impl specific ops, we could only knowed by invoking.
> >> Except above impl, I also consider the other two:
> >> 1. just invoke rte_eth_dev_priv_dump without previous printf("Device private info") and later error printf.
> >> and I think people may curious about the extra output without a prompt just like "Device private info".
> >> 2. use fmemopen (the below code), this way will perfect process the PMD which not imp ops.
> >> FILE *f = fmemopen(buf, max-size(e.g. 128KB));
> >> ret = rte_eth_dev_priv_dump(port_id, f);
> >> if (ret == 0) {
> >> printf("Device private info:\n");
> >> printf("%s", buf);
> >> }
> >> But the windows platform don't support fmemopen.
> >>
> >> Hope for more feedback.
> >
> > What if rte_eth_dev_priv_dump() was a documented no-op when "f == NULL"?
> > This can be implemented in ethdev layer:
> > 1) if not implemented, return ENOTSUP
> > 2) if f == NULL, return 0
> > 3) else call PMD
> > Technically, even now a null device handle can be used, but this is
> > cumbersome and wastes resources for running the API twice.
>
>
> Not sure about to overload "f == NULL" condition to detect the feature
> support.
>
> It may be good to have a generic way to detect the support.
>
> One way is to add new set of APIs just to test the dev_ops, and return
> boolean like:
> 'bool rte_eth_dev_is_priv_dump(uint16_t port_id);'
>
>
> Another option can be introducing an enum, each enum item can represent
> a dev_ops and a single API can be used to detect the support. This
> requires more maintenance for long term, as app needs to know more,
> not sure if I like this.
>
>
> If there is no objection to add new APIs, I can own the task, to have
> APIs like:
> 'bool rte_eth_dev_is_xxx(uint16_t port_id);'
That's a debug function, so I don't think we need to know in advance
whether it will print something or not.
Returning ENOTSUP should be enough in my opinion.
@@ -938,6 +938,11 @@ port_infos_display(portid_t port_id)
printf("unknown\n");
break;
}
+ printf("Device private info:\n");
+ ret = rte_eth_dev_priv_dump(port_id, stdout);
+ if (ret < 0)
+ fprintf(stderr, " Failed to dump private info with error (%d): %s\n",
+ ret, strerror(-ret));
}
void