[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 02:41:37PM -0700, Matthew Hall wrote: > On Fri, Jun 03, 2016 at 03:18:04PM -0400, Neil Horman wrote: > > I'm not opposed to default values, but it seems to me that if we are > > splitting > > out a configuration storage library from dpdk, part of the initzliation of > > th

[dpdk-dev] [RFC] Yet another option for DPDK options

I On Fri, Jun 3, 2016 at 10:23 PM, Wiles, Keith wrote: > > On 6/3/16, 2:18 PM, "Neil Horman" wrote: > > >On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: > >> On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" < > dev-bounces at dpdk.org on behalf of keith.wiles at intel.com> wrot

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman wrote: > On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote: > > > > On 6/3/16, 12:44 PM, "Neil Horman" wrote: > > > > >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: > > >> Sorry, I deleted all of the text as it was getting a

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/3/16, 2:18 PM, "Neil Horman" wrote: >On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: >> On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" > on behalf of keith.wiles at intel.com> wrote: >> >> >On 6/3/16, 1:52 PM, "Arnon Warshavsky" mailto:arnon at >> >qwilt.com>> wrote: >>

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" wrote: >On 6/3/16, 1:52 PM, "Arnon Warshavsky" mailto:arnon at >qwilt.com>> wrote: > > > >On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman tuxdriver.com> wrote: >On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/3/16, 1:52 PM, "Arnon Warshavsky" mailto:arnon at qwilt.com>> wrote: On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman mailto:nhorman at tuxdriver.com>> wrote: On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote: > > On 6/3/16, 12:44 PM, "Neil Horman" mailto:nhorman > at tuxdriver.com>

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/3/16, 12:44 PM, "Neil Horman" wrote: >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: >> Sorry, I deleted all of the text as it was getting a bit long. >> >> Here are my thoughts as of now, which is a combination of many suggestions I >> read from everyone?s emails. I hope t

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 3, 2016 at 3:53 PM, Panu Matilainen wrote: > On 06/03/2016 03:01 PM, Arnon Warshavsky wrote: > >> >> >> On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman > > wrote: >> >> On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: >> > On Fri,

[dpdk-dev] [RFC] Yet another option for DPDK options

Regards, Keith On 6/3/16, 11:04 AM, "dev on behalf of Wiles, Keith" wrote: >Sorry, I deleted all of the text as it was getting a bit long. > >Here are my thoughts as of now, which is a combination of many suggestions I >read from everyone?s emails. I hope this is not too hard to understand.

[dpdk-dev] [RFC] Yet another option for DPDK options

+1 We're using INI in our app, turned out to be quite simple, like this: [eal] ;; EAL common options: ;; -c COREMASK Hexadecimal bitmask of cores to run on # coremask = fff ;; -l CORELIST List of cores to run on corelist = 3,4,5 ;; --lcores COREMAPMap lcore set to phys

[dpdk-dev] [RFC] Yet another option for DPDK options

Sorry, I deleted all of the text as it was getting a bit long. Here are my thoughts as of now, which is a combination of many suggestions I read from everyone?s emails. I hope this is not too hard to understand. - Break out the current command line options out of the DPDK common code and move i

[dpdk-dev] [RFC] Yet another option for DPDK options

On 06/03/2016 03:01 PM, Arnon Warshavsky wrote: > > > On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman > wrote: > > On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: > > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: > > >

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: > On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" on behalf of keith.wiles at intel.com> wrote: > > >On 6/3/16, 1:52 PM, "Arnon Warshavsky" mailto:arnon at > >qwilt.com>> wrote: > > > > > > > >On Fri, Jun 3, 2016 at 9:38 PM, Neil

[dpdk-dev] [RFC] Yet another option for DPDK options

On 06/03/2016 02:50 PM, Neil Horman wrote: > On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: >> On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: >>> On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles,

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman wrote: > On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: > > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: > > > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > > > > On Thu, Jun 02, 2016 at 07:41:10P

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 07:23:39PM +, Wiles, Keith wrote: > If someone needs or wants default values in the API call then a wrapper > functions around the basic keystore APIs can be done by the developer or we > can add a new set of APIs to provide that type of feature, just like the > varia

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 03:18:04PM -0400, Neil Horman wrote: > I'm not opposed to default values, but it seems to me that if we are splitting > out a configuration storage library from dpdk, part of the initzliation of > that > library can be installing default values. That is to say, instead of

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: > If I understand your code above the API would pass in a default value if one > did not exist in the storage, which I guess is reasonable. Anyone think this > is a good idea or not? This model has worked very well in my code at least

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 09:52:40PM +0300, Arnon Warshavsky wrote: > What about the data types of the values? > I would assume that as a library it can provide the service of typed > get/set and not leave conversion and validation to the app. > > rte_map_get_int(map,section,key) > rte_map_get_doubl

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote: > > On 6/3/16, 12:44 PM, "Neil Horman" wrote: > > >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: > >> Sorry, I deleted all of the text as it was getting a bit long. > >> > >> Here are my thoughts as of now, which is a

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: > Sorry, I deleted all of the text as it was getting a bit long. > > Here are my thoughts as of now, which is a combination of many suggestions I > read from everyone?s emails. I hope this is not too hard to understand. > > - Break ou

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > > On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote: > > > > > > On 6/2/16, 12:11 PM, "Neil Horman" wrote: > > > > > > > > > > >1) The definition of a con

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote: > > > > On 6/2/16, 12:11 PM, "Neil Horman" wrote: > > > > > > > >1) The definition of a config structure that can be passed to rte_eal_init, > > >defining the configuratio

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 10:57:22AM +0100, Bruce Richardson wrote: > On Thu, Jun 02, 2016 at 07:17:05PM -0700, Matthew Hall wrote: > > On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote: > > > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy > > > > any > > > > pe

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 07:17:05PM -0700, Matthew Hall wrote: > On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote: > > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy > > > any > > > performance advantage because it's just for config. > > > > > What!? I can't

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 07:17:05PM -0700, Matthew Hall wrote: > On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote: > > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy > > > any > > > performance advantage because it's just for config. > > > > > What!? I can't

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: > > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > > > On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote: > > > > > > > > On 6/2/16, 12:1

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/2/16, 12:11 PM, "Neil Horman" wrote: > >1) The definition of a config structure that can be passed to rte_eal_init, >defining the configuration for that running process Having a configuration structure means we have to have an ABI change to that structure anytime we add or remove an optio

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/2/16, 12:11 PM, "Neil Horman" wrote: >On Thu, Jun 02, 2016 at 01:53:32PM +, Wiles, Keith wrote: >> >> On 6/2/16, 8:19 AM, "Thomas Monjalon" wrote: >> >> >2016-06-02 06:41, Neil Horman: >> >> I'm not sure why you're focusing no selecting a config file format at >> >> all. Why >> >>

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote: > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy any > > performance advantage because it's just for config. > > > What!? I can't even parse that sentence. I would not want to have to use the structure you p

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 01:53:55PM -0700, Matthew Hall wrote: > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > > struct key_vals { > > char *key; > > union { > > ulong longval; > > void *ptrval; > > } value; > > }; > > > > struct config { > >

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote: > > On 6/2/16, 12:11 PM, "Neil Horman" wrote: > > > > >1) The definition of a config structure that can be passed to rte_eal_init, > >defining the configuration for that running process > > Having a configuration structure means we h

