Re: [PATCH v8 6/9] ethdev: add common devargs parser

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----Original Message-----
> From: Doherty, Declan
> Sent: Thursday, April 26, 2018 3:29 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org
> Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>;
> Shahaf Shuler <shahafs@mellanox.com>; Horton, Remy <remy.horton@intel.com>
> Subject: Re: [dpdk-dev][PATCH v8 6/9] ethdev: add common devargs parser
> 
> On 26/04/2018 1:03 PM, Ananyev, Konstantin wrote:
> >
> >
> >> -----Original Message-----
> >> From: Doherty, Declan
> >> Sent: Thursday, April 26, 2018 11:41 AM
> >> To: dev@dpdk.org
> >> Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>;
> >> Shahaf Shuler <shahafs@mellanox.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Horton, Remy
> <remy.horton@intel.com>;
> >> Doherty, Declan <declan.doherty@intel.com>
> >> Subject: [dpdk-dev][PATCH v8 6/9] ethdev: add common devargs parser
> >>
> >> From: Remy Horton <remy.horton@intel.com>
> >>
> >> Introduces a new structure, rte_eth_devargs, to support generic
> >> ethdev arguments common across NET PMDs, with a new API
> >> rte_eth_devargs_parse API to support PMD parsing these arguments. The
> >> patch add support for a representor argument  passed with passed with
> >> the EAL -w option. The representor parameter allows the user to specify
> >> which representor ports to initialise on a device.
> >>
> >> The argument supports passing a single representor port, a list of
> >> port values or a range of port values.
> >>
> >> -w BDF,representor=1  # create representor port 1 on pci device BDF
> >> -w BDF,representor=[1,2,5,6,10] # create representor ports in list
> >> -w BDF,representor=[0-31] # create representor ports in range
> >>
> >> Signed-off-by: Remy Horton <remy.horton@intel.com>
> >> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> >> ---
> >>   doc/guides/prog_guide/poll_mode_drv.rst |  19 ++++
> >>   lib/Makefile                            |   1 +
> >>   lib/librte_ether/rte_ethdev.c           | 182 ++++++++++++++++++++++++++++++++
> >>   lib/librte_ether/rte_ethdev_driver.h    |  30 ++++++
> >>   lib/librte_ether/rte_ethdev_version.map |   1 +
> >>   5 files changed, 233 insertions(+)
> >>
> >> diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
> >> index e5d01874e..09a93baec 100644
> >> --- a/doc/guides/prog_guide/poll_mode_drv.rst
> >> +++ b/doc/guides/prog_guide/poll_mode_drv.rst
> >> @@ -345,6 +345,25 @@ Ethernet Device API
> >>
> >>   The Ethernet device API exported by the Ethernet PMDs is described in the *DPDK API Reference*.
> >>
> >> +Ethernet Device Standard Device Arguments
> >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> +
> >> +Standard Ethernet device arguments allow for a set of commonly used arguments/
> >> +parameters which are applicable to all Ethernet devices to be available to for
> >> +specification of specific device and for passing common configuration
> >> +parameters to those ports.
> >> +
> >> +* ``representor`` for a device which supports the creation of representor ports
> >> +  this argument allows user to specify which switch ports to enable port
> >> +  representors for.::
> >> +
> >> +   -w BDBF,representor=0
> >> +   -w BDBF,representor=[0,4,6,9]
> >> +   -w BDBF,representor=[0-31]
> >> +
> >> +Note: PMDs are not required to support the standard device arguments and users
> >> +should consult the relevant PMD documentation to see support devargs.
> >> +
> >>   Extended Statistics API
> >>   ~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >> diff --git a/lib/Makefile b/lib/Makefile
> >> index 965be6c8d..536775e59 100644
> >> --- a/lib/Makefile
> >> +++ b/lib/Makefile
> >> @@ -21,6 +21,7 @@ DEPDIRS-librte_cmdline := librte_eal
> >>   DIRS-$(CONFIG_RTE_LIBRTE_ETHER) += librte_ether
> >>   DEPDIRS-librte_ether := librte_net librte_eal librte_mempool librte_ring
> >>   DEPDIRS-librte_ether += librte_mbuf
> >> +DEPDIRS-librte_ether += librte_kvargs
> >>   DIRS-$(CONFIG_RTE_LIBRTE_BBDEV) += librte_bbdev
> >>   DEPDIRS-librte_bbdev := librte_eal librte_mempool librte_mbuf
> >>   DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += librte_cryptodev
> >> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> >> index 621f8af7f..cb85d8bb7 100644
> >> --- a/lib/librte_ether/rte_ethdev.c
> >> +++ b/lib/librte_ether/rte_ethdev.c
> >> @@ -34,6 +34,7 @@
> >>   #include <rte_errno.h>
> >>   #include <rte_spinlock.h>
> >>   #include <rte_string_fns.h>
> >> ++#include <rte_kvargs.h>
> >>
> >>   #include "rte_ether.h"
> >>   #include "rte_ethdev.h"
> >> @@ -4101,6 +4102,187 @@ rte_eth_dev_pool_ops_supported(uint16_t port_id, const char *pool)
> >>   	return (*dev->dev_ops->pool_ops_supported)(dev, pool);
> >>   }
> >>
> >> +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.

Ok, thanks Declan.
Konstantin