Re: [dpdk-dev] [PATCH v8 2/3] ethdev: tunnel offload model

[Gregory Etelson <getelson@nvidia.com>]

Hello,

Please find my answers below.

Regards,
Gregory

> External email: Use caution opening links or attachments
> 
> 
> Hi Gregory, Eli,
> 
> On 16/10/2020 15:51, Gregory Etelson wrote:
>  > Applications wishing to offload tunneled traffic are required to use  > the
> rte_flow primitives, such as group, meta, mark, tag, and others to  > model
> their high-level objects.  The hardware model design for
> 
> As far as I understand, the model is an abstraction of sorts, and the quoted
> lines provide examples of primitives which applications would have to use if
> the model did not exist.
> 
> Looking at the implementation, I don't quite discern any means to let the
> application query PMD-specific values of "rte_flow_attr". In example, the
> PMD may need to enforce "transfer=1" both for the "tunnel set" rule and
> for "tunnel match" one. What if "group" and "priority"
> values also need to be implicitly controlled by the PMD for the tunnel
> offload rules?
> 
> Have you considered adding an abstraction for "rte_flow_attr" in terms of
> this model?
> 


Tunnel offload introduces application model to recover packet outer headers
after partial miss. We were able to build the model with addition of
rte_flow_tunnel_decap_set & rte_flow_tunnel_match functions only. Please note, 
that except from returning private flow rule elements, these functions can provide
internal PMD hints on tunnel flow rules processing. PMD can use these hints with
addition of private PMD rule elements to modify any part of incoming tunnel flow
rule - attributes, items or actions, to implement the model according
to hardware specifications.

>  > The first VXLAN packet that arrives matches the rule in group 0 and  >
> jumps to group 3.  In group 3 the packet will miss since there is no
> 
> This example considers jumping from group 0 to group 3. First of all, it's
> unclear whether this model intentionally lets the application choose group
> values freely (see my question above) or simply lacks an interface to let the
> application use values enforced by the PMD (if any). Secondly, given the fact
> that existing description of "rte_flow_attr" does not shed any light on how
> groups are ordered by default, when no JUMPs are configured (it only
> explains how priority levels are ordered within the given group but not how
> groups are ordered), it's unclear whether the model intentionally permits
> the application to jump between arbitrary groups (in example, from 0 to 3)
> and not necessarily between, say, 0 to 1. More to that, it's unclear whether
> the model lets the application jump from, say, group 0 to the very same
> group, 0 ("recirculation") or not. Or is the "recirculation"
> is in fact the main scenario in the model? Could you please elaborate on the
> model's expectations of groups?
> 

The model has no limitation on application group selection.
Application can use any group value in jump action destination,
including the same one as was used for flow creation.

> Thank you.
> 
> --
> Ivan M