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

[Thomas Monjalon <thomas@monjalon.net>]

02/03/2021 10:22, Ivan Malov:
> 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?
> 
>  > 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?
> 
> Thank you.

Given the questions, I think the discussion should be concluded
(when done) with a patch updating the API description.
Thanks for the questions and clarifications to come :)