[dpdk-dev] [PATCH v6 1/2] ethdev: extend flow metadata

Andrew Rybchenko arybchenko at solarflare.com
Thu Oct 31 10:19:25 CET 2019


On 10/30/19 8:12 PM, Viacheslav Ovsiienko wrote:
> Currently, metadata can be set on egress path via mbuf tx_metadata field
> with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META matches metadata.
>
> This patch extends the metadata feature usability.
>
> 1) RTE_FLOW_ACTION_TYPE_SET_META
>
> When supporting multiple tables, Tx metadata can also be set by a rule and
> matched by another rule. This new action allows metadata to be set as a
> result of flow match.
>
> 2) Metadata on ingress
>
> There's also need to support metadata on ingress. Metadata can be set by
> SET_META action and matched by META item like Tx. The final value set by
> the action will be delivered to application via metadata dynamic field of
> mbuf which can be accessed by RTE_FLOW_DYNF_METADATA() macro or with
> rte_flow_dynf_metadata_set() and rte_flow_dynf_metadata_get() helper
> routines. PKT_RX_DYNF_METADATA flag will be set along with the data.
>
> The mbuf dynamic field must be registered by calling
> rte_flow_dynf_metadata_register() prior to use SET_META action.
>
> The availability of dynamic mbuf metadata field can be checked
> with rte_flow_dynf_metadata_avail() routine.
>
> If application is going to engage the metadata feature it registers
> the metadata  dynamic fields, then PMD checks the metadata field
> availability and handles the appropriate fields in datapath.
>
> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> propagated to the other path depending on hardware capability.
>
> MARK and METADATA look similar and might operate in similar way,
> but not interacting.
>
> Initially, there were proposed two metadata related actions:
>
> - RTE_FLOW_ACTION_TYPE_FLAG
> - RTE_FLOW_ACTION_TYPE_MARK
>
> These actions set the special flag in the packet metadata, MARK action
> stores some specified value in the metadata storage, and, on the packet
> receiving PMD puts the flag and value to the mbuf and applications can
> see the packet was threated inside flow engine according to the appropriate
> RTE flow(s). MARK and FLAG are like some kind of gateway to transfer some
> per-packet information from the flow engine to the application via
> receiving datapath. Also, there is the item of type RTE_FLOW_ITEM_TYPE_MARK
> provided. It allows us to extend the flow match pattern with the capability
> to match the metadata values set by MARK/FLAG actions on other flows.
>
>  From the datapath point of view, the MARK and FLAG are related to the
> receiving side only. It would useful to have the same gateway on the
> transmitting side and there was the feature of type RTE_FLOW_ITEM_TYPE_META
> was proposed. The application can fill the field in mbuf and this value
> will be transferred to some field in the packet metadata inside the flow
> engine. It did not matter whether these metadata fields are shared because
> of MARK and META items belonged to different domains (receiving and
> transmitting) and could be vendor-specific.
>
> So far, so good, DPDK proposes some entities to control metadata inside
> the flow engine and gateways to exchange these values on a per-packet basis
> via datapaths.
>
> As we can see, the MARK and META means are not symmetric, there is absent
> action which would allow us to set META value on the transmitting path.
> So, the action of type:
>
> - RTE_FLOW_ACTION_TYPE_SET_META was proposed.
>
> The next, applications raise the new requirements for packet metadata.
> The flow ngines are getting more complex, internal switches are introduced,
> multiple ports might be supported within the same flow engine namespace.
>  From the DPDK points of view, it means the packets might be sent on one
> eth_dev port and received on the other one, and the packet path inside
> the flow engine entirely belongs to the same hardware device. The simplest
> example is SR-IOV with PF, VFs and the representors. And there is a
> brilliant opportunity to provide some out-of-band channel to transfer
> some extra data from one port to another one, besides the packet data
> itself. And applications would like to use this opportunity.
>
> It is supposed for application to use trials (with rte_flow_validate)
> to detect which metadata features (FLAG, MARK, META) actually supported
> by PMD and underlying hardware. It might depend on PMD configuration,
> system software, hardware settings, etc., and should be detected
> in run time.
>
> Signed-off-by: Yongseok Koh <yskoh at mellanox.com>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo at mellanox.com>

It is good enough as an experimental feature to try how it goes, so

Acked-by: Andrew Rybchenko <arybchenko at solarflare.com>



More information about the dev mailing list