[PATCH] doc: fix typos and wording in flow API guide

[Ferruh Yigit]

On 7/3/2023 8:58 AM, Ali Alnubani wrote:
> This fixes typos, punctuation and wording in the rte flow API guide.
> 
> Fixes: 2f82d143fb31 ("ethdev: add group jump action")
> Cc: declan.doherty at intel.com
> Cc: stable at dpdk.org
> 
> Signed-off-by: Ali Alnubani <alialnu at nvidia.com>
> ---
>  doc/guides/prog_guide/rte_flow.rst | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 32fc45516a..6dbf5ef0a4 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -148,14 +148,14 @@ Attribute: Group
>  Flow rules can be grouped by assigning them a common group number. Groups
>  allow a logical hierarchy of flow rule groups (tables) to be defined. These
>  groups can be supported virtually in the PMD or in the physical device.
> -Group 0 is the default group and this is the only group which flows are
> -guarantee to matched against, all subsequent groups can only be reached by
> -way of the JUMP action from a matched flow rule.
> +Group 0 is the default group and is the only group where flows are
> +guaranteed to be matched against. All subsequent groups can only be reached by
> +using a JUMP action from a matched flow rule.
>  
>  Although optional, applications are encouraged to group similar rules as
>  much as possible to fully take advantage of hardware capabilities
>  (e.g. optimized matching) and work around limitations (e.g. a single pattern
> -type possibly allowed in a given group), while being aware that the groups
> +type possibly allowed in a given group), while being aware that the groups'
>  hierarchies must be programmed explicitly.
>  
>  Note that support for more than a single group is not guaranteed.
> @@ -170,7 +170,7 @@ Priority levels are arbitrary and up to the application, they do
>  not need to be contiguous nor start from 0, however the maximum number
>  varies between devices and may be affected by existing flow rules.
>  
> -A flow which matches multiple rules in the same group will always matched by
> +A flow which matches multiple rules in the same group will always be matched by
>  the rule with the highest priority in that group.
>  
>  If a packet is matched by several rules of a given group for a given
> @@ -1755,12 +1755,12 @@ flow group/tables on the device, this action redirects the matched flow to
>  the specified group on that device.
>  
>  If a matched flow is redirected to a table which doesn't contain a matching
> -rule for that flow then the behavior is undefined and the resulting behavior
> -is up to the specific device. Best practice when using groups would be define
> +rule for that flow, then the behavior is undefined and the resulting behavior
> +is up to the specific device. Best practice when using groups would be to define
>  a default flow rule for each group which a defines the default actions in that
>  group so a consistent behavior is defined.
>  
> -Defining an action for matched flow in a group to jump to a group which is
> +Defining an action for a matched flow in a group to jump to a group which is
>  higher in the group hierarchy may not be supported by physical devices,
>  depending on how groups are mapped to the physical devices. In the
>  definitions of jump actions, applications should be aware that it may be
>

Hi John, Can you please help reviewing this patch?