RE: [PATCH v2 01/10] ethdev: introduce flow pre-configuration hints

[Alexander Kozyrev <akozyrev@nvidia.com>]

Sorry, Ivan, missed your email last week since I wasn't in To list. Adding all the people back.

On Wednesday, January 19, 2022 8:07 Ivan Malov <ivan.malov@oktetlabs.ru> wrote:


> > +Rules management configuration
> > +------------------------------
> > +
> > +Configure flow rules management.
> 
> It is either "management OF ruleS" or "rule management".
> Perhaps fix similar occurrences across the series.
Yes, thank for catching this, "rule management", of course.

> > +	/**
> > +	 * Number of counter actions pre-configured.
> > +	 * If set to 0, PMD will allocate counters dynamically.
> > +	 * @see RTE_FLOW_ACTION_TYPE_COUNT
> > +	 */
> > +	uint32_t nb_counters;
> > +	/**
> > +	 * Number of aging actions pre-configured.
> > +	 * If set to 0, PMD will allocate aging dynamically.
> > +	 * @see RTE_FLOW_ACTION_TYPE_AGE
> > +	 */
> > +	uint32_t nb_aging;
> > +	/**
> > +	 * Number of traffic metering actions pre-configured.
> > +	 * If set to 0, PMD will allocate meters dynamically.
> > +	 * @see RTE_FLOW_ACTION_TYPE_METER
> > +	 */
> > +	uint32_t nb_meters;
> 
> If duplication of the same description is undesirable,
> consider adding a common description for these fields:
> 
> /**
>   * Resource preallocation settings. Use zero to
>   * request that allocations be done on demand.
>   */
While this is true today and all these resources behave the same way if 0 is specified,
there is no guarantee the same behavior will preserve for any additional field in the future.
That is why I prefer to keep the descriptions separate for every single member here.


> Instead of "nb_aging", perhaps consider something like "nb_age_timers".
It is not technically correct, aging may be implemented as a timer or a counter.
nb_aging_flows maybe?

> > + * Configure flow rules module.
> > + * To pre-allocate resources as per the flow port attributes
> > + * this configuration function must be called before any flow rule is
> created.
> > + * Must be called only after Ethernet device is configured, but may be
> called
> > + * before or after the device is started as long as there are no flow rules.
> > + * No other rte_flow function should be called while this function is
> invoked.
> > + * This function can be called again to change the configuration.
> > + * Some PMDs may not support re-configuration at all,
> > + * or may only allow increasing the number of resources allocated.
> 
> Consider:
> 
> * Pre-configure the port's flow API engine.
> *
> * This API can only be invoked before the application
> * starts using the rest of the flow library functions.
> *
> * The API can be invoked multiple times to change the
> * settings. The port, however, may reject the changes.
Let me sink that in, the shorter description the better, I think.