[dpdk-dev] [PATCH v3 00/19] net/mlx5: implement extensive metadata feature
Raslan Darawsheh
rasland at mellanox.com
Thu Nov 7 23:46:45 CET 2019
Hi,
> -----Original Message-----
> From: Viacheslav Ovsiienko <viacheslavo at mellanox.com>
> Sent: Thursday, November 7, 2019 7:10 PM
> To: dev at dpdk.org
> Cc: Matan Azrad <matan at mellanox.com>; Raslan Darawsheh
> <rasland at mellanox.com>; Thomas Monjalon <thomas at monjalon.net>; Ori
> Kam <orika at mellanox.com>; Yongseok Koh <yskoh at mellanox.com>
> Subject: [PATCH v3 00/19] net/mlx5: implement extensive metadata feature
>
> The modern networks operate on the base of the packet switching
> approach, and in-network environment data are transmitted as the packets.
> Within the host besides the data, actually transmitted on the wire as packets,
> there might some out-of-band data helping to process packets. These data
> are named as metadata, exist on a per-packet basis and are attached to each
> packet as some extra dedicated storage (in meaning it besides the packet
> data itself).
>
> In the DPDK network data are represented as mbuf structure chains and go
> along the application/DPDK datapath. From the other side, DPDK provides
> Flow API to control the flow engine. Being precise, there are two kinds of
> metadata in the DPDK, the one is purely software metadata (as fields of
> mbuf - flags, packet types, data length, etc.), and the other is metadata
> within flow engine.
> In this scope, we cover the second type (flow engine metadata) only.
>
> The flow engine metadata is some extra data, supported on the per-packet
> basis and usually handled by hardware inside flow engine.
>
> 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
> datapath.
>
> 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 is proposed.
>
> The next, applications raise the new requirements for packet metadata. The
> flow engines 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.
>
> Improving the metadata definitions it is proposed to:
> - suppose MARK and META metadata fields not shared, dedicated
> - extend applying area for MARK and META items/actions for all
> flow engine domains - transmitting and receiving
> - allow MARK and META metadata to be preserved while crossing
> the flow domains (from transmit origin through flow database
> inside (E-)switch to receiving side domain), in simple words,
> to allow metadata to convey the packet thought entire flow
> engine space.
>
> Another new proposed feature is transient per-packet storage inside the
> flow engine. It might have a lot of use cases.
> For example, if there is VXLAN tunneled traffic and some flow performs
> VXLAN decapsulation and wishes to save information regarding the dropped
> header it could use this temporary transient storage. The tools to maintain
> this storage are traditional (for DPDK rte_flow API):
>
> - RTE_FLOW_ACTION_TYPE_SET_TAG - to set value
> - RTE_FLOW_ACTION_TYPE_SET_ITEM - to match on
>
> There are primary properties of the proposed storage:
> - the storage is presented as an array of 32-bit opaque values
> - the size of array (or even bitmap of available indices) is
> vendor specific and is subject to run-time trial
> - it is transient, it means it exists only inside flow engine,
> no gateways for interacting with datapath, applications have
> way neither to specify these data on transmitting nor to get
> these data on receiving
>
> This patchset implements the abovementioned extensive metadata feature
> in the mlx5 PMD.
>
> The patchset must be applied after hashed list patch:
>
> [1]
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fpatch%2F62539%2F&data=02%7C01%7Crasland%40mell
> anox.com%7C104e9a22f43a4faace5108d763a55e70%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C637087434230552807&sdata=7xYZEaSke
> MCeBXDz8NRXKw7iMnBFzzf4Fb7%2FjYRJm3g%3D&reserved=0
>
> Signed-off-by: Yongseok Koh <yskoh at mellanox.com>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo at mellanox.com>
> Acked-by: Matan Azrad <matan at mellanox.com>
>
> ---
> v3: - moved missed part from isolated debug commit
> - rebased
>
> v2: -
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fcover%2F62579%2F&data=02%7C01%7Crasland%40mell
> anox.com%7C104e9a22f43a4faace5108d763a55e70%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C637087434230552807&sdata=2f9iQrJtTp9
> HqVAy%2BHANBfco%2BZsCAgd5Y8pI4iLPndE%3D&reserved=0
> - fix: metadata endianess
> - fix: infinite loop in header modify update routine
> - fix: reg_c_3 is reserved for split shared tag
> - fix: vport mask and value endianess
> - hash list implementation removed
> - rebased
>
> v1:
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fcover%2F62419%2F&data=02%7C01%7Crasland%40mell
> anox.com%7C104e9a22f43a4faace5108d763a55e70%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C637087434230552807&sdata=cV5lXlXExtZ
> CUPloJESwjqBlqrNyN4OI6OMUURKP2XI%3D&reserved=0
>
> Viacheslav Ovsiienko (19):
> net/mlx5: convert internal tag endianness
> net/mlx5: update modify header action translator
> net/mlx5: add metadata register copy
> net/mlx5: refactor flow structure
> net/mlx5: update flow functions
> net/mlx5: update meta register matcher set
> net/mlx5: rename structure and function
> net/mlx5: check metadata registers availability
> net/mlx5: add devarg for extensive metadata support
> net/mlx5: adjust shared register according to mask
> net/mlx5: check the maximal modify actions number
> net/mlx5: update metadata register id query
> net/mlx5: add flow tag support
> net/mlx5: extend flow mark support
> net/mlx5: extend flow meta data support
> net/mlx5: add meta data support to Rx datapath
> net/mlx5: introduce flow splitters chain
> net/mlx5: split Rx flows to provide metadata copy
> net/mlx5: add metadata register copy table
>
> doc/guides/nics/mlx5.rst | 49 +
> drivers/net/mlx5/mlx5.c | 150 ++-
> drivers/net/mlx5/mlx5.h | 19 +-
> drivers/net/mlx5/mlx5_defs.h | 8 +
> drivers/net/mlx5/mlx5_ethdev.c | 8 +-
> drivers/net/mlx5/mlx5_flow.c | 1201 ++++++++++++++++++++++-
> drivers/net/mlx5/mlx5_flow.h | 108 ++-
> drivers/net/mlx5/mlx5_flow_dv.c | 1566
> ++++++++++++++++++++++++------
> drivers/net/mlx5/mlx5_flow_verbs.c | 55 +-
> drivers/net/mlx5/mlx5_prm.h | 45 +-
> drivers/net/mlx5/mlx5_rxtx.c | 5 +
> drivers/net/mlx5/mlx5_rxtx_vec_altivec.h | 25 +-
> drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 23 +
> drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 27 +-
> 14 files changed, 2866 insertions(+), 423 deletions(-)
>
> --
> 1.8.3.1
Series applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
More information about the dev
mailing list