Re: [dpdk-dev] [PATCH v5] ethdev: extend flow metadata

[Andrew Rybchenko <arybchenko@solarflare.com>]

On 10/29/19 10:31 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@mellanox.com>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

[snip]

> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index 4fee105..47b0220 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h

[snip]

> @@ -2662,6 +2728,32 @@ enum rte_flow_conv_op {
>   };
>   
>   /**
> + * Check if mbuf dynamic field for metadata is registered.
> + *
> + * @return
> + *   True if registered, false otherwise.
> + */
> +__rte_experimental
> +static inline int
> +rte_flow_dynf_metadata_avail(void) {

Wrong placement of function open curly bracket.

> +	return !!rte_flow_dynf_metadata_mask;
> +}
> +
> +/**
> + * Register mbuf dynamic field and flag for metadata.
> + *
> + * This function must be called prior to use SET_META action in order to
> + * register the dynamic mbuf field. Otherwise, the data cannot be delivered to
> + * application.
> + *
> + * @return
> + *   0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +__rte_experimental
> +int
> +rte_flow_dynf_metadata_register(void);
> +
> +/**
>    * Check whether a flow rule can be created on a given port.
>    *
>    * The flow rule is validated for correctness and whether it could be accepted
>