[v6,1/2] rte_flow: add eCPRI key fields to flow API

Message ID 1594560903-313858-2-git-send-email-bingz@mellanox.com (mailing list archive)
State Accepted, archived
Delegated to: Ferruh Yigit
Headers
Series rte_flow: introduce eCPRI item for rte_flow |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Performance-Testing fail build patch failure
ci/Intel-compilation success Compilation OK
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-testing success Testing PASS

Commit Message

Bing Zhao July 12, 2020, 1:35 p.m. UTC
  Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.

eCPRI is a packet based protocol used in the fronthaul interface of
5G networks. Header format definition could be found in the
specification via the link below:
https://www.gigalight.com/downloads/standards/ecpri-specification.pdf

eCPRI message can be over Ethernet layer (.1Q supported also) or over
UDP layer. Message header formats are the same in these two variants.

Signed-off-by: Bing Zhao <bingz@mellanox.com>
Acked-by: Ori Kam <orika@mellanox.com>
---
v2: Add dw0 for the eCPRI common header to switch the endianess, and
    use fixed u32 value with big-endian for rte_flow_item_ecpri_mask.
    It is due to the fact that global variable only support constant
    expression in C when building.
v4: update release notes part.
v5: fix type#6 define, add event indication macros, and comments for
    revisions.
v6: 1. change the doxygen format into standard format
    2. change the members definition of 'struct rte_ecpri_common_hdr'
    3. fix the missing '^' in prog guide
    4. change the address define in type #4, removed '__packed__'
    5. change the name of 'rte_ecpri_msg_hdr'
       to 'rte_ecpri_combined_msg_hdr'
---
 doc/guides/prog_guide/rte_flow.rst     |   8 ++
 doc/guides/rel_notes/release_20_08.rst |   5 +
 lib/librte_ethdev/rte_flow.c           |   1 +
 lib/librte_ethdev/rte_flow.h           |  33 ++++++
 lib/librte_net/Makefile                |   1 +
 lib/librte_net/meson.build             |   3 +-
 lib/librte_net/rte_ecpri.h             | 183 +++++++++++++++++++++++++++++++++
 lib/librte_net/rte_ether.h             |   1 +
 8 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_net/rte_ecpri.h
  

Comments

Olivier Matz July 12, 2020, 2:45 p.m. UTC | #1
On Sun, Jul 12, 2020 at 09:35:02PM +0800, Bing Zhao wrote:
> Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.
> 
> eCPRI is a packet based protocol used in the fronthaul interface of
> 5G networks. Header format definition could be found in the
> specification via the link below:
> https://www.gigalight.com/downloads/standards/ecpri-specification.pdf
> 
> eCPRI message can be over Ethernet layer (.1Q supported also) or over
> UDP layer. Message header formats are the same in these two variants.
> 
> Signed-off-by: Bing Zhao <bingz@mellanox.com>
> Acked-by: Ori Kam <orika@mellanox.com>

Acked-by: Olivier Matz <olivier.matz@6wind.com>

Thanks!
  
Bing Zhao July 12, 2020, 2:50 p.m. UTC | #2
Many thanks for your big help.

BR. Bing

> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Sunday, July 12, 2020 10:46 PM
> To: Bing Zhao <bingz@mellanox.com>
> Cc: Ori Kam <orika@mellanox.com>; john.mcnamara@intel.com;
> marko.kovacevic@intel.com; Thomas Monjalon
> <thomas@monjalon.net>; ferruh.yigit@intel.com;
> arybchenko@solarflare.com; akhil.goyal@nxp.com; dev@dpdk.org;
> wenzhuo.lu@intel.com; beilei.xing@intel.com;
> bernard.iremonger@intel.com
> Subject: Re: [PATCH v6 1/2] rte_flow: add eCPRI key fields to flow API
> 
> On Sun, Jul 12, 2020 at 09:35:02PM +0800, Bing Zhao wrote:
> > Add a new item "rte_flow_item_ecpri" in order to match eCRPI
> header.
> >
> > eCPRI is a packet based protocol used in the fronthaul interface of 5G
> > networks. Header format definition could be found in the
> specification
> > via the link below:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > gigalight.com%2Fdownloads%2Fstandards%2Fecpri-
> specification.pdf&amp;da
> >
> ta=02%7C01%7Cbingz%40mellanox.com%7C5ffe8275a9594dfc6d9f08d
> 826724506%7
> >
> Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C6373016195227
> 27143&amp;sda
> >
> ta=%2BdY5DigE0mMLu7dOVl3OqPrVvquDLCKTtWI3M%2BSfK3A%3D&
> amp;reserved=0
> >
> > eCPRI message can be over Ethernet layer (.1Q supported also) or
> over
> > UDP layer. Message header formats are the same in these two
> variants.
> >
> > Signed-off-by: Bing Zhao <bingz@mellanox.com>
> > Acked-by: Ori Kam <orika@mellanox.com>
> 
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
> 
> Thanks!
  
Thomas Monjalon July 13, 2020, 12:50 a.m. UTC | #3
12/07/2020 16:45, Olivier Matz:
> On Sun, Jul 12, 2020 at 09:35:02PM +0800, Bing Zhao wrote:
> > Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.
> > 
> > eCPRI is a packet based protocol used in the fronthaul interface of
> > 5G networks. Header format definition could be found in the
> > specification via the link below:
> > https://www.gigalight.com/downloads/standards/ecpri-specification.pdf
> > 
> > eCPRI message can be over Ethernet layer (.1Q supported also) or over
> > UDP layer. Message header formats are the same in these two variants.
> > 
> > Signed-off-by: Bing Zhao <bingz@mellanox.com>
> > Acked-by: Ori Kam <orika@mellanox.com>
> 
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
> 
> Thanks!

Glad to see this 5G feature is ready to be merged in last minute of 20.08-rc1.

Applied, thanks
  
Ferruh Yigit July 13, 2020, 8:30 a.m. UTC | #4
On 7/13/2020 1:50 AM, Thomas Monjalon wrote:
> 12/07/2020 16:45, Olivier Matz:
>> On Sun, Jul 12, 2020 at 09:35:02PM +0800, Bing Zhao wrote:
>>> Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.
>>>
>>> eCPRI is a packet based protocol used in the fronthaul interface of
>>> 5G networks. Header format definition could be found in the
>>> specification via the link below:
>>> https://www.gigalight.com/downloads/standards/ecpri-specification.pdf
>>>
>>> eCPRI message can be over Ethernet layer (.1Q supported also) or over
>>> UDP layer. Message header formats are the same in these two variants.
>>>
>>> Signed-off-by: Bing Zhao <bingz@mellanox.com>
>>> Acked-by: Ori Kam <orika@mellanox.com>
>>
>> Acked-by: Olivier Matz <olivier.matz@6wind.com>
>>
>> Thanks!
> 
> Glad to see this 5G feature is ready to be merged in last minute of 20.08-rc1.
> 
> Applied, thanks
> 

Thanks Thomas for getting it.
  

Patch

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d5dd18c..3e5cd1e 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1362,6 +1362,14 @@  Matches a PFCP Header.
 - ``seid``: session endpoint identifier.
 - Default ``mask`` matches s_field and seid.
 
+Item: ``ECPRI``
+^^^^^^^^^^^^^^^
+
+Matches a eCPRI header.
+
+- ``hdr``: eCPRI header definition (``rte_ecpri.h``).
+- Default ``mask`` matches nothing, for all eCPRI messages.
+
 Actions
 ~~~~~~~
 
