DPDK patches and discussions
 help / color / mirror / Atom feed
From: Sarosh Arif <sarosh.arif@emumba.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] testpmd: add speed capability in device info
Date: Mon, 21 Sep 2020 16:22:47 +0500	[thread overview]
Message-ID: <CABoZmYPJF7-xHEXTMFJ2PsKzLry8h2NM0hzp5dZruendcrr-EA@mail.gmail.com> (raw)
In-Reply-To: <84032779-1b74-0aed-2a49-9a0315c7b819@intel.com>

On Thu, Sep 17, 2020 at 8:56 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> On 9/4/2020 7:23 AM, Sarosh Arif wrote:
> > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> > index 30bee3324..8824ad174 100644
> > --- a/app/test-pmd/config.c
> > +++ b/app/test-pmd/config.c
> > @@ -518,6 +518,7 @@ device_infos_display(const char *identifier)
> >       struct rte_device *dev;
> >       struct rte_devargs da;
> >       portid_t port_id;
> > +     struct rte_eth_dev_info dev_info;
> >       char devstr[128];
>
> This is for the testpmd command "show device info <identifier>|all",
> not sure speed capabilities really fits the device info display.
>
> "show port info <port_id>|all" command may be better fit, but before
> that is there a specific need to see the speed capabilities of a port,
> it may help figuring out right place.
In bug 496 on bugzilla, it is requested to display speed capabilities
of a device,
in order to create a test to confirm the correct speed capabilities of a device.
Since speed_capa is property of the device it should be printed under
show device info.


>
> >
> >       memset(&da, 0, sizeof(da));
> > @@ -569,6 +570,90 @@ device_infos_display(const char *identifier)
> >                                                     &mac_addr);
> >                               rte_eth_dev_get_name_by_port(port_id, name);
> >                               printf("\n\tDevice name: %s", name);
> > +                             rte_eth_dev_info_get(port_id, &dev_info);
> > +                             switch (dev_info.speed_capa) {
> > +                             case ETH_LINK_SPEED_AUTONEG:
> > +                                     printf("\n\tDevice speed capability: %s",
> > +                                                     "Autonegotiate (all speeds)");
> > +                                     break;
> > +                             case ETH_LINK_SPEED_FIXED:
> > +                                     printf("\n\tDevice speed capability: %s",
> > +                                                     "Disable autonegotiate (fixed speed)");
> > +                                     break;
> > +                             case ETH_LINK_SPEED_10M_HD ...
> > +                                             ETH_LINK_SPEED_10M-1:
>
> Why ranges are used, there can't be any value in between?
>
It's a bit map so multiple bits can be one at a time resulting in
values in between.
> Also case range is not part of starndard, may be good to avoid for
> portability, like the case -pendantic is used etc..
I will submit v2 without using case range.
>
>
> > +                                     printf("\n\tDevice speed capability: %s",
> > +                                                     "10 Mbps half-duplex");
> > +                                     break;
>
> You should not break. 'speed_capa' is list of speeds that device
> supports, so it won't be a single value, that is why breaking after
> first hit is wrong.
I will correct this in v2
>
> Can you please confirm you intentions is not to display link speed, but
> "speed capability"? Btw, link speed is already displayed in "show port
> info ..."
The intention is to be able create a test to confirm the correct speed
capabilities of a device.

>
> > +                             case ETH_LINK_SPEED_10M ...
> > +                                             ETH_LINK_SPEED_100M_HD-1:
> > +                                     printf("\n\tDevice speed capability: %s",
> > +                                                     "10 Mbps full-duplex");
>
> Also no need to be this verbose, since there will be multiple values,
> this makes to much noise, instead can be an list of speeds in single line.
Okay
>

  reply	other threads:[~2020-09-21 11:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-04  6:23 Sarosh Arif
2020-09-08  8:36 ` Sarosh Arif
2020-09-08 11:55   ` Ferruh Yigit
2020-09-17 15:56 ` Ferruh Yigit
2020-09-21 11:22   ` Sarosh Arif [this message]
2020-09-28 10:01 ` [dpdk-dev] [PATCH v2] " Sarosh Arif
2020-10-04  8:51   ` Asaf Penso
2020-10-07 15:30     ` Ferruh Yigit
2020-10-08 11:49   ` [dpdk-dev] [PATCH v3] " Sarosh Arif
2020-10-08 16:14     ` Ferruh Yigit
2020-10-08 18:11   ` [dpdk-dev] [PATCH v4] " Sarosh Arif
2020-10-08 18:25   ` [dpdk-dev] [PATCH v5] " Sarosh Arif
2020-10-09  9:27     ` Ferruh Yigit
2020-10-09 11:53       ` Ferruh Yigit

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=CABoZmYPJF7-xHEXTMFJ2PsKzLry8h2NM0hzp5dZruendcrr-EA@mail.gmail.com \
    --to=sarosh.arif@emumba.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    /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).