From: David Marchand <david.marchand@redhat.com>
To: "Varghese, Vipin" <vipin.varghese@intel.com>
Cc: dev <dev@dpdk.org>,
"Kovacevic, Marko" <marko.kovacevic@intel.com>,
"Pattan, Reshma" <reshma.pattan@intel.com>,
"Wiles, Keith" <keith.wiles@intel.com>,
"Mcnamara, John" <john.mcnamara@intel.com>,
"Byrne, Stephen1" <stephen1.byrne@intel.com>,
"Tamboli, Amit S" <amit.tamboli@intel.com>,
"Padubidri, Sanjay A" <sanjay.padubidri@intel.com>,
"Patel, Amol" <amol.patel@intel.com>
Subject: Re: [dpdk-dev] [PATCH v5 2/2] app/pdump: enhance to support multi-core capture
Date: Thu, 4 Apr 2019 09:39:32 +0200 [thread overview]
Message-ID: <CAJFAV8wiDpePnu8GoNXb0HTRqNicKsnkeGBiX9PzKA2F3vCdwQ@mail.gmail.com> (raw)
Message-ID: <20190404073932.Sg1cliYmYeut0J_lpRc-TtdglN2YNGtXWdVh0E8RKMI@z> (raw)
In-Reply-To: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D328FFD@BGSMSX101.gar.corp.intel.com>
On Tue, Apr 2, 2019 at 5:30 PM Varghese, Vipin <vipin.varghese@intel.com>
wrote:
> Hi David,
>
>
>
> snipped
> #define CMD_LINE_OPT_PDUMP "pdump"
> +#define CMD_LINE_OPT_PDUMP_NUM 1
> +#define CMD_LINE_OPT_MULTI "multi"
> +#define CMD_LINE_OPT_MULTI_NUM 2
> #define PDUMP_PORT_ARG "port"
> #define PDUMP_PCI_ARG "device_id"
> #define PDUMP_QUEUE_ARG "queue"
>
>
>
> You'd better map to integers that do not collide with ascii characters
> (even if non printable).
>
> So values >= 256 are better.
>
> This is the reason for the comment here:
>
> https://git.dpdk.org/dpdk/tree/lib/librte_eal/common/eal_options.h#n19
>
>
>
> In case of dpdk-pdump; there are 2 options ‘multi’ and ‘pdump’. But in
> case of eal_option there are multiple options which has same fist
> character. Hence the comment 'first long only option value must be >= 256,
> so that we won't conflict with short options' is true.
>
>
>
> In my humble opinion, I think it need not change. But please let me know
> otherwise.
>
The convention I had proposed is to just leave the whole [0-255] range to
potential short options.
This marks a demarcation between long options that map to short options and
long "only" options.
I don't care, just prefer to have something systematic.
Snipped
>
> + printf("usage: %s [EAL options] -- [--%s] "
> + "--%s "
> "'(port=<port id> | device_id=<pci id or vdev
> name>),"
> "(queue=<queue_id>),"
> "(rx-dev=<iface or pcap file> |"
> @@ -152,7 +157,7 @@ pdump_usage(const char *prgname)
> "[ring-size=<ring size>default:16384],"
> "[mbuf-size=<mbuf data size>default:2176],"
> "[total-num-mbufs=<number of
> mbufs>default:65535]'\n",
> - prgname);
> + prgname, CMD_LINE_OPT_MULTI, CMD_LINE_OPT_PDUMP);
> }
>
> static int
>
>
>
> You can concatenate the macro.
>
>
>
> Thank you for the suggestion,
>
>
>
> #define OPT(X) #X
>
> #define STR_REPLACE "\n[--"OPT(multi)"]\n --"OPT(pdump)
>
>
> prgname, STR_REPLACE);
>
>
>
> should we change to this or skip this as we are using this once?
>
>
>
> snipped
>
I don't understand what you propose.
My suggestion is simple:
+ printf("usage: %s [EAL options] -- [--"CMD_LINE_OPT_MULTI"] "
+ "--"CMD_LINE_OPT_PDUMP" "
--
David Marchand
next prev parent reply other threads:[~2019-04-04 7:39 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-28 6:00 [dpdk-dev] [PATCH] " Vipin Varghese
2019-03-28 6:00 ` Vipin Varghese
2019-03-28 14:57 ` [dpdk-dev] [PATCH v2] " Vipin Varghese
2019-03-28 14:57 ` Vipin Varghese
2019-03-28 15:04 ` [dpdk-dev] [PATCH v3] " Vipin Varghese
2019-03-28 15:04 ` Vipin Varghese
2019-03-28 15:34 ` Wiles, Keith
2019-03-28 15:34 ` Wiles, Keith
2019-03-29 10:08 ` Pattan, Reshma
2019-03-29 10:08 ` Pattan, Reshma
2019-03-29 10:22 ` Varghese, Vipin
2019-03-29 10:22 ` Varghese, Vipin
2019-03-29 10:52 ` Pattan, Reshma
2019-03-29 10:52 ` Pattan, Reshma
2019-03-29 17:03 ` Ferruh Yigit
2019-03-29 17:03 ` Ferruh Yigit
2019-04-01 4:05 ` Varghese, Vipin
2019-04-01 4:05 ` Varghese, Vipin
2019-04-02 4:33 ` [dpdk-dev] [PATCH v4 0/2] app/pdump: enhance to support unique cores Vipin Varghese
2019-04-02 4:33 ` Vipin Varghese
2019-04-02 4:33 ` [dpdk-dev] [PATCH v4 1/2] app/pdump: remove core restriction Vipin Varghese
2019-04-02 4:33 ` Vipin Varghese
2019-04-02 4:33 ` [dpdk-dev] [PATCH v4 2/2] app/pdump: enhance to support multi-core capture Vipin Varghese
2019-04-02 4:33 ` Vipin Varghese
2019-04-02 7:05 ` David Marchand
2019-04-02 7:05 ` David Marchand
2019-04-02 8:06 ` Varghese, Vipin
2019-04-02 8:06 ` Varghese, Vipin
2019-04-02 9:18 ` [dpdk-dev] [PATCH v5 0/2] app/pdump: enhance to support unique cores Vipin Varghese
2019-04-02 9:18 ` Vipin Varghese
2019-04-02 9:18 ` [dpdk-dev] [PATCH v5 1/2] app/pdump: remove core restriction Vipin Varghese
2019-04-02 9:18 ` Vipin Varghese
2019-04-02 9:18 ` [dpdk-dev] [PATCH v5 2/2] app/pdump: enhance to support multi-core capture Vipin Varghese
2019-04-02 9:18 ` Vipin Varghese
2019-04-02 10:01 ` David Marchand
2019-04-02 10:01 ` David Marchand
2019-04-02 15:30 ` Varghese, Vipin
2019-04-02 15:30 ` Varghese, Vipin
2019-04-04 7:39 ` David Marchand [this message]
2019-04-04 7:39 ` David Marchand
2019-04-02 16:13 ` Pattan, Reshma
2019-04-02 16:13 ` Pattan, Reshma
2019-04-03 3:53 ` Varghese, Vipin
2019-04-03 3:53 ` Varghese, Vipin
2019-04-05 17:10 ` Pattan, Reshma
2019-04-05 17:10 ` Pattan, Reshma
2019-04-08 3:03 ` Varghese, Vipin
2019-04-08 3:03 ` Varghese, Vipin
2019-04-04 8:55 ` [dpdk-dev] [PATCH v6 0/2] app/pdump: enhance to support unique cores Vipin Varghese
2019-04-04 8:55 ` Vipin Varghese
2019-04-04 8:55 ` [dpdk-dev] [PATCH v6 1/2] app/pdump: remove core restriction Vipin Varghese
2019-04-04 8:55 ` Vipin Varghese
2019-04-09 9:04 ` Pattan, Reshma
2019-04-09 9:04 ` Pattan, Reshma
2019-04-04 8:55 ` [dpdk-dev] [PATCH v6 2/2] app/pdump: enhance to support multi-core capture Vipin Varghese
2019-04-04 8:55 ` Vipin Varghese
2019-04-05 17:09 ` Pattan, Reshma
2019-04-05 17:09 ` Pattan, Reshma
2019-04-08 3:01 ` Varghese, Vipin
2019-04-08 3:01 ` Varghese, Vipin
2019-04-09 9:05 ` Pattan, Reshma
2019-04-09 9:05 ` Pattan, Reshma
2019-04-22 19:49 ` [dpdk-dev] [PATCH v6 0/2] app/pdump: enhance to support unique cores Thomas Monjalon
2019-04-22 19:49 ` Thomas Monjalon
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=CAJFAV8wiDpePnu8GoNXb0HTRqNicKsnkeGBiX9PzKA2F3vCdwQ@mail.gmail.com \
--to=david.marchand@redhat.com \
--cc=amit.tamboli@intel.com \
--cc=amol.patel@intel.com \
--cc=dev@dpdk.org \
--cc=john.mcnamara@intel.com \
--cc=keith.wiles@intel.com \
--cc=marko.kovacevic@intel.com \
--cc=reshma.pattan@intel.com \
--cc=sanjay.padubidri@intel.com \
--cc=stephen1.byrne@intel.com \
--cc=vipin.varghese@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).