[dpdk-dev] [RFC] Yet another option for DPDK options

On Wed, Jun 01, 2016 at 03:00:11PM +, Wiles, Keith wrote: > I have been looking at a number of different options here and the direction I > was thinking was using a file for the options and configurations with the > data in a clean format. It should be helpful and handy for productive usage.

[dpdk-dev] [RFC] Yet another option for DPDK options

2016-06-02 06:41, Neil Horman: > I'm not sure why you're focusing no selecting a config file format at all. > Why > not just focus on removing the argument parsing from the core rte_eal_init > code, > instead passing in a configuration struct that is stored and queried per > application. Leave

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > struct key_vals { > char *key; > union { > ulong longval; > void *ptrval; > } value; > }; > > struct config { > size_t count; > struct key_vals kvp[0]; > }; This sort of code i

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/2/16, 8:19 AM, "Thomas Monjalon" wrote: >2016-06-02 06:41, Neil Horman: >> I'm not sure why you're focusing no selecting a config file format at all. >> Why The reason is I am on now looking at formats is because I have been thinking about this issue for some time and already understand

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote: > Would this work better in the long run, does a fixed structure still make > sense? This right here is why I suggested libjson-c as an example. It has a nice API like this already: http://json-c.github.io/json-c/json-c-0.12/doc/html

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 01:53:32PM +, Wiles, Keith wrote: > > On 6/2/16, 8:19 AM, "Thomas Monjalon" wrote: > > >2016-06-02 06:41, Neil Horman: > >> I'm not sure why you're focusing no selecting a config file format at all. > >> Why > > The reason is I am on now looking at formats is becau

