[dpdk-dev] [PATCH 0/2] ethdev: tunnel offload model
Andrew Rybchenko
arybchenko at solarflare.com
Sun Jul 5 15:39:54 CEST 2020
On 6/25/20 7:03 PM, Gregory Etelson wrote:
> Hardware vendors implement tunneled traffic offload techniques
> differently. Although RTE flow API provides tools capable to offload
> all sorts of network stacks, software application must reference this
> hardware differences in flow rules compilation. As the result tunneled
> traffic flow rules that utilize hardware capabilities can be different
> for the same traffic.
>
> Tunnel port offload proposed in [1] provides software application with
> unified rules model for tunneled traffic regardless underlying
> hardware.
> - The model introduces a concept of a virtual tunnel port (VTP).
> - The model uses VTP to offload ingress tunneled network traffic
> with RTE flow rules.
> - The model is implemented as set of helper functions. Each PMD
> implements VTP offload according to underlying hardware offload
> capabilities. Applications must query PMD for VTP flow
> items / actions before using in creation of a VTP flow rule.
>
> The model components:
> - Virtual Tunnel Port (VTP) is a stateless software object that
> describes tunneled network traffic. VTP object usually contains
> descriptions of outer headers, tunnel headers and inner headers.
> - Tunnel Steering flow Rule (TSR) detects tunneled packets and
> delegates them to tunnel processing infrastructure, implemented
> in PMD for optimal hardware utilization, for further processing.
> - Tunnel Matching flow Rule (TMR) verifies packet configuration and
> runs offload actions in case of a match.
>
> Application actions:
> 1 Initialize VTP object according to tunnel
> network parameters.
> 2 Create TSR flow rule:
> 2.1 Query PMD for VTP actions: application can query for VTP actions
> more than once
> int
> rte_flow_tunnel_decap_set(uint16_t port_id,
> struct rte_flow_tunnel *tunnel,
> struct rte_flow_action **pmd_actions,
> uint32_t *num_of_pmd_actions,
> struct rte_flow_error *error);
>
> 2.2 Integrate PMD actions into TSR actions list.
> 2.3 Create TSR flow rule:
> flow create <port> group 0
> match {tunnel items} / end
> actions {PMD actions} / {App actions} / end
>
> 3 Create TMR flow rule:
> 3.1 Query PMD for VTP items: application can query for VTP items
> more than once
> int
> rte_flow_tunnel_match(uint16_t port_id,
> struct rte_flow_tunnel *tunnel,
> struct rte_flow_item **pmd_items,
> uint32_t *num_of_pmd_items,
> struct rte_flow_error *error);
>
> 3.2 Integrate PMD items into TMR items list:
> 3.3 Create TMR flow rule
> flow create <port> group 0
> match {PMD items} / {APP items} / end
> actions {offload actions} / end
>
> The model provides helper function call to restore packets that miss
> tunnel TMR rules to its original state:
> int
> rte_flow_get_restore_info(uint16_t port_id,
> struct rte_mbuf *mbuf,
> struct rte_flow_restore_info *info,
> struct rte_flow_error *error);
>
> rte_tunnel object filled by the call inside
> rte_flow_restore_info *info parameter can be used by the application
> to create new TMR rule for that tunnel.
>
> The model requirements:
> Software application must initialize
> rte_tunnel object with tunnel parameters before calling
> rte_flow_tunnel_decap_set() & rte_flow_tunnel_match().
>
> PMD actions array obtained in rte_flow_tunnel_decap_set() must be
> released by application with rte_flow_action_release() call.
> Application can release the actionsfter TSR rule was created.
>
> PMD items array obtained with rte_flow_tunnel_match() must be released
> by application with rte_flow_item_release() call. Application can
> release the items after rule was created. However, if the application
> needs to create additional TMR rule for the same tunnel it will need
> to obtain PMD items again.
>
> Application cannot destroy rte_tunnel object before it releases all
> PMD actions & PMD items referencing that tunnel.
>
> [1] https://mails.dpdk.org/archives/dev/2020-June/169656.html
Three copies of the above text here, in 2/2 description and 2/2
content in DPDK documentation is too much. IMHO, it should only
one place in the documentation with brief summary in
patch/series description.
More information about the dev
mailing list