diff --git a/doc/guides/rel_notes/release_20_08.rst b/doc/guides/rel_notes/release_20_08.rst
index 3e07ee6..67888aa 100644
--- a/doc/guides/rel_notes/release_20_08.rst
+++ b/doc/guides/rel_notes/release_20_08.rst
@@ -205,6 +205,11 @@  New Features
   the  ``5tswap`` swaps source and destination in layers 2,3,4
   for ipv4 and ipv6 in L3 and UDP and TCP in L4.
 
+* **Added eCPRI protocol support in rte_flow.**
+
+  The ``ECPRI`` item have been added to support eCPRI packet offloading for
+  5G network.
+
 * **Added flow performance test application.**
 
   Added new application to test ``rte_flow`` performance, including:
diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
index 1685be5..f8fdd68 100644
--- a/lib/librte_ethdev/rte_flow.c
+++ b/lib/librte_ethdev/rte_flow.c
@@ -95,6 +95,7 @@  struct rte_flow_desc_data {
 	MK_FLOW_ITEM(HIGIG2, sizeof(struct rte_flow_item_higig2_hdr)),
 	MK_FLOW_ITEM(L2TPV3OIP, sizeof(struct rte_flow_item_l2tpv3oip)),
 	MK_FLOW_ITEM(PFCP, sizeof(struct rte_flow_item_pfcp)),
+	MK_FLOW_ITEM(ECPRI, sizeof(struct rte_flow_item_ecpri)),
 };
 
 /** Generate flow_action[] entry. */
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index b0e4199..da8bfa5 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -28,6 +28,7 @@ 
 #include <rte_byteorder.h>
 #include <rte_esp.h>
 #include <rte_higig.h>
+#include <rte_ecpri.h>
 #include <rte_mbuf.h>
 #include <rte_mbuf_dyn.h>
 
