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 55D07A00BE; Tue, 10 May 2022 11:09:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D950842822; Tue, 10 May 2022 11:09:23 +0200 (CEST) Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by mails.dpdk.org (Postfix) with ESMTP id 826EA4161A for ; Tue, 10 May 2022 11:09:22 +0200 (CEST) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-2f7b815ac06so172274087b3.3 for ; Tue, 10 May 2022 02:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CiAavim5PSZBToP7kBXMQPppT3573bF5Qe4GA3Sc0No=; b=REP4cfjKMj7irwxCO0arzv2W2KluB542cUz+xWuKGl1KY3pbg08dNCof2tLJLY0XLr mGNCzyEFUqz+KlIXX+Myh40PiRb2al04hi4FkStlRCIKK+dV7OT2INjbGGhCIRgH7kdJ 0gx+9mw+4foNyCJBCQwbhSUcElI632t7d+4tOjIRJdjqVU1zCRxEpZZ1qe5Z+AgrpkAY 15ojI/vKcLlk1NLKrotb6si4WvTrAv3NFTgAbe+EpH0x42v3FOKEFw1K7MMkbRuFQqgO MpTc71lNY8QzJzuyKyQJMNt4XqNx4ALFhc+jJiVLNvZFHJNlnteJWWslgqF2acWNSjlk wq9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CiAavim5PSZBToP7kBXMQPppT3573bF5Qe4GA3Sc0No=; b=Zj9DVmVKjavxaAQnvtWNGoqCoAOo89gAzd6T+/xt9o1S9kV2mFDzx4WL4tehiQRSBB Wap76Q7I6eDC8us0da64fXU2+g0m5iuk+ZYuKw5pi4dL8jQ6qU5P2CfbNOQ94rfy+nGQ vyf/b+kiujYRl6WP5r8/vVHksd3xGnNfVfmqGI6iVnz3V3MytCte6cYcpyxu2+XFRslP DA5fKCYvKVKxxxf2ypgrUuRd2dqox+izijrOmxv3I1QxM2SkNbLeRn1ljE5287dQJluv 2UwSlo2Q+7aNEBAnOOCaVE5xzyFwC7C+MSIsTQ1Iughcdf4oJeO2gRgHi20m3LyetpVJ zQQA== X-Gm-Message-State: AOAM530NRq4yRbjEIQwk2kl+/M14uSvInz/uebkB6k2BtZspYwQxagdT MPZA5rUHIV6pej8ztmszM3DqVTdtSku/OhuhX6xT X-Google-Smtp-Source: ABdhPJx5hzY+HW3Zayco2lOREJJL9mQG6eQEyYuPTACCIGoyQ20BCP8IAl374hCdetC1F/dtHvKKArJ/O5Po6AY0NSQ= X-Received: by 2002:a81:15d6:0:b0:2f8:5d5:2b49 with SMTP id 205-20020a8115d6000000b002f805d52b49mr18134229ywv.357.1652173761761; Tue, 10 May 2022 02:09:21 -0700 (PDT) MIME-Version: 1.0 References: <3710E2E2-5CCC-41F3-A12A-E8B6A884CC40@arista.com> <5574950.QJadu78ljV@thomas> <20220504104833.5e021a12@shemminger-XPS-13-9360> In-Reply-To: <20220504104833.5e021a12@shemminger-XPS-13-9360> From: Subendu Santra Date: Tue, 10 May 2022 14:39:05 +0530 Message-ID: Subject: Re: [dpdk-dev] [PATCH v3 6/7] app/proc-info: provide way to request info on owned ports To: Stephen Hemminger Cc: Thomas Monjalon , dev@dpdk.org, hemant.agrawal@nxp.com, maryam.tahhan@intel.com, reshma.pattan@intel.com, Sriram Rajagopalan Content-Type: multipart/alternative; boundary="0000000000002d78bd05dea4aef6" 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 --0000000000002d78bd05dea4aef6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 =3D=3D 0) { > > > + RTE_ETH_FOREACH_DEV(i) { > > > + enabled_port_mask |=3D 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 =3D=3D 0) { > > > + RTE_ETH_FOREACH_DEV(i) > > > + enabled_port_mask =3D 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=E2=80=99t s= pecify > any port mask? > > > > It looks like a bug. It should be |=3D > > 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. > --0000000000002d78bd05dea4aef6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Stephen, Thomas,

On a related n= ote w.r.to=C2=A0commit 1dd6= cffb6571f816d5a0d1fd620f43532240b40b (app/procinfo: provide way to request = info on owned ports), we see this change:

-static uint3= 2_t enabled_port_mask;
+static unsigned = long enabled_port_mask;

While this i= s 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 archit= ectures?

Specifying a mask of 0xffffffffffffffff on 32-bit platforms results in error:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">+ sudo /usr/share/dpdk/tools/dpdk-procinfo -- --show-por= t -p 0xffffffffffffffff
Invalid portmask '0xffffffffffffffff'
<= br>
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 i= t runs on.

Kindly share your thoughts on this.

Regards,
Subendu.

=


On Wed, May 4, 2022 at 11:18 PM Stephen Hemminger <stephen@networkp= lumber.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-s= tephen@networkplumber.org/ and hoping to get clarification on the behav= iour if post mask is not specified in the input to `dpdk-proc-info` tool. > >
> > Specifically, In PATCH v3 6/7, we see this:
> > +=C2=A0 =C2=A0/* If no port mask was specified, one will be provi= ded */
> > +=C2=A0 =C2=A0if (enabled_port_mask =3D=3D 0) {
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RTE_ETH_FOREACH_DEV(i) = {
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0enabled_port_mask |=3D 1u << i;
> >
> > However, in PATCH v4 8/8, we see this:
> > +=C2=A0 =C2=A0/* If no port mask was specified, then show non-own= ed ports */
> > +=C2=A0 =C2=A0if (enabled_port_mask =3D=3D 0) {
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RTE_ETH_FOREACH_DEV(i)<= br> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0enabled_port_mask =3D 1ul << i;
> > +=C2=A0 =C2=A0}
> >
> > Was there any specific reason to show just the last non-owned por= t in case the port mask was not specified?
> > Should we show all non-owned ports in case the user doesn=E2=80= =99t specify any port mask?=C2=A0
>
> It looks like a bug. It should be |=3D
> 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.
--0000000000002d78bd05dea4aef6--