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.
