Re: [dpdk-dev] [PATCH v3 4/4] app/testpmd: add commands for tunnel offload API

[Gregory Etelson <getelson@nvidia.com>]

Hello Ajit,

> [snip]
> > > > testpmd> flow tunnel 0 type vxlan
> > > > port 0: flow tunnel #1 type vxlan
> > > > testpmd> flow create 0 ingress group 0 tunnel_set 1
> > > >          pattern eth /ipv4 / udp dst is 4789 / vxlan / end
> > > >          actions  jump group 0 / end
> > >
> > > I could not get enough time to completely look at this.
> > > Can you help understand the sequence a bit.
> > >
> > > So when this flow create is issued, it looks like the application issues
> > > one of the helper APIs.
> > > In response the PMD returns the vendor specific items/actions.
> > > So what happens to the original match and action criteria provided by the
> > > user
> > > or applications?
> > >
> > > Does the vendor provided actions and items in the tunnel descriptor
> > > take precedence over what was used by the application?
> > >
> > > And is the criteria provided by the PMD opaque to the application?
> > > Such that only the PMD can decipher it when the application calls it
> > > for subsequent flow create(s)?
> > >
> >
> > Flow rules that implement tunnel offload API are compiled from application
> and
> > PMD actions and items. Both application and PMD elements are equally
> important
> > for offload rule creation. Application is "aware" what type of tunnel offload
> > flow rule, decap_set or match, it builds. Therefore, application elements
> are
> > created according to tunnel offload rule type and the API helper function,
> that
> > matches selected rule type, is activated to provide PMD elements.
> > PMD elements are opaque. When all elements are present, application
> concatenates
> > PMD items with application items and PMD actions with application
> actions.
> > As the result application will have pattern & actions arrays for flow rule
> > creation. For the decap_set rule, the API expects application to provide
> pattern
> > that describes a tunnel and the JUMP action, although the JUMP is not
> strictly
> > required. And for the match rule, application pattern should describe
> packet
> > headers and actions refer to inner parts.
> Since the application concatenates the elements provided by the PMD with
> that of its own, the PMD is free to validate, parse and use a subset
> or all of them?
> 

Concatenated array must provide enough information for PMD to build a rule.
Application RTE elements describe flow and flow actions while PMD elements are
about internal PMD hardware offload and restore after partial miss . PMD uses all
application elements, but it may skip internal elements, depending on
implementation.

> [snip]