DPDK patches and discussions
 help / color / mirror / Atom feed
From: Subendu Santra <subendu@arista.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	dev@dpdk.org, hemant.agrawal@nxp.com, maryam.tahhan@intel.com,
	reshma.pattan@intel.com,  Sriram Rajagopalan <sriramr@arista.com>
Subject: Re: [dpdk-dev] [PATCH v3 6/7] app/proc-info: provide way to request info on owned ports
Date: Tue, 10 May 2022 14:39:05 +0530	[thread overview]
Message-ID: <CAEc=+Onq9N=sTsUi6d9D0NmMUnw3+FSFDHgAa0r-ztFRT8Eb3w@mail.gmail.com> (raw)
In-Reply-To: <20220504104833.5e021a12@shemminger-XPS-13-9360>

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

Hi Stephen, Thomas,

On a related note w.r.to commit 1dd6cffb6571f816d5a0d1fd620f43532240b40b
(app/procinfo: provide way to request info on owned ports), we see this
change:

-static uint32_t enabled_port_mask;
> +static unsigned long enabled_port_mask;


While this is ok for 64-bit machines, where unsigned long is 64-bit, on
32-bit machines unsigned long is 32-bits.
Should we change this to unsigned long long which is guaranteed to be
64-bits on both architectures?

Specifying a mask of 0xffffffffffffffff on 32-bit platforms results in
error:

> + sudo /usr/share/dpdk/tools/dpdk-procinfo -- --show-port -p
> 0xffffffffffffffff
> Invalid portmask '0xffffffffffffffff'


We have a script that runs periodically and it uses the dpdk-procinfo tool
to collect information about the ports.
It will be ideal to use the same portmask in the script irrespective of the
platform it runs on.

Kindly share your thoughts on this.

Regards,
Subendu.



On Wed, May 4, 2022 at 11:18 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Tue, 03 May 2022 10:47:58 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 24/04/2022 07:34, Subendu Santra:
> > > Hi Stephen,
> > >
> > > We were going through the patch set:
> https://inbox.dpdk.org/dev/20200715212228.28010-7-stephen@networkplumber.org/
> and hoping to get clarification on the behaviour if post mask is not
> specified in the input to `dpdk-proc-info` tool.
> > >
> > > Specifically, In PATCH v3 6/7, we see this:
> > > +   /* If no port mask was specified, one will be provided */
> > > +   if (enabled_port_mask == 0) {
> > > +           RTE_ETH_FOREACH_DEV(i) {
> > > +                   enabled_port_mask |= 1u << i;
> > >
> > > However, in PATCH v4 8/8, we see this:
> > > +   /* If no port mask was specified, then show non-owned ports */
> > > +   if (enabled_port_mask == 0) {
> > > +           RTE_ETH_FOREACH_DEV(i)
> > > +                   enabled_port_mask = 1ul << i;
> > > +   }
> > >
> > > Was there any specific reason to show just the last non-owned port in
> case the port mask was not specified?
> > > Should we show all non-owned ports in case the user doesn’t specify
> any port mask?
> >
> > It looks like a bug. It should be |=
> > Feel free to send a fix.
> >
> >
>
> Agree. Thats a bug.
>
> It would be good to have a "show all ports" flag to proc-info.
> To show all ports including owned.
>

[-- Attachment #2: Type: text/html, Size: 4213 bytes --]

  reply	other threads:[~2022-05-10  9:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-24  5:34 Subendu Santra
2022-05-03  5:29 ` Subendu Santra
2022-05-03  8:47 ` Thomas Monjalon
2022-05-04 17:48   ` Stephen Hemminger
2022-05-10  9:09     ` Subendu Santra [this message]
2022-05-10 20:02       ` Stephen Hemminger
2022-05-11  7:36         ` Subendu Santra
  -- strict thread matches above, loose matches on Subject: below --
2020-05-06 19:37 [dpdk-dev] [PATCH 0/7] proc-info enhancements Stephen Hemminger
2020-07-15 21:22 ` [dpdk-dev] [PATCH v3 0/7] app/proc-info enhancments Stephen Hemminger
2020-07-15 21:22   ` [dpdk-dev] [PATCH v3 6/7] app/proc-info: provide way to request info on owned ports Stephen Hemminger
2020-07-17 15:01     ` Thomas Monjalon
2020-07-21 17:05       ` Stephen Hemminger
2020-07-21 17:08         ` Thomas Monjalon
2020-07-21 17:37           ` Stephen Hemminger

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='CAEc=+Onq9N=sTsUi6d9D0NmMUnw3+FSFDHgAa0r-ztFRT8Eb3w@mail.gmail.com' \
    --to=subendu@arista.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=maryam.tahhan@intel.com \
    --cc=reshma.pattan@intel.com \
    --cc=sriramr@arista.com \
    --cc=stephen@networkplumber.org \
    --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).