Hi, > -----Original Message----- > From: Viacheslav Ovsiienko <viachesl...@mellanox.com> > Sent: Thursday, November 7, 2019 7:10 PM > To: dev@dpdk.org > Cc: Matan Azrad <ma...@mellanox.com>; Raslan Darawsheh > <rasl...@mellanox.com>; Thomas Monjalon <tho...@monjalon.net>; Ori > Kam <or...@mellanox.com>; Yongseok Koh <ys...@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 <ys...@mellanox.com> > Signed-off-by: Viacheslav Ovsiienko <viachesl...@mellanox.com> > Acked-by: Matan Azrad <ma...@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
