On 3/3/2021 4:03 PM, Ivan Malov wrote:

Hi,

Could someone please also clarify the meaning (from PMD standpoint and 
from application's standpoint) of the 64-bit field "tun_id" in 
"rte_flow_tunnel"? The current comment reads: "Tunnel identification", 
which is quite ambiguous, not to mention the fact that it simply 
expands the field's name. Does this ID have anything to do with 
VXLAN's VNI (which is 24-bit field)?

rte_flow_tunnel struct is the tunnel details communicated between the 
application and PMD when applying flows, and from the PMD to the 
application upon miss.

The fields in it are porting of the kernel's 'struct ip_tunnel_key'. See 
https://elixir.bootlin.com/linux/latest/source/include/net/ip_tunnels.h#L40

Regarding 'tun_id' - yes. In case of VXLAN tunnel it stores the VNI.

As far as I can learn from the testpmd patch series, this field gets 
printed only if it's non-zero. Hmm. A special value of sorts? Maybe 
clarify this, too?

Thank you.

On 02/03/2021 12:42, Thomas Monjalon wrote:

quoted

02/03/2021 10:22, Ivan Malov:

quoted

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 :)