[dpdk-dev] [PATCH v5 01/13] eal: add param register infrastructure

Thomas Monjalon thomas at monjalon.net
Wed Oct 17 15:46:42 CEST 2018


17/10/2018 13:45, Gaëtan Rivet:
> Hi Thomas,
> 
> On Wed, Oct 17, 2018 at 11:41:53AM +0200, Thomas Monjalon wrote:
> > I still think all the wording is incorrect.
> > Please start by describing what is "param", "flag" and "option" in your mind.
> > They are all mentioned in this file.
> > Are you sure rte_param is the right name?
> > 
> 
> I suggested the name rte_param, I think the original proposal was
> rte_lib_init, which to me unduly diminished the intent of these structures.

I think the right word is "run-time option".
An option can have a parameter.
If this API is not supporting options with parameters, the name is
really misleading.

> I think rte_param seems proper, this is a generic parameter object
> description. The integer "enabled" is described as a flag in the
> structure, as it is used to flag the init routine down the road to
> trigger the init callback associated with this parameter.

"enabled" can be documented as the result of the option parsing.
If the option is given to rte_eal_init, it becomes enabled.

> eal_option is reminiscent of optarg / optind of getopt() family,
> which seems fitting.
> 
> I don't mean to overstep Kevin's role defending his work, but given
> that I proposed some of this naming and pushed for this direction to be
> taken in the first place, I feel I should help explain my propositions.
> 
> rte_param could become rte_parameter or rte_option instead, eal_option
> could become opt_string or opt_str, and so on, do you have specific
> ideas about proper names?

rte_option looks OK.

The global picture may be better explained I think.
Any help with wording and documentation is appreciated, thanks.


> > 16/10/2018 17:57, Kevin Laatz:
> > > --- /dev/null
> > > +++ b/lib/librte_eal/common/include/rte_param.h
> > > @@ -0,0 +1,91 @@
> > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > + * Copyright(c) 2018 Intel Corporation.
> > > + */
> > > +
> > > +#ifndef __INCLUDE_RTE_PARAM_H__
> > > +#define __INCLUDE_RTE_PARAM_H__
> > > +
> > > +/**
> > > + * @file
> > > + *
> > > + * This API introduces the ability to register callbacks with EAL. When
> > > + * registering a callback, the application also provides an option as part
> > > + * of the struct used to register. If the option is passed to EAL when
> > > + * running a DPDK application, the relevant callback will be called at the
> > > + * end of EAL init.  For example, passing --telemetry will make the
> > > + * telemetry init be called at the end of EAL init.
> > > + *
> 
> Citing --telemetry here is a bad idea, this file is lib-agnostic,
> --telemetry is not assured to be relevant.
> 
> > > + * The register API can be used to resolve circular dependency issues
> > > + * between EAL and the library. The library uses EAL but is also initialized by
> > > + * EAL. Hence, EAL depends on the init function of the library. The API
> > > + * introduced in rte_param allows us to register the library init with EAL
> > > + * (passing a function pointer) and avoid the circular dependency.
> > > + */
> 
> 







More information about the dev mailing list