Hi Thomas, > -----Original Message----- > From: Thomas Monjalon <tho...@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 <tho...@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 <or...@nvidia.com> Thanks, Ori