[dpdk-dev] [RFC] Yet another option for DPDK options

On 1 June 2016 at 20:51, Thomas Monjalon wrote: > Hi Keith, > > I'll try to bring more context to this discussion below. > > 2016-06-01 15:00, Wiles, Keith: > > Started from the link below, but did not want to highjack the thread. > > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > > >

[dpdk-dev] [RFC] Yet another option for DPDK options

On Wed, Jun 01, 2016 at 03:00:11PM +, Wiles, Keith wrote: > Started from the link below, but did not want to highjack the thread. > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > I was thinking about this problem from a user perspective and command line > options are very difficult

[dpdk-dev] [RFC] Yet another option for DPDK options

Hi Keith, I'll try to bring more context to this discussion below. 2016-06-01 15:00, Wiles, Keith: > Started from the link below, but did not want to highjack the thread. > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > I was thinking about this problem from a user perspective and com

[dpdk-dev] [RFC] Yet another option for DPDK options

On Wed, Jun 1, 2016 at 7:18 PM, Bruce Richardson wrote: > On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote: > > On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith > wrote: > > > > > Started from the link below, but did not want to highjack the thread. > > > http://dpdk.org/ml/archives/dev/

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/1/16, 11:18 AM, "Richardson, Bruce" wrote: >On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote: >> On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith >> wrote: >> >> > Started from the link below, but did not want to highjack the thread. >> > http://dpdk.org/ml/archives/dev/2016-June

[dpdk-dev] [RFC] Yet another option for DPDK options

On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote: > On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith > wrote: > > > Started from the link below, but did not want to highjack the thread. > > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > > > I was thinking about this problem fr

[dpdk-dev] [RFC] Yet another option for DPDK options

Regards, Keith On 6/1/16, 10:46 AM, "Matthew Hall" wrote: >On Wed, Jun 01, 2016 at 03:00:11PM +, Wiles, Keith wrote: >> The INI file is too flat and I wanted a hierarchy in the data, the JSON data >> is similar and XML is just hard to read. > >I don't think it's fair to say JSON lacks h

[dpdk-dev] [RFC] Yet another option for DPDK options

Started from the link below, but did not want to highjack the thread. http://dpdk.org/ml/archives/dev/2016-June/040021.html I was thinking about this problem from a user perspective and command line options are very difficult to manage specifically when you have a large number of options as we h

[dpdk-dev] [RFC] Yet another option for DPDK options

On Wed, 1 Jun 2016 17:18:26 +0100 Bruce Richardson wrote: > On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote: > > On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith > > wrote: > > > > > Started from the link below, but did not want to highjack the thread. > > > http://dpdk.org/ml/archive

[dpdk-dev] [RFC] Yet another option for DPDK options

On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith wrote: > Started from the link below, but did not want to highjack the thread. > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > I was thinking about this problem from a user perspective and command line > options are very difficult to manag

[dpdk-dev] [RFC] Yet another option for DPDK options

On Wed, Jun 01, 2016 at 03:00:11PM +, Wiles, Keith wrote: > The INI file is too flat and I wanted a hierarchy in the data, the JSON data > is similar and XML is just hard to read. I don't think it's fair to say JSON lacks hierarchy. Personally it is working great in my current application. T