Re: [dpdk-dev] [PATCH v4 2/4] ethdev: tunnel offload model

[Gregory Etelson <getelson@nvidia.com>]

Hello Feruh,

> Subject: Re: [dpdk-dev] [PATCH v4 2/4] ethdev: tunnel offload model
> 
> External email: Use caution opening links or attachments
> 
> 
> On 10/7/2020 1:36 PM, Gregory Etelson wrote:
> > Hello Harsha,
> >
> >> -----Original Message-----
> >
> > [snip]
> >>
> >> Tunnel vport is an internal construct used by one specific
> >> application: OVS. So, shouldn't the rte APIs also be application
> >> agnostic apart from being vendor agnostic ? For OVS, the match fields
> >> in the existing datapath flow rules contain enough information to
> >> identify the tunnel type.
> >
> > Tunnel offload model was inspired by OVS vport, but it is not part of
> the existing API.
> > It looks like the API documentation should not use that term to avoid
> confusion.
> >
> > [snip]
> >
> > [snip]
> >>
> >> Wouldn't it be better if the APIs do not refer to vports and avoid
> >> percolating it down to the PMD ? My point here is to avoid bringing in
> >> the knowledge of an application specific virtual object (vport) to the
> >> PMD.
> >>
> >
> > As I have mentioned above, the API description should not mention vport.
> > I'll post updated documents.
> >
> >> Here's some other issues that I see with the helper APIs and
> >> vendor-specific variable actions.
> >> 1) The application needs some kind of validation (or understanding) of
> >> the actions returned by the PMD. The application can't just blindly
> >> use the actions specified by the PMD. That is, the decision to pick
> >> the set of actions can't be left entirely to the PMD.
> >> 2) The application needs to learn a PMD-specific way of action
> >> processing for each vendor. For example, how should the application
> >> handle flow-miss, given a different set of actions between two vendors
> >> (if one vendor has already popped the tunnel header while the other
> >> one hasn't).
> >> 3) The end-users/customers won't have a common interface (as in,
> >> consistent actions) to perform tunnel decap action. This becomes a
> >> manageability/maintenance issue for the application while working with
> >> different vendors.
> >>
> >> IMO, the API shouldn't expect the PMD to understand the notion of
> >> vport. The goal here is to offload a flow rule to decap the tunnel
> >> header and forward the packet to a HW endpoint.  The problem is that
> >> we don't have a way to express the "tnl_pop" datapath action to the HW
> >> (decap flow #1, in the context of br-phy in OVS-DPDK) and also we may
> >> not want the HW to really pop the tunnel header at that stage. If this
> >> cannot be expressed with existing rte action types, maybe we should
> >> introduce a new action that clearly defines what is expected to the
> >> PMD.
> >
> > Tunnel Offload API provides a common interface for all HW vendors:
> > Rule #1: define a tunneled traffic and steer / group traffic related to
> > that tunnel
> > Rule #2: within the tunnel selection, run matchers on all packet
> headers,
> > outer and inner, and perform actions on inner headers in case of a
> match.
> > For the rule #1 application provides tunnel matchers and traffic
> selection actions
> > and for rule #2 application provides full header matchers and actions
> for inner parts.
> > The rest is supplied by PMD according to HW and rule type. Application
> does not
> > need to understand exact PMD elements implementation.
> > Helper return value notifies application whether it received requested
> PMD elements or not.
> > If helper completed successfully, it means that application received
> required elements
> > and can complete flow rule compilation.
> > As the result, a packet will be fully offloaded or returned to
> application with enough
> > information to continue processing in SW.
> >
> > [snip]
> >
> > [snip]
> >
> >>> Miss handling
> >>> -------------
> >>> Packets going through multiple rte_flow groups are exposed to hw
> >>> misses due to partial packet processing. In such cases, the software
> >>> should continue the packet's processing from the point where the
> >>> hardware missed.
> >>
> >> Whether the packet goes through multiple groups or not for tunnel
> >> decap processing, should be left to the PMD/HW.  These assumptions
> >> shouldn't be built into the APIs. The encapsulated packet (i,e with
> >> outer headers) should be provided to the application, rather than
> >> making SW understand that there was a miss in stage-1, or stage-n in
> >> HW. That is, HW either processes it entirely, or punts the whole
> >> packet to SW if there's a miss. And the packet should take the normal
> >> processing path in SW (no action offload).
> >>
> >> Thanks,
> >> -Harsha
> >
> > The packet is provided to the application via the standard
> rte_eth_rx_burst API.
> > Additional information about the HW packet processing state is provided
> to
> > the application by the suggested rte_flow_get_restore_info API. It is up
> to the
> > application if to use such provided info, or even if to call this API at
> all.
> >
> > [snip]
> >
> > Regards,
> > Gregory
> >
> 
> 
> Hi Gregory, Sriharsha,
> 
> Is there any output of the discussion?

Tunnel API documentation was updated in V6.

Regards,
Gregory