On Mon, Feb 7, 2022 at 11:30 PM Alexander Kozyrev <akozy...@nvidia.com> wrote:
>
> On Monday, February 7, 2022 9:52 Jerin Jacob <jerinjac...@gmail.com> wrote:
> > On Sun, Feb 6, 2022 at 8:56 AM Alexander Kozyrev <akozy...@nvidia.com>
> > wrote:
> > >
> > > The flow rules creation/destruction at a large scale incurs a performance
> > > penalty and may negatively impact the packet processing when used
> > > as part of the datapath logic. This is mainly because software/hardware
> > > resources are allocated and prepared during the flow rule creation.
> > >
> > > In order to optimize the insertion rate, PMD may use some hints provided
> > > by the application at the initialization phase. The rte_flow_configure()
> > > function allows to pre-allocate all the needed resources beforehand.
> > > These resources can be used at a later stage without costly allocations.
> > > Every PMD may use only the subset of hints and ignore unused ones or
> > > fail in case the requested configuration is not supported.
> > >
> > > The rte_flow_info_get() is available to retrieve the information about
> > > supported pre-configurable resources. Both these functions must be called
> > > before any other usage of the flow API engine.
> > >
> > > Signed-off-by: Alexander Kozyrev <akozy...@nvidia.com>
> > > ---
> > > doc/guides/prog_guide/rte_flow.rst | 37 ++++++++++++
> > > doc/guides/rel_notes/release_22_03.rst | 4 ++
> > > lib/ethdev/rte_flow.c | 40 +++++++++++++
> > > lib/ethdev/rte_flow.h | 82 ++++++++++++++++++++++++++
> > > lib/ethdev/rte_flow_driver.h | 10 ++++
> > > lib/ethdev/version.map | 4 ++
> > > 6 files changed, 177 insertions(+)
> > >
> > > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > > index b4aa9c47c2..5b4c5dd609 100644
> > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > @@ -3589,6 +3589,43 @@ Return values:
> > >
> > > - 0 on success, a negative errno value otherwise and ``rte_errno`` is
> > > set.
> > >
> > > +Flow engine configuration
> > > +-------------------------
> > > +
> > > +Configure flow API management.
> > > +
> > > +An application may provide some hints at the initialization phase about
> > > +rules engine configuration and/or expected flow rules characteristics.
> >
> > IMO, We can explicitly remove _hint_ in the documentation.
> > When we add new paramers to configure, it may not be hit.
> >
> > > +These hints may be used by PMD to pre-allocate resources and configure
> > NIC.
> >
> > hints->parameters
>
> Sounds good, let's call them parameters and PDM will decide to use them or
> not anyway.
> > > + */
> > > +struct rte_flow_port_attr {
> > > + /**
> > > + * Version of the struct layout, should be 0.
> > > + */
> > > + uint32_t version;
> >
> > IMO, it is not concluded to use the version in the public API.
>
> Yes, there is ongoing discussion on how to properly address versioning right
> now.
> But I would like to proceed with this API without having to wait the final
> decision on that.
> My API is experimental and it is possible to switch to any versioning model
> after.
+ @Richardson, Bruce
On the same note, since it is experimental, we can add the version
when we needed.
I think, the primary pushback is application should not be aware of
version, instead,
implementation probe the version and adjust accordingly.
IMO, In order to make forward progress, I suggest having the next
version of the patch with without
version and we can introduce this topic to TB for a final decision one
way or another.
>
> >
> > > + /**
> > > + * Number of counter actions pre-configured.
> > > + * @see RTE_FLOW_ACTION_TYPE_COUNT
> > > + */
> > > + uint32_t nb_counters;
> > > + /**
> > > + * Number of aging flows actions pre-configured.
> > > + * @see RTE_FLOW_ACTION_TYPE_AGE
> > > + */
> > > + uint32_t nb_aging_flows;
> > > + /**
> > > + * Number of traffic metering actions pre-configured.
> > > + * @see RTE_FLOW_ACTION_TYPE_METER
> > > + */
> > > + uint32_t nb_meters;
> > > +};
> > > +
> > > +/**
> > > + * @warning
> > > + * @b EXPERIMENTAL: this API may change without prior notice.
> > > + *
> > > + * Retrieve configuration attributes supported by the port.
> > > + *
> > > + * @param port_id
> > > + * Port identifier of Ethernet device.
> > > + * @param[in] port_attr
> >
> > By default all parameters are "in", no need for additional "in" for just
> > input.
>
> "in" or "out" is a part of description of every pointer parameter throughout
> rte_flow.h
Ack.
