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

[Ori Kam <orika@mellanox.com>]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Viacheslav Ovsiienko
> Sent: Tuesday, October 29, 2019 9:32 PM
> To: dev@dpdk.org
> Cc: Matan Azrad <matan@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>; Thomas Monjalon <thomas@monjalon.net>;
> olivier.matz@6wind.com; arybchenko@solarflare.com; Yongseok Koh
> <yskoh@mellanox.com>
> Subject: [dpdk-dev] [PATCH v5] ethdev: extend flow metadata
> 
> 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>
> ---
> v5: - addressed code style issues from comments
>     - Tx metadata deprecation notice removed
>       (dedicated tx_metadata patch is coming)
>     - MBUF_DYNF_METADATA_NAME is splitted into FIELD and FLAG
>       dedicated ones, RTE suffix is added
>     - metadata historic retrospective is added to log message
>     - rebased
> 
> v4: -
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatches.dp
> dk.org%2Fpatch%2F62065%2F&amp;data=02%7C01%7Corika%40mellanox.com
> %7Cc179230aa76b4847b6d708d75ca6a727%7Ca652971c7d2e4d9ba6a4d14925
> 6f461b%7C0%7C0%7C637079743167838838&amp;sdata=KEb4Vy%2Fr9Y%2BVh
> FZHqeo7ZOzO5Tphrk5gwRiwLA%2BSPPc%3D&amp;reserved=0
>     - documentation comments addressed
>     - deprecation notice for Tx metadata offload flag
>     - rebased
> 
> v3: -
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatches.dp
> dk.org%2Fpatch%2F61902%2F&amp;data=02%7C01%7Corika%40mellanox.com
> %7Cc179230aa76b4847b6d708d75ca6a727%7Ca652971c7d2e4d9ba6a4d14925
> 6f461b%7C0%7C0%7C637079743167838838&amp;sdata=IuMDbqwUdKhpkkJNy
> aLsBEqtQnQIYLD%2BPUTKx%2BuBb6o%3D&amp;reserved=0
>     - rebased, neat updates
> 
> v2: -
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatches.dp
> dk.org%2Fpatch%2F60909%2F&amp;data=02%7C01%7Corika%40mellanox.com
> %7Cc179230aa76b4847b6d708d75ca6a727%7Ca652971c7d2e4d9ba6a4d14925
> 6f461b%7C0%7C0%7C637079743167838838&amp;sdata=IRxJ5TA2b%2BLjw3ud
> WUNweQbqzjELEtnr1tcAzUZrB94%3D&amp;reserved=0
> 
> v1: -
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatches.dp
> dk.org%2Fpatch%2F56104%2F&amp;data=02%7C01%7Corika%40mellanox.com
> %7Cc179230aa76b4847b6d708d75ca6a727%7Ca652971c7d2e4d9ba6a4d14925
> 6f461b%7C0%7C0%7C637079743167838838&amp;sdata=3gmQwKhk0cZMUdy
> NI9aQtQkxkzWZUpLDdt5rkPz9AzY%3D&amp;reserved=0
>     - rfc:
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatches.dp
> dk.org%2Fpatch%2F54271%2F&amp;data=02%7C01%7Corika%40mellanox.com
> %7Cc179230aa76b4847b6d708d75ca6a727%7Ca652971c7d2e4d9ba6a4d14925
> 6f461b%7C0%7C0%7C637079743167838838&amp;sdata=20Bz7wbiDCYqccY0M
> NQm0OFuM9KqX017l7KnXeWhWlQ%3D&amp;reserved=0
> 
> 

Acked-by: Ori Kam <orika@mellanox.com>
Thanks,
Ori