DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Dai, Wei" <wei.dai@intel.com>
To: Adam Bynes <adambynes@outlook.com>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse --lcores
Date: Wed, 27 Jul 2016 09:15:27 +0000	[thread overview]
Message-ID: <49759EB36A64CF4892C1AFEC9231E8D63A266397@PGSMSX106.gar.corp.intel.com> (raw)
In-Reply-To: <SG2PR0201MB09985927FC27DBAA84E7B260B60E0@SG2PR0201MB0998.apcprd02.prod.outlook.com>

Hi, Adam & Ananyev
Thanks for your feedback.

> -----Original Message-----
> From: Adam Bynes [mailto:adambynes@outlook.com]
> Sent: Wednesday, July 27, 2016 1:36 AM
> To: Dai, Wei <wei.dai@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse
> --lcores
> 
> On Tue, Jul 26, 2016 at 11:51:57AM +0000, Ananyev, Konstantin wrote:
> >
> >
> hi Wei,
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wei Dai
> > > Sent: Tuesday, July 26, 2016 10:52 AM
> > > To: dev@dpdk.org
> > > Cc: Dai, Wei <wei.dai@intel.com>
> > > Subject: [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse
> --lcores
> > >
> > > local variable i is not referred by other codes in the function
> eal_parse_lcores( ), so it can be removed.
> > >
> > > Signed-off-by: Wei Dai <wei.dai@intel.com>
> > > ---
> > >  lib/librte_eal/common/eal_common_options.c | 4 ----
> > >  1 file changed, 4 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> > > index 481c732..c5bf98c 100644
> > > --- a/lib/librte_eal/common/eal_common_options.c
> > > +++ b/lib/librte_eal/common/eal_common_options.c
> > > @@ -578,7 +578,6 @@ eal_parse_lcores(const char *lcores)
> > >  	struct rte_config *cfg = rte_eal_get_configuration();
> > >  	static uint16_t set[RTE_MAX_LCORE];
> > >  	unsigned idx = 0;
> > > -	int i;
> > >  	unsigned count = 0;
> > >  	const char *lcore_start = NULL;
> > >  	const char *end = NULL;
> > > @@ -593,9 +592,6 @@ eal_parse_lcores(const char *lcores)
> > >  	/* Remove all blank characters ahead and after */
> > >  	while (isblank(*lcores))
> > >  		lcores++;
> > > -	i = strlen(lcores);
> > > -	while ((i > 0) && isblank(lcores[i - 1]))
> > > -		i--;
> >
> > I suppose originally it meant to do something  like that:
> > while ((i > 0) && isblank(lcores[i - 1]))
> > 	lcores[i--] = 0;
> totally agreed Konstantin, need to add lcore[i--] = '\0'
> 
> >
> > to get rid of blank characters at the end of the line, no?
> > Konstantin

The tail blank is not necessary to be removed from lcores here for following reasons:
1. The tail blanks can also be swallowed later in function eal_parse_set( ) 
  by "while (isblank(*end)) end++". And such operation/sentence also
  deal with blanks in the middle of arguments (for example: blank before
  - and after (7,8) in '0   -2    ,(3   - 6)@(3-6),7@(7-8)     ,8@(8-10)      '), 
  so above removal of blank is redundant.
  By the way, with --lcores '(0-3)@(0-3), (4-5)@(4-5)    ', I also find a new bug.
  After processing cpu set (4-5), the variable end in eal_parse_lcores doesn't point t
  ',' or '\0',  so this function return an error.
  The tail blank after cpu set (4-5) still need to be swallowed. 
  The patch v3 will be removed.eal

2. if let lcores[i--] = 0 here, due to type of input argument lcores (const char *), 
  building will fail. And if the type is changed to char *, the type of input argument of
  several other function also need to be changed. So according to above reason 1, it
  is not need to change the type.

Thanks
Wei Dai 

> >
> > >
> > >  	CPU_ZERO(&cpuset);
> > >
> > > --
> > > 2.5.5
> Adam Bynes

  reply	other threads:[~2016-07-27  9:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-21  6:03 [dpdk-dev] [PATCH] eal: fix parsing of argument of option --lcores Wei Dai
2016-07-21 14:21 ` Thomas Monjalon
2016-07-21 20:44 ` bynes adam
2016-07-27 10:06   ` Dai, Wei
2016-07-26  9:52 ` [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse --lcores Wei Dai
2016-07-26 11:51   ` Ananyev, Konstantin
2016-07-26 17:36     ` Adam Bynes
2016-07-27  9:15       ` Dai, Wei [this message]
2016-07-27 11:22   ` [dpdk-dev] [PATCH v3 1/4] " Wei Dai
2016-07-28 15:18     ` Ferruh Yigit
2016-07-27 11:25   ` [dpdk-dev] [PATCH v3 3/4] eal: fix tail blank check in --lcores argument Wei Dai
2016-07-28 15:18     ` Ferruh Yigit
2016-07-26  9:52 ` [dpdk-dev] [PATCH v2 2/2] eal: fix parsing of eal option --lcores Wei Dai
2016-07-27 11:23 ` [dpdk-dev] [PATCH v3 2/4] " Wei Dai
2016-07-28 15:18   ` Ferruh Yigit
2016-07-27 11:27 ` [dpdk-dev] [PATCH v3 4/4] eal: fix end character check in --lcores argument Wei Dai
2016-07-28 15:26   ` Ferruh Yigit
2016-07-28 16:05     ` Thomas Monjalon
2016-08-02  8:22       ` Dai, Wei
2016-08-02 10:45         ` 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=49759EB36A64CF4892C1AFEC9231E8D63A266397@PGSMSX106.gar.corp.intel.com \
    --to=wei.dai@intel.com \
    --cc=adambynes@outlook.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@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).