[dpdk-dev] [PATCH] doc: remove obsolete future considerations in flow guide

[Ori Kam]

Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Subject: [PATCH] doc: remove obsolete future considerations in flow guide
> 
> After 4 years, rte_flow has evolved enough to not require special notes
> about what could be added in future.
> Part of the removed plans were obsolete anyway.
> 
> Signed-off-by: Thomas Monjalon <thomas at monjalon.net>
> ---
>  doc/guides/prog_guide/rte_flow.rst | 38 +-----------------------------
>  1 file changed, 1 insertion(+), 37 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index 62a57919eb..c6cef43bdd 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -719,9 +719,6 @@ Most of these are basically protocol header
> definitions with associated  bit-masks. They must be specified (stacked) from
> lowest to highest protocol  layer to form a matching pattern.
> 
> -The following list is not exhaustive, new protocols will be added in the -
> future.
> -
>  Item: ``ANY``
>  ^^^^^^^^^^^^^
> 
> @@ -1523,8 +1520,7 @@ that VOID is ignored.
>  Action types
>  ~~~~~~~~~~~~
> 
> -Common action types are described in this section. Like pattern item types, -
> this list is not exhaustive as new actions will be added in the future.
> +Common action types are described in this section.
> 
>  Action: ``END``
>  ^^^^^^^^^^^^^^^
> @@ -2854,19 +2850,6 @@ A method to generate them remains to be
> defined.
>  Application may use PMD dynamic items or actions in flow rules. In that case
> size of configuration object in dynamic element must be a pointer size.
> 
> -Planned types
> -~~~~~~~~~~~~~
> -
> -Pattern item types will be added as new protocols are implemented.
> -
> -Variable headers support through dedicated pattern items, for example in -
> order to match specific IPv4 options and IPv6 extension headers would be -
> stacked after IPv4/IPv6 items.
> -
> -Other action types are planned but are not defined yet. These include the -
> ability to alter packet data in several ways, such as performing -
> encapsulation/decapsulation of tunnel headers.
> -
>  Rules management
>  ----------------
> 
> @@ -3361,8 +3344,6 @@ so the API level protection is disabled.
>  Please note that this API-level mutex protects only rte_flow functions,
> other control path functions are not in scope.
> 
> -More will be added over time.
> -
>  Device compatibility
>  --------------------
> 
> @@ -3511,22 +3492,5 @@ PMDs.
>  - In order to save priority levels, PMDs may evaluate whether rules are
>    likely to collide and adjust their priority accordingly.
> 
> -Future evolutions
> ------------------
> -
> -- A device profile selection function which could be used to force a
> -  permanent profile instead of relying on its automatic configuration based
> -  on existing flow rules.
> -
> -- A method to optimize *rte_flow* rules with specific pattern items and
> -  action types generated on the fly by PMDs. DPDK should assign negative
> -  numbers to these in order to not collide with the existing types. See
> -  `Negative types`_.
> -
> -- Adding specific egress pattern items and actions as described in
> -  `Attribute: Traffic direction`_.
> -
> -- Optional software fallback when PMDs are unable to handle requested
> flow
> -  rules so applications do not have to implement their own.
> 
>  .. _OpenFlow Switch Specification:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.opennetworking.org%2Fsoftware-defined-
> standards%2Fspecifications%2F&data=04%7C01%7Corika%40nvidia.com
> %7C5e9459a6e52c4e9b7e6e08d8f2d31458%7C43083d15727340c1b7db39efd9
> ccc17a%7C0%7C0%7C637526335691409134%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C1000&sdata=gj8TzUA%2Fo%2BsULeKO%2Fk5%2F7Z%2FAMyfrpe0
> yprqheQPeuAE%3D&reserved=0
> --
> 2.30.1

Acked-by: Ori Kam <orika at nvidia.com>
Thanks,
Ori