From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v8 6/9] ethdev: add common devargs parser
Date: Thu, 26 Apr 2018 16:44:33 +0200
Message-ID: <1766858.7hL0hTjUtK@xps>
References: <20180416130605.6509-1-declan.doherty@intel.com>
 <2601191342CEEE43887BDE71AB977258AEBD049D@IRSMSX102.ger.corp.intel.com>
 <6c84cc1c-9ad4-11e5-f99f-1bc7152c7b14@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>, Adrien Mazarguil <adrien.mazarguil@6wind.com>,
 "Yigit, Ferruh" <ferruh.yigit@intel.com>, Shahaf Shuler <shahafs@mellanox.com>,
 "Horton, Remy" <remy.horton@intel.com>, gaetan.rivet@6wind.com
To: "Doherty, Declan" <declan.doherty@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id A30548D3C
 for <dev@dpdk.org>; Thu, 26 Apr 2018 16:44:36 +0200 (CEST)
In-Reply-To: <6c84cc1c-9ad4-11e5-f99f-1bc7152c7b14@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

26/04/2018 16:28, Doherty, Declan:
> On 26/04/2018 1:03 PM, Ananyev, Konstantin wrote:
> > From: Doherty, Declan
> >> +typedef int (*rte_eth_devargs_callback_t)(char *str, void *data);
> >> +
> >> +static int
> >> +rte_eth_devargs_tokenise(struct rte_kvargs *arglist, const char *str_in)
> >> +{
> > 
> > I still think that if you'd like to extend rte_kvarrgs to be able to parse something like: "key=[val1,val2,...,valn]",
> > you have to make it generic kvargs ability and put it into librte_kvargs, not try to introduce your own new parser here.
> > Imagine that in addition to your 'port=[val1,val2, ..valn]' devargs string would contain some extra (let say device specific)
> > parameters.
> > What would happen, when PMD will try to use rte_kvargs_parse() on such string?
> > My understanding - it would fail, correct?
> > 
> > As an alternative - as I remember rte_kvargs allows you to have multiple identical key, i.e: "key=val1,key=val2,...,key=valn".
> > Why not to use that way, if you don't want to introduce extra code in rte_kvargs?
> > 
> 
> Hey Konstantin, the rationale for keeping this independent from 
> librte_kvargs was that it is likely that the implementation of parsing 
> devarfs will change in the next release due the proposed rework on the 
> whole devargs infrastructure. I hadn't considered the potential issue 
> with rte_kvargs_parse() on string using the proposed syntax here. I'll 
> send a patch for alignment with librte_kvargs for the next release 
> candidate.

The new devargs infra will rely on librte_kvargs.
So improving kvargs is the right way here.