[dpdk-dev] [PATCH v8 2/3] ethdev: tunnel offload model
Thomas Monjalon
thomas at monjalon.net
Tue Mar 2 10:42:09 CET 2021
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 :)
More information about the dev
mailing list