@@ -527,6 +528,15 @@  enum rte_flow_item_type {
 	 */
 	RTE_FLOW_ITEM_TYPE_PFCP,
 
+	/**
+	 * Matches eCPRI Header.
+	 *
+	 * Configure flow for eCPRI over ETH or UDP packets.
+	 *
+	 * See struct rte_flow_item_ecpri.
+	 */
+	RTE_FLOW_ITEM_TYPE_ECPRI,
+
 };
 
 /**
@@ -1547,6 +1557,29 @@  struct rte_flow_item_pfcp {
 #endif
 
 /**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_ECPRI
+ *
+ * Match eCPRI Header
+ */
+struct rte_flow_item_ecpri {
+	struct rte_ecpri_combined_msg_hdr hdr;
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_ECPRI. */
+#ifndef __cplusplus
+static const struct rte_flow_item_ecpri rte_flow_item_ecpri_mask = {
+	.hdr = {
+		.common = {
+			.u32 = 0x0,
+		},
+	},
+};
+#endif
+
+/**
  * Matching pattern item definition.
  *
  * A pattern is formed by stacking items starting from the lowest protocol
diff --git a/lib/librte_net/Makefile b/lib/librte_net/Makefile
index aa1d6fe..9830e77 100644
--- a/lib/librte_net/Makefile
+++ b/lib/librte_net/Makefile
@@ -20,5 +20,6 @@  SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_sctp.h rte_icmp.h rte_arp.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_gre.h rte_net.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_net_crc.h rte_mpls.h rte_higig.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_gtp.h rte_vxlan.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ecpri.h
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_net/meson.build b/lib/librte_net/meson.build
index f799349..24ed825 100644
--- a/lib/librte_net/meson.build
+++ b/lib/librte_net/meson.build
@@ -15,7 +15,8 @@  headers = files('rte_ip.h',
 	'rte_net.h',
 	'rte_net_crc.h',
 	'rte_mpls.h',
-	'rte_higig.h')
+	'rte_higig.h',
+	'rte_ecpri.h')
 
 sources = files('rte_arp.c', 'rte_ether.c', 'rte_net.c', 'rte_net_crc.c')
 deps += ['mbuf']
diff --git a/lib/librte_net/rte_ecpri.h b/lib/librte_net/rte_ecpri.h
new file mode 100644
index 0000000..d1c4838
--- /dev/null
+++ b/lib/librte_net/rte_ecpri.h
@@ -0,0 +1,183 @@ 
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#ifndef _RTE_ECPRI_H_
+#define _RTE_ECPRI_H_
+
+#include <stdint.h>
+#include <rte_byteorder.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*
+ * eCPRI Protocol Revision 1.0, 1.1, 1.2, 2.0: 0001b
+ * Other values are reserved for future
+ */
+#define RTE_ECPRI_REV_UP_TO_20		1
+
+/*
+ * eCPRI message types in specifications
+ * IWF* types will only be supported from rev.2
+ * 12-63: Reserved for future revision
+ * 64-255: Vendor Specific
+ */
+#define RTE_ECPRI_MSG_TYPE_IQ_DATA	0
+#define RTE_ECPRI_MSG_TYPE_BIT_SEQ	1
+#define RTE_ECPRI_MSG_TYPE_RTC_CTRL	2
+#define RTE_ECPRI_MSG_TYPE_GEN_DATA	3
+#define RTE_ECPRI_MSG_TYPE_RM_ACC	4
+#define RTE_ECPRI_MSG_TYPE_DLY_MSR	5
+#define RTE_ECPRI_MSG_TYPE_RMT_RST	6
+#define RTE_ECPRI_MSG_TYPE_EVT_IND	7
+#define RTE_ECPRI_MSG_TYPE_IWF_UP	8
+#define RTE_ECPRI_MSG_TYPE_IWF_OPT	9
+#define RTE_ECPRI_MSG_TYPE_IWF_MAP	10
+#define RTE_ECPRI_MSG_TYPE_IWF_DCTRL	11
+
+/*
+ * Event Type of Message Type #7: Event Indication
+ * 0x00: Fault(s) Indication
+ * 0x01: Fault(s) Indication Acknowledge
+ * 0x02: Notification(s) Indication
+ * 0x03: Synchronization Request
+ * 0x04: Synchronization Acknowledge
+ * 0x05: Synchronization End Indication
+ * 0x06...0xFF: Reserved
+ */
+#define RTE_ECPRI_EVT_IND_FAULT_IND	0x00
+#define RTE_ECPRI_EVT_IND_FAULT_ACK	0x01
+#define RTE_ECPRI_EVT_IND_NTFY_IND	0x02
+#define RTE_ECPRI_EVT_IND_SYNC_REQ	0x03
+#define RTE_ECPRI_EVT_IND_SYNC_ACK	0x04
+#define RTE_ECPRI_EVT_IND_SYNC_END	0x05
+
+/**
+ * eCPRI Common Header
+ */
+RTE_STD_C11
+struct rte_ecpri_common_hdr {
+	union {
+		rte_be32_t u32;			/**< 4B common header in BE */
+		struct {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+			uint32_t size:16;	/**< Payload Size */
+			uint32_t type:8;	/**< Message Type */
+			uint32_t c:1;		/**< Concatenation Indicator */
+			uint32_t res:3;		/**< Reserved */
+			uint32_t revision:4;	/**< Protocol Revision */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+			uint32_t revision:4;	/**< Protocol Revision */
+			uint32_t res:3;		/**< Reserved */
+			uint32_t c:1;		/**< Concatenation Indicator */
+			uint32_t type:8;	/**< Message Type */
+			uint32_t size:16;	/**< Payload Size */
+#endif
+		};
+	};
+};
+
+/**
+ * eCPRI Message Header of Type #0: IQ Data
+ */
+struct rte_ecpri_msg_iq_data {
+	rte_be16_t pc_id;		/**< Physical channel ID */
+	rte_be16_t seq_id;		/**< Sequence ID */
+};
+
+/**
+ * eCPRI Message Header of Type #1: Bit Sequence
+ */
+struct rte_ecpri_msg_bit_seq {
+	rte_be16_t pc_id;		/**< Physical channel ID */
+	rte_be16_t seq_id;		/**< Sequence ID */
+};
+
+/**
+ * eCPRI Message Header of Type #2: Real-Time Control Data
+ */
+struct rte_ecpri_msg_rtc_ctrl {
+	rte_be16_t rtc_id;		/**< Real-Time Control Data ID */
+	rte_be16_t seq_id;		/**< Sequence ID */
+};
+
+/**
+ * eCPRI Message Header of Type #3: Generic Data Transfer
+ */
+struct rte_ecpri_msg_gen_data {
+	rte_be32_t pc_id;		/**< Physical channel ID */
+	rte_be32_t seq_id;		/**< Sequence ID */
+};
+
+/**
+ * eCPRI Message Header of Type #4: Remote Memory Access
+ */
+RTE_STD_C11
+struct rte_ecpri_msg_rm_access {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+	uint32_t ele_id:16;		/**< Element ID */
+	uint32_t rr:4;			/**< Req/Resp */
+	uint32_t rw:4;			/**< Read/Write */
+	uint32_t rma_id:8;		/**< Remote Memory Access ID */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+	uint32_t rma_id:8;		/**< Remote Memory Access ID */
+	uint32_t rw:4;			/**< Read/Write */
+	uint32_t rr:4;			/**< Req/Resp */
+	uint32_t ele_id:16;		/**< Element ID */
+#endif
+	uint8_t addr[6];		/**< 48-bits address */
+	rte_be16_t length;		/**< number of bytes */
+};
+
+/**
+ * eCPRI Message Header of Type #5: One-Way Delay Measurement
+ */
+struct rte_ecpri_msg_delay_measure {
+	uint8_t msr_id;			/**< Measurement ID */
+	uint8_t act_type;		/**< Action Type */
+};
+
+/**
+ * eCPRI Message Header of Type #6: Remote Reset
+ */
+struct rte_ecpri_msg_remote_reset {
+	rte_be16_t rst_id;		/**< Reset ID */
+	uint8_t rst_op;			/**< Reset Code Op */
+};
+
+/**
+ * eCPRI Message Header of Type #7: Event Indication
+ */
+struct rte_ecpri_msg_event_ind {
+	uint8_t evt_id;			/**< Event ID */
+	uint8_t evt_type;		/**< Event Type */
+	uint8_t seq;			/**< Sequence Number */
+	uint8_t number;			/**< Number of Faults/Notif */
+};
+
+/**
+ * eCPRI Combined Message Header Format: Common Header + Message Types
+ */
+RTE_STD_C11
+struct rte_ecpri_combined_msg_hdr {
+	struct rte_ecpri_common_hdr common;
+	union {
+		struct rte_ecpri_msg_iq_data type0;
+		struct rte_ecpri_msg_bit_seq type1;
+		struct rte_ecpri_msg_rtc_ctrl type2;
+		struct rte_ecpri_msg_bit_seq type3;
+		struct rte_ecpri_msg_rm_access type4;
+		struct rte_ecpri_msg_delay_measure type5;
+		struct rte_ecpri_msg_remote_reset type6;
+		struct rte_ecpri_msg_event_ind type7;
+		rte_be32_t dummy[3];
+	};
+};
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_ECPRI_H_ */
diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index e942556..a358e88 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -307,6 +307,7 @@  struct rte_vlan_hdr {
 #define RTE_ETHER_TYPE_LLDP 0x88CC /**< LLDP Protocol. */
 #define RTE_ETHER_TYPE_MPLS 0x8847 /**< MPLS ethertype. */
 #define RTE_ETHER_TYPE_MPLSM 0x8848 /**< MPLS multicast ethertype. */
+#define RTE_ETHER_TYPE_ECPRI 0xAEFE /**< eCPRI ethertype (.1Q supported). */
 
 /**
  * Extract VLAN tag information into mbuf