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.dohe...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ali Alnubani <alia...@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?
