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

[Ajit Khaparde <ajit.khaparde@broadcom.com>]

Gregory,

[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?

[snip]