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

Gaëtan Rivet gaetan.rivet at 6wind.com
Thu Mar 22 17:27:51 CET 2018


On Thu, Mar 22, 2018 at 10:10:37AM -0400, Neil Horman wrote:
> 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?
> > 
> > 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 :-)
> > 
> +1, this really doesn't make much sense to me.  Two parsing routines seems like
> its just asking for us to have to fix parsing bugs in two places.  If allocation
> is a concern, I don't see why you can't just change the malloc in
> rte_kvargs_parse to an automatic allocation on the stack, or a preallocation set
> of kvargs that can be shared from init time.

I think the existing allocation scheme is fine for other usages (in
drivers and so on). Not for what I wanted to do.

>                                               librte_kvargs isn't necessecarily
> the best parsing library ever, but its not bad, and it just seems wrong to go
> re-inventing the wheel.
> 

It serves a different purpose than the one I'm pursuing.

This helper is lightweight and private. If I wanted to integrate my
needs with librte_kvargs, I would be adding new functionalities, making
it more complex, and for a use-case that is useless for the vast
majority of users of the lib.

If that's really an issue, I'm better off simply removing rte_parse_kv
and writing the parsing by hand within my function. This would be ugly
and tedious, but less than moving librte_kvargs within EAL and changing
it to my needs.

-- 
Gaëtan Rivet
6WIND


More information about the dev mailing list