[dpdk-dev] [PATCH v2 04/18] eal: add lightweight kvarg parsing utility

Gaëtan Rivet gaetan.rivet at 6wind.com
Wed Mar 21 18:58:07 CET 2018


Hello Keith,

On Wed, Mar 21, 2018 at 05:32:24PM +0000, Wiles, Keith wrote:
> 
> 
> > On Mar 21, 2018, at 12:15 PM, Gaetan Rivet <gaetan.rivet at 6wind.com> wrote:
> > 
> > This library offers a quick way to parse parameters passed with a
> > key=value syntax.
> > 
> > A single function is needed and finds the relevant element within the
> > text. No dynamic allocation is performed. It is possible to chain the
> > parsing of each pairs for quickly scanning a list.
> > 
> > This utility is private to the EAL and should allow avoiding having to
> > move around the more complete librte_kvargs.
> 
> What is the big advantage with this code and the librte_kvargs code. Is it just no allocation, rte_kvargs needs to be build before parts of EAL or what?
> 

Pretty much, yes. I needed something lean and simple.

> My concern is we have now two flavors one in EAL and one in librte_kvargs, would it not be more reasonable to improve rte_kvargs to remove your objections? I am all for fast, better, stronger code :-)
> 

I hear you. I decided this was worth the trade-off.

librte_kvargs does the iteration on a kvlist in one-line.
It processes the input text and mangle as needed to be able to do so.
Drivers using it will be able to declare first a set of acceptable keys,
meaning that it is complementary to having a usage-help and more stringent
input validation.

rte_kvargs does none of it. This means that each user would have to
re-implement checks by hand, and reviewers would need to enforce that
they are done, etc.

So, IMO, different use-cases. In this context, I think making the effort
of moving around librte_kvargs within the EAL, tweaking its use for my
needs, does not make much sense. It would complicate its
implementation only for one less private function.

If people do not like using librte_kvargs, it could maybe evolve, be
rewritten, then all drivers would need to follow suit, etc. But I
haven't seen the need personally.

Regards,
-- 
Gaëtan Rivet
6WIND


More information about the dev mailing list