support match on L3 fragmented packets
cover support match on L3 fragmented packets
This series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
In MLX5 PMD, support match on IPv4 fragmented packets, IPv6 fragmented packets, and IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
Dekel Peled (10):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item net/mlx5: remove handling of ICMP fragmented packets net/mlx5: support match on IPv4 fragment packets net/mlx5: support match on IPv6 fragment packets net/mlx5: support match on IPv6 fragment ext. item
doc: update release notes for MLX5 L3 frag support
app/test-pmd/cmdline_flow.c | 53 +++++ doc/guides/prog_guide/rte_flow.rst | 28 ++- doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/mlx5/mlx5_flow.c | 48 +++-- drivers/net/mlx5/mlx5_flow.h | 14 ++ drivers/net/mlx5/mlx5_flow_dv.c | 382 +++++++++++++++++++++++++++++---- drivers/net/mlx5/mlx5_flow_verbs.c | 9 +- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 46 +++- lib/librte_ip_frag/rte_ip_frag.h | 26 +-- lib/librte_net/rte_ip.h | 26 ++- 11 files changed, 555 insertions(+), 88 deletions(-)
Signature · 1 line
1.8.3.1
PATCH 1/10 ethdev: add extensions attributes to IPv6 item
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- doc/guides/prog_guide/rte_flow.rst | 16 +++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 36 insertions(+), 5 deletions(-)
doc/guides/prog_guide/rte_flow.rst +13 -3
@@ -946,11 +946,21 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension header exists. +- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.h +23 -2
@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH 01/10] ethdev: add extensions attributes to IPv6 item
Quoted 40 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, September 30, 2020 5:10 PM
Subject: [PATCH 01/10] ethdev: add extensions attributes to IPv6 itemUsing the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header.[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dp
dk.org%2Farchives%2Fdev%2F2020- August%2F177257.html&data=02%7C01%7Corika%40nvidia.com%7C5a12 16c396994e296ce308d8654aa25a%7C43083d15727340c1b7db39efd9ccc17a%7 C0%7C1%7C637370718505729468&sdata=ym5QBAFHOsuNfcKxhc%2Fj60B ojpD%2B5G1mvUuYAxKZP6k%3D&reserved=0
Quoted 2 lines
Signed-off-by Dekel Peled <[email protected]>---
Thanks,
Ori
PATCH 2/10 ethdev: add IPv6 fragment extension header item
In reply to Dekel PeledApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].
Relevant definitions are moved from lib/librte_ip_frag/rte_ip_frag.h to lib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. struct ipv6_extension_fragment renamed to rte_ipv6_fragment_ext to adapt it to the common naming convention.
Default mask is not defined, since all fields are optional.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++-- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 21 +++++++++++++++++++++ lib/librte_ip_frag/rte_ip_frag.h | 26 ++------------------------ lib/librte_net/rte_ip.h | 26 ++++++++++++++++++++++++-- 5 files changed, 62 insertions(+), 28 deletions(-)
doc/guides/prog_guide/rte_flow.rst +14 -2
@@ -947,8 +947,8 @@ Item: ``IPV6`` Matches an IPv6 header. Dedicated flags indicate existence of specific extension headers. -Every type of extension header can use a dedicated pattern item, or -the generic `Item: IPV6_EXT`_. +Every type of extension header can use a dedicated pattern item, +for example `Item: IPV6_FRAG_EXT`_, or the generic `Item: IPV6_EXT`_. - ``hdr``: IPv6 header definition (``rte_ip.h``). - ``hop_ext_exist``: Hop-by-Hop Options extension header exists.
@@ -1187,6 +1187,18 @@ Normally preceded by any of: - `Item: IPV6`_ - `Item: IPV6_EXT`_ +Item: ``IPV6_FRAG_EXT`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Matches the presence of IPv6 fragment extension header. + +- ``hdr``: IPv6 fragment extension header definition (``rte_ip.h``). + +Normally preceded by any of: + +- `Item: IPV6`_ +- `Item: IPV6_EXT`_ + Item: ``ICMP6`` ^^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.c +1 -0
@@ -72,6 +72,7 @@ struct rte_flow_desc_data {MK_FLOW_ITEM (VXLAN_GPE ,sizeof (struct rte_flow_item_vxlan_gpe )),MK_FLOW_ITEM (ARP_ETH_IPV4 ,sizeof (struct rte_flow_item_arp_eth_ipv4 )),MK_FLOW_ITEM (IPV6_EXT ,sizeof (struct rte_flow_item_ipv6_ext )), +MK_FLOW_ITEM (IPV6_FRAG_EXT ,sizeof (struct rte_flow_item_ipv6_frag_ext )),MK_FLOW_ITEM (ICMP6 ,sizeof (struct rte_flow_item_icmp6 )),MK_FLOW_ITEM (ICMP6_ND_NS ,sizeof (struct rte_flow_item_icmp6_nd_ns )), MK_FLOW_ITEM(ICMP6_ND_NA, sizeof(struct rte_flow_item_icmp6_nd_na)),
lib/librte_ethdev/rte_flow.h +21 -0
@@ -368,6 +368,13 @@ enum rte_flow_item_type {RTE_FLOW_ITEM_TYPE_IPV6_EXT ,/** +* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, + +/** * Matches any ICMPv6 header. * * See struct rte_flow_item_icmp6.
@@ -1188,6 +1195,20 @@ struct rte_flow_item_ipv6_ext rte_flow_item_ipv6_ext_mask = {#endif /** +* RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT +* +* Matches the presence of IPv6 fragment extension header. +* +* Preceded by any of: +* +* - RTE_FLOW_ITEM_TYPE_IPV6 +* - RTE_FLOW_ITEM_TYPE_IPV6_EXT +*/ +struct rte_flow_item_ipv6_frag_ext { +struct rte_ipv6_fragment_ext hdr; +}; + +/** * RTE_FLOW_ITEM_TYPE_ICMP6 * * Matches any ICMPv6 header.
lib/librte_ip_frag/rte_ip_frag.h +2 -24
@@ -110,30 +110,8 @@ struct rte_ip_frag_tbl { __extension__struct ip_frag_pkt pkt[0 ];/**< hash table. */ }; -/** IPv6 fragment extension header */ -#define RTE_IPV6_EHDR_MF_SHIFT 0 -#define RTE_IPV6_EHDR_MF_MASK 1 -#define RTE_IPV6_EHDR_FO_SHIFT 3 -#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) -#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_FRAG_USED_MASK \ - (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) - -#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) -#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ - (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) - -struct ipv6_extension_fragment { -uint8_t next_header;/**< Next header type */ -uint8_t reserved;/**< Reserved */ -uint16_t frag_data;/**< All fragmentation data */ -uint32_t id;/**< Packet ID */ -} __rte_packed; - - +/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */ +#define ipv6_extension_fragment rte_ipv6_fragment_ext/** * Create a new IP fragmentation table.
lib/librte_net/rte_ip.h +24 -2
@@ -456,8 +456,30 @@ struct rte_ipv6_hdr {return (uint16_t )cksum; } -/* IPv6 fragmentation header size */ -#define RTE_IPV6_FRAG_HDR_SIZE 8 +/** IPv6 fragment extension header. */ +#define RTE_IPV6_EHDR_MF_SHIFT 0 +#define RTE_IPV6_EHDR_MF_MASK 1 +#define RTE_IPV6_EHDR_FO_SHIFT 3 +#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) +#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_FRAG_USED_MASK (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) + +#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) +#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ + (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) + +struct rte_ipv6_fragment_ext { +uint8_t next_header;/**< Next header type */ +uint8_t reserved;/**< Reserved */ +rte_be16_t frag_data;/**< All fragmentation data */ +rte_be32_t id;/**< Packet ID */ +} __rte_packed; + +/* IPv6 fragment extension header size */ +#define RTE_IPV6_FRAG_HDR_SIZE sizeof(struct rte_ipv6_fragment_ext)/** * Parse next IPv6 header extension
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH 02/10] ethdev: add IPv6 fragment extension header item
Quoted 213 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, September 30, 2020 5:10 PM
Subject: [PATCH 02/10] ethdev: add IPv6 fragment extension header itemApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].Relevant definitions are moved from
lib/librte_ip_frag/rte_ip_frag.htolib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. structipv6_extension_fragmentrenamed torte_ipv6_fragment_extto adapt it to the common naming convention.Default mask is not defined, since all fields are optional.
[1]
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpd
k.org%2Farchives%2Fdev%2F2020- March%2F160255.html&data=02%7C01%7Corika%40nvidia.com%7C52959 fd24ed2489868e308d8654abe56%7C43083d15727340c1b7db39efd9ccc17a%7C 0%7C0%7C637370718986486792&sdata=EPQFJHS9JJvzNj%2Ff9ODWt6yd3 F1HhQiKcPX6UD1eWGA%3D&reserved=0Signed-off-by Dekel Peled <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++-- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 21 +++++++++++++++++++++ lib/librte_ip_frag/rte_ip_frag.h | 26 ++------------------------ lib/librte_net/rte_ip.h | 26 ++++++++++++++++++++++++-- 5 files changed, 62 insertions(+), 28 deletions(-)doc/guides/prog_guide/rte_flow.rst +14
-2@@ -947,8 +947,8 @@ Item: ``IPV6`` Matches an IPv6 header. Dedicated flags indicate existence of specific extension headers. -Every type of extension header can use a dedicated pattern item, or -the generic `Item: IPV6_EXT`_. +Every type of extension header can use a dedicated pattern item, +for example `Item: IPV6_FRAG_EXT`_, or the generic `Item: IPV6_EXT`_. - ``hdr``: IPv6 header definition (``rte_ip.h``). - ``hop_ext_exist``: Hop-by-Hop Options extension header exists.@@ -1187,6 +1187,18 @@ Normally preceded by any of: - `Item: IPV6`_ - `Item: IPV6_EXT`_ +Item: ``IPV6_FRAG_EXT`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Matches the presence of IPv6 fragment extension header. + +- ``hdr``: IPv6 fragment extension header definition (``rte_ip.h``). + +Normally preceded by any of: + +- `Item: IPV6`_ +- `Item: IPV6_EXT`_ + Item: ``ICMP6`` ^^^^^^^^^^^^^^^lib/librte_ethdev/rte_flow.c +1
-0@@ -72,6 +72,7 @@ struct rte_flow_desc_data {MK_FLOW_ITEM (VXLAN_GPE ,sizeof (struct rte_flow_item_vxlan_gpe )),MK_FLOW_ITEM (ARP_ETH_IPV4 ,sizeof (struct rte_flow_item_arp_eth_ipv4 )),MK_FLOW_ITEM (IPV6_EXT ,sizeof (struct rte_flow_item_ipv6_ext )), +MK_FLOW_ITEM (IPV6_FRAG_EXT ,sizeof (struct rte_flow_item_ipv6_frag_ext )), MK_FLOW_ITEM(ICMP6, sizeof(struct rte_flow_item_icmp6)),MK_FLOW_ITEM(ICMP6_ND_NS, sizeof(struct
rte_flow_item_icmp6_nd_ns)),
MK_FLOW_ITEM(ICMP6_ND_NA, sizeof(structrte_flow_item_icmp6_nd_na)),lib/librte_ethdev/rte_flow.h +21
-0@@ -368,6 +368,13 @@ enum rte_flow_item_type {RTE_FLOW_ITEM_TYPE_IPV6_EXT ,/** +* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, + +/** * Matches any ICMPv6 header. * * See struct rte_flow_item_icmp6. @@ -1188,6 +1195,20 @@ struct rte_flow_item_ipv6_ext rte_flow_item_ipv6_ext_mask = {#endif /** +* RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT +* +* Matches the presence of IPv6 fragment extension header. +* +* Preceded by any of: +* +* - RTE_FLOW_ITEM_TYPE_IPV6 +* - RTE_FLOW_ITEM_TYPE_IPV6_EXT +*/ +struct rte_flow_item_ipv6_frag_ext { +struct rte_ipv6_fragment_ext hdr; +}; + +/** * RTE_FLOW_ITEM_TYPE_ICMP6 * * Matches any ICMPv6 header.
lib/librte_ip_frag/rte_ip_frag.h +1
-24@@ -110,30 +110,8 @@ struct rte_ip_frag_tbl { __extension__struct ip_frag_pkt pkt[0 ];/**< hash table. */ }; -/** IPv6 fragment extension header */ -#define RTE_IPV6_EHDR_MF_SHIFT 0 -#define RTE_IPV6_EHDR_MF_MASK 1 -#define RTE_IPV6_EHDR_FO_SHIFT 3 -#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) -#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_FRAG_USED_MASK \ - (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) - -#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) -#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ - (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) - -struct ipv6_extension_fragment { -uint8_t next_header;/**< Next header type */ -uint8_t reserved;/**< Reserved */ -uint16_t frag_data;/**< All fragmentation data */ -uint32_t id;/**< Packet ID */ -} __rte_packed; - - +/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */
lib/librte_ip_frag/rte_ip_frag.h +1
-0+#define ipv6_extension_fragment rte_ipv6_fragment_ext/** * Create a new IP fragmentation table. lib/librte_net/rte_ip.h +14
-2@@ -456,8 +456,30 @@ struct rte_ipv6_hdr {return (uint16_t )cksum; } -/* IPv6 fragmentation header size */ -#define RTE_IPV6_FRAG_HDR_SIZE 8 +/** IPv6 fragment extension header. */ +#define RTE_IPV6_EHDR_MF_SHIFT 0 +#define RTE_IPV6_EHDR_MF_MASK 1 +#define RTE_IPV6_EHDR_FO_SHIFT 3 +#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) +#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_FRAG_USED_MASK (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) + +#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) +#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ + (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) &
RTE_IPV6_EHDR_MF_MASK))lib/librte_net/rte_ip.h +10
-1+ +struct rte_ipv6_fragment_ext { +uint8_t next_header;/**< Next header type */ +uint8_t reserved;/**< Reserved */ +rte_be16_t frag_data;/**< All fragmentation data */ +rte_be32_t id;/**< Packet ID */ +} __rte_packed; + +/* IPv6 fragment extension header size */ +#define RTE_IPV6_FRAG_HDR_SIZE sizeof(struct rte_ipv6_fragment_ext)/** * Parse next IPv6 header extension --
Quoted 1 line
1.8.3.1
Thanks,
Ori
PATCH 3/10 app/testpmd: support IPv4 fragments
In reply to Dekel PeledThis patch updates testpmd CLI to support fragment_offset field of IPv4 header item.
To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 0 fragment_offset mask 0x3fff ... To match on fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 1 fragment_offset last 0x3fff fragment_offset mask 0x3fff ...
(Use the full available range 1 to 0x3fff to include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, the fragment_offset field should not be specified for match.
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -129,6 +129,7 @@ enum index {ITEM_VLAN_INNER_TYPE ,ITEM_IPV4 ,ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO , ITEM_IPV4_SRC,
@@ -871,6 +872,7 @@ struct parse_action_priv {static const enum index item_ipv4[] = {ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO ,ITEM_IPV4_SRC ,
@@ -2093,6 +2095,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, hdr.type_of_service)), }, + [ITEM_IPV4_FRAGMENT_OFFSET] = { + .name = "fragment_offset", + .help = "fragmentation flags and fragment offset", + .next = NEXT(item_ipv4, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, + hdr.fragment_offset)), + }, [ITEM_IPV4_TTL] = { .name = "ttl", .help = "time to live",
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH 03/10] app/testpmd: support IPv4 fragments
Quoted 62 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, September 30, 2020 5:10 PM
Subject: [PATCH 03/10] app/testpmd: support IPv4 fragmentsThis patch updates testpmd CLI to support
fragment_offsetfield of IPv4 header item.To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4fragment_offsetspec 0fragment_offsetmask0x3fff... To match on fragmented IPv4 packets, need to use pattern:
... ipv4fragment_offsetspec 1fragment_offsetlast0x3ffffragment_offsetmask0x3fff...
(Use the full available range 1 to0x3fffto include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, thefragment_offsetfield should not be specified for match.Signed-off-by Dekel Peled <[email protected]>--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)app/test-pmd/cmdline_flow.c +9
-0@@ -129,6 +129,7 @@ enum index {ITEM_VLAN_INNER_TYPE ,ITEM_IPV4 ,ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO , ITEM_IPV4_SRC,@@ -871,6 +872,7 @@ struct parse_action_priv {static const enum index item_ipv4[] = {ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO ,ITEM_IPV4_SRC ,@@ -2093,6 +2095,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, hdr.type_of_service)), }, + [ITEM_IPV4_FRAGMENT_OFFSET] = { + .name ="fragment_offset" , + .help ="fragmentation flags and fragment offset" , + .next =NEXT (item_ipv4,NEXT_ENTRY (UNSIGNED ), item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, + hdr.fragment_offset)), + }, [ITEM_IPV4_TTL ] = {app/test-pmd/cmdline_flow.c +0
-1.name = "ttl", .help = "time to live", --
Quoted 1 line
1.8.3.1
Thanks,
Ori
PATCH 4/10 app/testpmd: support IPv6 fragments
In reply to Dekel Peledrte_flow update, following RFC [1], introduced frag_ext_exist field for IPv6 header item, used to indicate match on fragmented/non-fragmented packets.
This patch updates testpmd CLI to support the new field.
To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 0 frag_ext_exist mask 1 ... To match on fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 1 frag_ext_exist mask 1 ... To match on any IPv6 packets, the frag_ext_exist field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -141,6 +141,7 @@ enum index {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_ICMP ,ITEM_ICMP_TYPE , ITEM_ICMP_CODE,
@@ -888,6 +889,7 @@ struct parse_action_priv {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_NEXT , ZERO, };
@@ -2181,6 +2183,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6, hdr.dst_addr)), }, + [ITEM_IPV6_FRAG_EXT_EXIST] = { + .name = "frag_ext_exist", + .help = "fragment packet attribute", + .next = NEXT(item_ipv6, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6, + frag_ext_exist, 1)), + }, [ITEM_ICMP] = { .name = "icmp", .help = "match ICMP header",
Signature · 1 line
1.8.3.1
PATCH 5/10 app/testpmd: support IPv6 fragment extension item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.
To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 / ipv6_frag_ext ...
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- app/test-pmd/cmdline_flow.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
app/test-pmd/cmdline_flow.c +35 -0
@@ -193,6 +193,9 @@ enum index {ITEM_ARP_ETH_IPV4_TPA ,ITEM_IPV6_EXT ,ITEM_IPV6_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT , +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA ,ITEM_ICMP6 ,ITEM_ICMP6_TYPE , ITEM_ICMP6_CODE,
@@ -784,6 +787,7 @@ struct parse_action_priv {ITEM_VXLAN_GPE ,ITEM_ARP_ETH_IPV4 ,ITEM_IPV6_EXT , +ITEM_IPV6_FRAG_EXT ,ITEM_ICMP6 ,ITEM_ICMP6_ND_NS , ITEM_ICMP6_ND_NA,
@@ -1003,6 +1007,13 @@ struct parse_action_priv { ZERO, }; +static const enum index item_ipv6_frag_ext[] = { +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA , +ITEM_NEXT , +ZERO , +}; +static const enum index item_icmp6[] = {ITEM_ICMP6_TYPE ,ITEM_ICMP6_CODE ,
@@ -2560,6 +2571,30 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_ext, next_hdr)), }, + [ITEM_IPV6_FRAG_EXT] = { + .name = "ipv6_frag_ext", + .help = "match presence of IPv6 fragment extension header", + .priv =PRIV_ITEM (IPV6_FRAG_EXT , + sizeof(struct rte_flow_item_ipv6_frag_ext)), + .next = NEXT(item_ipv6_frag_ext), + .call = parse_vc, + }, + [ITEM_IPV6_FRAG_EXT_NEXT_HDR] = { + .name = "next_hdr", + .help = "next header", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ipv6_frag_ext, + hdr.next_header)), + }, + [ITEM_IPV6_FRAG_EXT_FRAG_DATA] = { + .name = "frag_data", + .help = "Fragment flags and offset", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext, + hdr.frag_data)), + }, [ITEM_ICMP6] = { .name = "icmp6", .help = "match any ICMPv6 header",
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH 05/10] app/testpmd: support IPv6 fragment extension item
Quoted 100 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, September 30, 2020 5:10 PM
Cc: [email protected]
Subject: [PATCH 05/10] app/testpmd: support IPv6 fragment extension item
rte_flowupdate, following RFC [1], added to ethdev therte_flowitemipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 /ipv6_frag_ext...[1]
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpd
k.org%2Farchives%2Fdev%2F2020- March%2F160255.html&data=02%7C01%7Corika%40nvidia.com%7C1effc aa06bc943080a7408d8654aec04%7C43083d15727340c1b7db39efd9ccc17a%7C 0%7C1%7C637370719741604850&sdata=zgkbW7cwAMc9gKHeCvtDhQvFB c5605SqbfMF6hO3iPU%3D&reserved=0Signed-off-by Dekel Peled <[email protected]>--- app/test-pmd/cmdline_flow.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)app/test-pmd/cmdline_flow.c +33
-0@@ -193,6 +193,9 @@ enum index {ITEM_ARP_ETH_IPV4_TPA ,ITEM_IPV6_EXT ,ITEM_IPV6_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT , +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA ,ITEM_ICMP6 ,ITEM_ICMP6_TYPE , ITEM_ICMP6_CODE,@@ -784,6 +787,7 @@ struct parse_action_priv {ITEM_VXLAN_GPE ,ITEM_ARP_ETH_IPV4 ,ITEM_IPV6_EXT , +ITEM_IPV6_FRAG_EXT ,ITEM_ICMP6 ,ITEM_ICMP6_ND_NS , ITEM_ICMP6_ND_NA,@@ -1003,6 +1007,13 @@ struct parse_action_priv { ZERO, }; +static const enum index item_ipv6_frag_ext[] = { +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA , +ITEM_NEXT , +ZERO , +}; +static const enum index item_icmp6[] = {ITEM_ICMP6_TYPE ,ITEM_ICMP6_CODE ,@@ -2560,6 +2571,30 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_ext, next_hdr)), }, + [ITEM_IPV6_FRAG_EXT] = { + .name ="ipv6_frag_ext" , + .help ="match presence of IPv6 fragment extension header" , + .priv =PRIV_ITEM (IPV6_FRAG_EXT , +sizeof (struct rte_flow_item_ipv6_frag_ext )), + .next =NEXT (item_ipv6_frag_ext), + .call = parse_vc, + }, + [ITEM_IPV6_FRAG_EXT_NEXT_HDR ] = { + .name ="next_hdr" , + .help ="next header" , + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ipv6_frag_ext, + hdr.next_header)), + }, + [ITEM_IPV6_FRAG_EXT_FRAG_DATA ] = { + .name ="frag_data" , + .help ="Fragment flags and offset" , + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct
rte_flow_item_ipv6_frag_ext,app/test-pmd/cmdline_flow.c +2
-1+ hdr.frag_data)), + }, [ITEM_ICMP6] = { .name = "icmp6", .help = "match any ICMPv6 header", --
Quoted 1 line
1.8.3.1
Thanks,
Ori
PATCH 6/10 net/mlx5: remove handling of ICMP fragmented packets
In reply to Dekel PeledCommit [1] forced setting of match on 'frag' bit mask 1 and value 0. Previous patch in this series added support of match on fragmented and non-fragmented packets on L3 items, so this setting is now redundant.
This patch removes the changes done in [1].
[1] commit 85407db9f60d ("net/mlx5: fix matching for ICMP fragments")
--- drivers/net/mlx5/mlx5_flow_dv.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/net/mlx5/mlx5_flow_dv.c +0 -12
@@ -7345,12 +7345,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp6_m) icmp6_m = &rte_flow_item_icmp6_mask; -/* -* Force flow only to match the non-fragmented IPv6 ICMPv6 packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmpv6_type, icmp6_m->type);MLX5_SET (fte_match_set_misc3, misc3_v, icmpv6_type, icmp6_v->type & icmp6_m->type);
@@ -7398,12 +7392,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp_m) icmp_m = &rte_flow_item_icmp_mask; -/* -* Force flow only to match the non-fragmented IPv4 ICMP packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmp_type, icmp_m->hdr.icmp_type); MLX5_SET(fte_match_set_misc3, misc3_v, icmp_type,
Signature · 1 line
1.8.3.1
PATCH 7/10 net/mlx5: support match on IPv4 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv4 fragmented and non-fragmented packets, using the IPv4 header fragment_offset field.
--- drivers/net/mlx5/mlx5_flow.c | 48 ++++++++---- drivers/net/mlx5/mlx5_flow.h | 10 +++ drivers/net/mlx5/mlx5_flow_dv.c | 156 +++++++++++++++++++++++++++++++------ drivers/net/mlx5/mlx5_flow_verbs.c | 9 ++- 4 files changed, 178 insertions(+), 45 deletions(-)
drivers/net/mlx5/mlx5_flow.c +31 -17
@@ -474,6 +474,8 @@ struct mlx5_flow_tunnel_info {* Bit-masks covering supported fields by the NIC to compare with user mask. * @param[in] size * Bit-masks size in bytes. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -485,6 +487,7 @@ struct mlx5_flow_tunnel_info {const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error) { unsigned int i;
@@ -502,7 +505,7 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"mask/last without a spec is not" " supported"); -if (item->spec && item->last) { +if (item->spec && item->last && !range_accepted) {uint8_t spec[size];uint8_t last[size];unsigned int i;
@@ -1277,7 +1280,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp6_mask, -sizeof (struct rte_flow_item_icmp6 ), error); +sizeof (struct rte_flow_item_icmp6 ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1329,7 +1333,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp_mask, -sizeof (struct rte_flow_item_icmp ), error); +sizeof (struct rte_flow_item_icmp ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1384,7 +1389,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_eth ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -1438,7 +1443,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_vlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (!tunnel && mask->tci !=RTE_BE16 (0x0fff )) {
@@ -1502,6 +1507,7 @@ struct mlx5_flow_tunnel_info {uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error) { const struct rte_flow_item_ipv4 *mask = item->mask;
@@ -1572,7 +1578,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv4 ), - error); + range_accepted, error);if (ret <0 )return ret;return 0 ;
@@ -1592,6 +1598,8 @@ struct mlx5_flow_tunnel_info {* @param[in] acc_mask * Acceptable mask, if NULL default internal default mask * will be used to check whether item fields are supported. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -1671,7 +1679,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv6 ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error);if (ret <0 )return ret;return 0 ;
@@ -1726,7 +1734,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_udp_mask, -sizeof (struct rte_flow_item_udp ), error); +sizeof (struct rte_flow_item_udp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -1781,7 +1790,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)flow_mask, -sizeof (struct rte_flow_item_tcp ), error); +sizeof (struct rte_flow_item_tcp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -1835,7 +1845,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_mask,sizeof (struct rte_flow_item_vxlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -1906,7 +1916,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_gpe_mask,sizeof (struct rte_flow_item_vxlan_gpe ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -1980,7 +1990,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&gre_key_default_mask, -sizeof (rte_be32_t), error); +sizeof (rte_be32_t),MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -2032,7 +2042,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_gre ), error); +sizeof (struct rte_flow_item_gre ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;#ifndef HAVE_MLX5DV_DR
@@ -2107,7 +2118,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_geneve ), error); +sizeof (struct rte_flow_item_geneve ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (spec) {
@@ -2190,7 +2202,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_mpls_mask, -sizeof (struct rte_flow_item_mpls ), error); +sizeof (struct rte_flow_item_mpls ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2245,7 +2258,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_nvgre_mask, -sizeof (struct rte_flow_item_nvgre ), error); +sizeof (struct rte_flow_item_nvgre ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2339,7 +2353,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ecpri ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error); }/* Allocate unique ID for the split Q/RSS subflows. */
drivers/net/mlx5/mlx5_flow.h +10 -0
@@ -330,6 +330,14 @@ enum mlx5_feature_name {#define MLX5_ENCAPSULATION_DECISION_SIZE (sizeof(struct rte_flow_item_eth) + \ sizeof(struct rte_flow_item_ipv4)) +/* IPv4 fragment_offset field contains relevant data in bits 2 to 15. */ +#define MLX5_IPV4_FRAG_OFFSET_MASK \ + (RTE_IPV4_HDR_OFFSET_MASK | RTE_IPV4_HDR_MF_FLAG) + +/* Specific item's fields can accept a range of values (using spec and last). */ +#define MLX5_ITEM_RANGE_NOT_ACCEPTED false +#define MLX5_ITEM_RANGE_ACCEPTED true +/* Software header modify action numbers of a flow. */ #define MLX5_ACT_NUM_MDF_IPV4 1#define MLX5_ACT_NUM_MDF_IPV6 4
@@ -985,6 +993,7 @@ int mlx5_flow_item_acceptable(const struct rte_flow_item *item,const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_eth(const struct rte_flow_item *item, uint64_t item_flags,
@@ -1002,6 +1011,7 @@ int mlx5_flow_validate_item_ipv4(const struct rte_flow_item *item,uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_ipv6(const struct rte_flow_item *item, uint64_t item_flags,
drivers/net/mlx5/mlx5_flow_dv.c +132 -24
210 lines not on this page · raw message
drivers/net/mlx5/mlx5_flow_verbs.c +5 -4
@@ -1312,10 +1312,11 @@ }break ;case RTE_FLOW_ITEM_TYPE_IPV4 : - ret =mlx5_flow_validate_item_ipv4 (items, item_flags, - last_item, - ether_type,NULL , - error); + ret =mlx5_flow_validate_item_ipv4 + (items, item_flags, + last_item, ether_type,NULL , +MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret; last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV4 :
Signature · 1 line
1.8.3.1
PATCH 8/10 net/mlx5: support match on IPv6 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv6 fragmented and non-fragmented packets, using the new field frag_ext_exist, added to rte_flow following RFC [1].
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- drivers/net/mlx5/mlx5_flow_dv.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/mlx5/mlx5_flow_dv.c +5 -0
@@ -5211,6 +5211,7 @@ struct field_modify_info modify_tcp[] = { .proto = 0xff, .hop_limits = 0xff, }, + .frag_ext_exist = 1, };const struct rte_flow_item_ecpri nic_ecpri_mask = { .hdr = {
@@ -6519,6 +6520,10 @@ struct field_modify_info modify_tcp[] = { ipv6_m->hdr.hop_limits);MLX5_SET (fte_match_set_lyr_2_4, headers_v, ip_ttl_hoplimit, ipv6_v->hdr.hop_limits & ipv6_m->hdr.hop_limits); +MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag, + !!(ipv6_m->frag_ext_exist)); +MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag, + !!(ipv6_v->frag_ext_exist & ipv6_m->frag_ext_exist)); }/**
Signature · 1 line
1.8.3.1
PATCH 9/10 net/mlx5: support match on IPv6 fragment ext. item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch adds to MLX5 PMD the option to match on this item type.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- drivers/net/mlx5/mlx5_flow.h | 4 + drivers/net/mlx5/mlx5_flow_dv.c | 209 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 213 insertions(+)
drivers/net/mlx5/mlx5_flow.h +4 -0
@@ -122,6 +122,10 @@ enum mlx5_feature_name {/* Pattern eCPRI Layer bit. */ #define MLX5_FLOW_LAYER_ECPRI (UINT64_C(1) << 29) +/* IPv6 Fragment Extension Header bit. */ +#define MLX5_FLOW_LAYER_OUTER_L3_IPV6_FRAG_EXT (1u << 30) +#define MLX5_FLOW_LAYER_INNER_L3_IPV6_FRAG_EXT (1u << 31) +/* Outer Masks. */ #define MLX5_FLOW_LAYER_OUTER_L3 \ (MLX5_FLOW_LAYER_OUTER_L3_IPV4 | MLX5_FLOW_LAYER_OUTER_L3_IPV6)
drivers/net/mlx5/mlx5_flow_dv.c +209 -0
233 lines not on this page · raw message
Signature · 1 line
1.8.3.1
PATCH 10/10 doc: update release notes for MLX5 L3 frag support
In reply to Dekel PeledThis patch updates 20.11 release notes with the changes included in patches of this series:
1) MLX5 support of matching on IPv4/IPv6 fragmented/non-fragmented packets.
2) ABI change in ethdev struct rte_flow_item_ipv6.
--- doc/guides/rel_notes/release_20_11.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
doc/guides/rel_notes/release_20_11.rst +10 -0
@@ -84,6 +84,11 @@ New Features * Added support for 200G PAM4 link speed. +* **Updated Mellanox mlx5 driver.** + + Updated Mellanox mlx5 driver with new features and improvements, including: + + * Added support for matching on fragmented/non-fragmented IPv4/IPv6 packets. Removed Items -------------
@@ -209,6 +214,11 @@ ABI Changes * ``ethdev`` internal functions are marked with ``__rte_internal`` tag. + * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header. Known Issues ------------
Signature · 1 line
1.8.3.1
v2 cover support match on L3 fragmented packets
In reply to Dekel PeledThis series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
In MLX5 PMD, support match on IPv4 fragmented packets, IPv6 fragmented packets, and IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
---
Dekel Peled (11):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item net/mlx5: remove handling of ICMP fragmented packets net/mlx5: support match on IPv4 fragment packets net/mlx5: support match on IPv6 fragment packets net/mlx5: support match on IPv6 fragment ext. item
doc: update release notes for MLX5 L3 frag support net/mlx5: enforce limitation on IPv6 next proto
app/test-pmd/cmdline_flow.c | 53 +++++ doc/guides/nics/mlx5.rst | 7 + doc/guides/prog_guide/rte_flow.rst | 28 ++- doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/mlx5/mlx5_flow.c | 62 ++++-- drivers/net/mlx5/mlx5_flow.h | 14 ++ drivers/net/mlx5/mlx5_flow_dv.c | 382 +++++++++++++++++++++++++++++---- drivers/net/mlx5/mlx5_flow_verbs.c | 9 +- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 46 +++- lib/librte_ip_frag/rte_ip_frag.h | 26 +-- lib/librte_net/rte_ip.h | 26 ++- 12 files changed, 574 insertions(+), 90 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v2 1/11 ethdev: add extensions attributes to IPv6 item
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- doc/guides/prog_guide/rte_flow.rst | 16 +++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 36 insertions(+), 5 deletions(-)
doc/guides/prog_guide/rte_flow.rst +13 -3
@@ -946,11 +946,21 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension header exists. +- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.h +23 -2
@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 01/11] ethdev: add extensions attributes to IPv6 item
Hi
Quoted 39 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 01/11] ethdev: add extensions attributes to IPv6 itemUsing the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header.[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dp
dk.org%2Farchives%2Fdev%2F2020- August%2F177257.html&data=02%7C01%7Corika%40nvidia.com%7C1a92 82d24518485dd37508d8664f2634%7C43083d15727340c1b7db39efd9ccc17a%7 C0%7C0%7C637371837412802968&sdata=7Jdz3yt3nsSrWYei69BwWro7cZ 0VwdnKZ0sfcD8MglQ%3D&reserved=0
Quoted 2 lines
Signed-off-by Dekel Peled <[email protected]>---
Thanks,
Ori
PATCH v2 2/11 ethdev: add IPv6 fragment extension header item
In reply to Dekel PeledApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].
Relevant definitions are moved from lib/librte_ip_frag/rte_ip_frag.h to lib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. struct ipv6_extension_fragment renamed to rte_ipv6_fragment_ext to adapt it to the common naming convention.
Default mask is not defined, since all fields are optional.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++-- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 21 +++++++++++++++++++++ lib/librte_ip_frag/rte_ip_frag.h | 26 ++------------------------ lib/librte_net/rte_ip.h | 26 ++++++++++++++++++++++++-- 5 files changed, 62 insertions(+), 28 deletions(-)
doc/guides/prog_guide/rte_flow.rst +14 -2
@@ -947,8 +947,8 @@ Item: ``IPV6`` Matches an IPv6 header. Dedicated flags indicate existence of specific extension headers. -Every type of extension header can use a dedicated pattern item, or -the generic `Item: IPV6_EXT`_. +Every type of extension header can use a dedicated pattern item, +for example `Item: IPV6_FRAG_EXT`_, or the generic `Item: IPV6_EXT`_. - ``hdr``: IPv6 header definition (``rte_ip.h``). - ``hop_ext_exist``: Hop-by-Hop Options extension header exists.
@@ -1187,6 +1187,18 @@ Normally preceded by any of: - `Item: IPV6`_ - `Item: IPV6_EXT`_ +Item: ``IPV6_FRAG_EXT`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Matches the presence of IPv6 fragment extension header. + +- ``hdr``: IPv6 fragment extension header definition (``rte_ip.h``). + +Normally preceded by any of: + +- `Item: IPV6`_ +- `Item: IPV6_EXT`_ + Item: ``ICMP6`` ^^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.c +1 -0
@@ -72,6 +72,7 @@ struct rte_flow_desc_data {MK_FLOW_ITEM (VXLAN_GPE ,sizeof (struct rte_flow_item_vxlan_gpe )),MK_FLOW_ITEM (ARP_ETH_IPV4 ,sizeof (struct rte_flow_item_arp_eth_ipv4 )),MK_FLOW_ITEM (IPV6_EXT ,sizeof (struct rte_flow_item_ipv6_ext )), +MK_FLOW_ITEM (IPV6_FRAG_EXT ,sizeof (struct rte_flow_item_ipv6_frag_ext )),MK_FLOW_ITEM (ICMP6 ,sizeof (struct rte_flow_item_icmp6 )),MK_FLOW_ITEM (ICMP6_ND_NS ,sizeof (struct rte_flow_item_icmp6_nd_ns )), MK_FLOW_ITEM(ICMP6_ND_NA, sizeof(struct rte_flow_item_icmp6_nd_na)),
lib/librte_ethdev/rte_flow.h +21 -0
@@ -368,6 +368,13 @@ enum rte_flow_item_type {RTE_FLOW_ITEM_TYPE_IPV6_EXT ,/** +* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, + +/** * Matches any ICMPv6 header. * * See struct rte_flow_item_icmp6.
@@ -1188,6 +1195,20 @@ struct rte_flow_item_ipv6_ext rte_flow_item_ipv6_ext_mask = {#endif /** +* RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT +* +* Matches the presence of IPv6 fragment extension header. +* +* Preceded by any of: +* +* - RTE_FLOW_ITEM_TYPE_IPV6 +* - RTE_FLOW_ITEM_TYPE_IPV6_EXT +*/ +struct rte_flow_item_ipv6_frag_ext { +struct rte_ipv6_fragment_ext hdr; +}; + +/** * RTE_FLOW_ITEM_TYPE_ICMP6 * * Matches any ICMPv6 header.
lib/librte_ip_frag/rte_ip_frag.h +2 -24
@@ -110,30 +110,8 @@ struct rte_ip_frag_tbl { __extension__struct ip_frag_pkt pkt[0 ];/**< hash table. */ }; -/** IPv6 fragment extension header */ -#define RTE_IPV6_EHDR_MF_SHIFT 0 -#define RTE_IPV6_EHDR_MF_MASK 1 -#define RTE_IPV6_EHDR_FO_SHIFT 3 -#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) -#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_FRAG_USED_MASK \ - (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) - -#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) -#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ - (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) - -struct ipv6_extension_fragment { -uint8_t next_header;/**< Next header type */ -uint8_t reserved;/**< Reserved */ -uint16_t frag_data;/**< All fragmentation data */ -uint32_t id;/**< Packet ID */ -} __rte_packed; - - +/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */ +#define ipv6_extension_fragment rte_ipv6_fragment_ext/** * Create a new IP fragmentation table.
lib/librte_net/rte_ip.h +24 -2
@@ -456,8 +456,30 @@ struct rte_ipv6_hdr {return (uint16_t )cksum; } -/* IPv6 fragmentation header size */ -#define RTE_IPV6_FRAG_HDR_SIZE 8 +/** IPv6 fragment extension header. */ +#define RTE_IPV6_EHDR_MF_SHIFT 0 +#define RTE_IPV6_EHDR_MF_MASK 1 +#define RTE_IPV6_EHDR_FO_SHIFT 3 +#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) +#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_FRAG_USED_MASK (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) + +#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) +#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ + (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) + +struct rte_ipv6_fragment_ext { +uint8_t next_header;/**< Next header type */ +uint8_t reserved;/**< Reserved */ +rte_be16_t frag_data;/**< All fragmentation data */ +rte_be32_t id;/**< Packet ID */ +} __rte_packed; + +/* IPv6 fragment extension header size */ +#define RTE_IPV6_FRAG_HDR_SIZE sizeof(struct rte_ipv6_fragment_ext)/** * Parse next IPv6 header extension
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 02/11] ethdev: add IPv6 fragment extension header item
Quoted 8 lines · On Fri, 2 Oct 2020 00:14:59 +0300 Dekel Peled <[email protected]> wrote:
lib/librte_ethdev/rte_flow.h +0
-0@@ -368,6 +368,13 @@ enum rte_flow_item_type { RTE_FLOW_ITEM_TYPE_IPV6_EXT,/**
lib/librte_ethdev/rte_flow.h enum rte_flow_item_type { · line 380
Quoted 10 lines
lib/librte_ethdev/rte_flow.h +7
-0+* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, + +/** * Matches any ICMPv6 header. * * See struct rte_flow_item_icmp6
Putting new enum value in the middle of existing list will renumber the ones below. This causes an ABI breakage.
Since the ABI breakage was not preannounced, this patch needs to be revised or approved by the TAB.
PATCH v2 3/11 app/testpmd: support IPv4 fragments
In reply to Dekel PeledThis patch updates testpmd CLI to support fragment_offset field of IPv4 header item.
To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 0 fragment_offset mask 0x3fff ... To match on fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 1 fragment_offset last 0x3fff fragment_offset mask 0x3fff ...
(Use the full available range 1 to 0x3fff to include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, the fragment_offset field should not be specified for match.
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -129,6 +129,7 @@ enum index {ITEM_VLAN_INNER_TYPE ,ITEM_IPV4 ,ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO , ITEM_IPV4_SRC,
@@ -873,6 +874,7 @@ struct parse_action_priv {static const enum index item_ipv4[] = {ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO ,ITEM_IPV4_SRC ,
@@ -2097,6 +2099,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, hdr.type_of_service)), }, + [ITEM_IPV4_FRAGMENT_OFFSET] = { + .name = "fragment_offset", + .help = "fragmentation flags and fragment offset", + .next = NEXT(item_ipv4, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, + hdr.fragment_offset)), + }, [ITEM_IPV4_TTL] = { .name = "ttl", .help = "time to live",
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 03/11] app/testpmd: support IPv4 fragments
Quoted 20 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 03/11] app/testpmd: support IPv4 fragmentsThis patch updates testpmd CLI to support
fragment_offsetfield of IPv4 header item.To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4fragment_offsetspec 0fragment_offsetmask0x3fff... To match on fragmented IPv4 packets, need to use pattern:
... ipv4fragment_offsetspec 1fragment_offsetlast0x3ffffragment_offsetmask0x3fff...
(Use the full available range 1 to0x3fffto include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, thefragment_offsetfield should not be specified for match.
Quoted 2 lines
Signed-off-by Dekel Peled <[email protected]>---
Thanks,
Ori
PATCH v2 4/11 app/testpmd: support IPv6 fragments
In reply to Dekel Peledrte_flow update, following RFC [1], introduced frag_ext_exist field for IPv6 header item, used to indicate match on fragmented/non-fragmented packets.
This patch updates testpmd CLI to support the new field.
To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 0 frag_ext_exist mask 1 ... To match on fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 1 frag_ext_exist mask 1 ... To match on any IPv6 packets, the frag_ext_exist field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -141,6 +141,7 @@ enum index {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_ICMP ,ITEM_ICMP_TYPE , ITEM_ICMP_CODE,
@@ -890,6 +891,7 @@ struct parse_action_priv {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_NEXT , ZERO, };
@@ -2185,6 +2187,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6, hdr.dst_addr)), }, + [ITEM_IPV6_FRAG_EXT_EXIST] = { + .name = "frag_ext_exist", + .help = "fragment packet attribute", + .next = NEXT(item_ipv6, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6, + frag_ext_exist, 1)), + }, [ITEM_ICMP] = { .name = "icmp", .help = "match ICMP header",
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 04/11] app/testpmd: support IPv6 fragments
Hi
Quoted 25 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 04/11] app/testpmd: support IPv6 fragments
rte_flowupdate, following RFC [1], introducedfrag_ext_existfield for IPv6 header item, used to indicate match on fragmented/non-fragmented packets.
This patch updates testpmd CLI to support the new field.To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6frag_ext_existspec 0frag_ext_existmask 1 ... To match on fragmented IPv6 packets, need to use pattern:
... ipv6frag_ext_existspec 1frag_ext_existmask 1 ... To match on any IPv6 packets, thefrag_ext_existfield should not be specified for match.[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dp
dk.org%2Farchives%2Fdev%2F2020- August%2F177257.html&data=02%7C01%7Corika%40nvidia.com%7C52c00 2b1122645c54b6308d8664f3da6%7C43083d15727340c1b7db39efd9ccc17a%7C 0%7C0%7C637371837807355091&sdata=mTtFnZKwQ8Cs6XBjbikK76W8Vx TOHD6ZVwRK%2BMZizvg%3D&reserved=0
Quoted 2 lines
Signed-off-by Dekel Peled <[email protected]>---
Thanks,
Ori
PATCH v2 5/11 app/testpmd: support IPv6 fragment extension item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.
To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 / ipv6_frag_ext ...
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- app/test-pmd/cmdline_flow.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
app/test-pmd/cmdline_flow.c +35 -0
@@ -195,6 +195,9 @@ enum index {ITEM_ARP_ETH_IPV4_TPA ,ITEM_IPV6_EXT ,ITEM_IPV6_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT , +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA ,ITEM_ICMP6 ,ITEM_ICMP6_TYPE , ITEM_ICMP6_CODE,
@@ -786,6 +789,7 @@ struct parse_action_priv {ITEM_VXLAN_GPE ,ITEM_ARP_ETH_IPV4 ,ITEM_IPV6_EXT , +ITEM_IPV6_FRAG_EXT ,ITEM_ICMP6 ,ITEM_ICMP6_ND_NS , ITEM_ICMP6_ND_NA,
@@ -1007,6 +1011,13 @@ struct parse_action_priv { ZERO, }; +static const enum index item_ipv6_frag_ext[] = { +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA , +ITEM_NEXT , +ZERO , +}; +static const enum index item_icmp6[] = {ITEM_ICMP6_TYPE ,ITEM_ICMP6_CODE ,
@@ -2578,6 +2589,30 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_ext, next_hdr)), }, + [ITEM_IPV6_FRAG_EXT] = { + .name = "ipv6_frag_ext", + .help = "match presence of IPv6 fragment extension header", + .priv =PRIV_ITEM (IPV6_FRAG_EXT , + sizeof(struct rte_flow_item_ipv6_frag_ext)), + .next = NEXT(item_ipv6_frag_ext), + .call = parse_vc, + }, + [ITEM_IPV6_FRAG_EXT_NEXT_HDR] = { + .name = "next_hdr", + .help = "next header", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ipv6_frag_ext, + hdr.next_header)), + }, + [ITEM_IPV6_FRAG_EXT_FRAG_DATA] = { + .name = "frag_data", + .help = "Fragment flags and offset", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext, + hdr.frag_data)), + }, [ITEM_ICMP6] = { .name = "icmp6", .help = "match any ICMPv6 header",
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 05/11] app/testpmd: support IPv6 fragment extension item
Hi
Quoted 20 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 05/11] app/testpmd: support IPv6 fragment extension item
rte_flowupdate, following RFC [1], added to ethdev therte_flowitemipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 /ipv6_frag_ext...[1]
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpd
k.org%2Farchives%2Fdev%2F2020- March%2F160255.html&data=02%7C01%7Corika%40nvidia.com%7C05088 1c489164e37c32008d8664f2d9f%7C43083d15727340c1b7db39efd9ccc17a%7C 0%7C0%7C637371837539734661&sdata=WQyqN0fQMH%2BuGGcR9OU7 wp7yQMaup0dXGN4UCUG6B%2BA%3D&reserved=0
Quoted 2 lines
Signed-off-by Dekel Peled <[email protected]>---
Thanks,
Ori
PATCH v2 6/11 net/mlx5: remove handling of ICMP fragmented packets
In reply to Dekel PeledCommit [1] forced setting of match on 'frag' bit mask 1 and value 0. Previous patch in this series added support of match on fragmented and non-fragmented packets on L3 items, so this setting is now redundant.
This patch removes the changes done in [1].
[1] commit 85407db9f60d ("net/mlx5: fix matching for ICMP fragments")
--- drivers/net/mlx5/mlx5_flow_dv.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/net/mlx5/mlx5_flow_dv.c +0 -12
@@ -7345,12 +7345,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp6_m) icmp6_m = &rte_flow_item_icmp6_mask; -/* -* Force flow only to match the non-fragmented IPv6 ICMPv6 packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmpv6_type, icmp6_m->type);MLX5_SET (fte_match_set_misc3, misc3_v, icmpv6_type, icmp6_v->type & icmp6_m->type);
@@ -7398,12 +7392,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp_m) icmp_m = &rte_flow_item_icmp_mask; -/* -* Force flow only to match the non-fragmented IPv4 ICMP packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmp_type, icmp_m->hdr.icmp_type); MLX5_SET(fte_match_set_misc3, misc3_v, icmp_type,
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 06/11] net/mlx5: remove handling of ICMP fragmented packets
Hi
Quoted 52 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 06/11] net/mlx5: remove handling of ICMP fragmented packetsCommit [1] forced setting of match on 'frag' bit mask 1 and value 0. Previous patch in this series added support of match on fragmented and non-fragmented packets on L3 items, so this setting is now redundant.
This patch removes the changes done in [1].
[1] commit
85407db9f60d("net/mlx5: fix matching for ICMP fragments")Signed-off-by Dekel Peled <[email protected]>--- drivers/net/mlx5/mlx5_flow_dv.c | 12 ------------ 1 file changed, 12 deletions(-)drivers/net/mlx5/mlx5_flow_dv.c +0
-6@@ -7345,12 +7345,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp6_m) icmp6_m = &rte_flow_item_icmp6_mask; -/* -* Force flow only to match the non-fragmented IPv6 ICMPv6 packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmpv6_type, icmp6_m- >type); MLX5_SET(fte_match_set_misc3, misc3_v, icmpv6_type,drivers/net/mlx5/mlx5_flow_dv.c +0
-7icmp6_v->type & icmp6_m->type);@@ -7398,12 +7392,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp_m) icmp_m = &rte_flow_item_icmp_mask; -/* -* Force flow only to match the non-fragmented IPv4 ICMP packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmp_type, icmp_m->hdr.icmp_type); MLX5_SET(fte_match_set_misc3, misc3_v, icmp_type, --
Quoted 1 line
1.8.3.1
Thanks,
Ori
PATCH v2 7/11 net/mlx5: support match on IPv4 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv4 fragmented and non-fragmented packets, using the IPv4 header fragment_offset field.
--- drivers/net/mlx5/mlx5_flow.c | 48 ++++++++---- drivers/net/mlx5/mlx5_flow.h | 10 +++ drivers/net/mlx5/mlx5_flow_dv.c | 156 +++++++++++++++++++++++++++++++------ drivers/net/mlx5/mlx5_flow_verbs.c | 9 ++- 4 files changed, 178 insertions(+), 45 deletions(-)
drivers/net/mlx5/mlx5_flow.c +31 -17
@@ -474,6 +474,8 @@ struct mlx5_flow_tunnel_info {* Bit-masks covering supported fields by the NIC to compare with user mask. * @param[in] size * Bit-masks size in bytes. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -485,6 +487,7 @@ struct mlx5_flow_tunnel_info {const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error) { unsigned int i;
@@ -502,7 +505,7 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"mask/last without a spec is not" " supported"); -if (item->spec && item->last) { +if (item->spec && item->last && !range_accepted) {uint8_t spec[size];uint8_t last[size];unsigned int i;
@@ -1277,7 +1280,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp6_mask, -sizeof (struct rte_flow_item_icmp6 ), error); +sizeof (struct rte_flow_item_icmp6 ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1329,7 +1333,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp_mask, -sizeof (struct rte_flow_item_icmp ), error); +sizeof (struct rte_flow_item_icmp ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1384,7 +1389,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_eth ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -1438,7 +1443,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_vlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (!tunnel && mask->tci !=RTE_BE16 (0x0fff )) {
@@ -1502,6 +1507,7 @@ struct mlx5_flow_tunnel_info {uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error) { const struct rte_flow_item_ipv4 *mask = item->mask;
@@ -1572,7 +1578,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv4 ), - error); + range_accepted, error);if (ret <0 )return ret;return 0 ;
@@ -1592,6 +1598,8 @@ struct mlx5_flow_tunnel_info {* @param[in] acc_mask * Acceptable mask, if NULL default internal default mask * will be used to check whether item fields are supported. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -1671,7 +1679,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv6 ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error);if (ret <0 )return ret;return 0 ;
@@ -1726,7 +1734,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_udp_mask, -sizeof (struct rte_flow_item_udp ), error); +sizeof (struct rte_flow_item_udp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -1781,7 +1790,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)flow_mask, -sizeof (struct rte_flow_item_tcp ), error); +sizeof (struct rte_flow_item_tcp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -1835,7 +1845,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_mask,sizeof (struct rte_flow_item_vxlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -1906,7 +1916,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_gpe_mask,sizeof (struct rte_flow_item_vxlan_gpe ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -1980,7 +1990,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&gre_key_default_mask, -sizeof (rte_be32_t), error); +sizeof (rte_be32_t),MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -2032,7 +2042,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_gre ), error); +sizeof (struct rte_flow_item_gre ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;#ifndef HAVE_MLX5DV_DR
@@ -2107,7 +2118,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_geneve ), error); +sizeof (struct rte_flow_item_geneve ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (spec) {
@@ -2190,7 +2202,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_mpls_mask, -sizeof (struct rte_flow_item_mpls ), error); +sizeof (struct rte_flow_item_mpls ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2245,7 +2258,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_nvgre_mask, -sizeof (struct rte_flow_item_nvgre ), error); +sizeof (struct rte_flow_item_nvgre ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2339,7 +2353,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ecpri ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error); }/* Allocate unique ID for the split Q/RSS subflows. */
drivers/net/mlx5/mlx5_flow.h +10 -0
@@ -330,6 +330,14 @@ enum mlx5_feature_name {#define MLX5_ENCAPSULATION_DECISION_SIZE (sizeof(struct rte_flow_item_eth) + \ sizeof(struct rte_flow_item_ipv4)) +/* IPv4 fragment_offset field contains relevant data in bits 2 to 15. */ +#define MLX5_IPV4_FRAG_OFFSET_MASK \ + (RTE_IPV4_HDR_OFFSET_MASK | RTE_IPV4_HDR_MF_FLAG) + +/* Specific item's fields can accept a range of values (using spec and last). */ +#define MLX5_ITEM_RANGE_NOT_ACCEPTED false +#define MLX5_ITEM_RANGE_ACCEPTED true +/* Software header modify action numbers of a flow. */ #define MLX5_ACT_NUM_MDF_IPV4 1#define MLX5_ACT_NUM_MDF_IPV6 4
@@ -985,6 +993,7 @@ int mlx5_flow_item_acceptable(const struct rte_flow_item *item,const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_eth(const struct rte_flow_item *item, uint64_t item_flags,
@@ -1002,6 +1011,7 @@ int mlx5_flow_validate_item_ipv4(const struct rte_flow_item *item,uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_ipv6(const struct rte_flow_item *item, uint64_t item_flags,
drivers/net/mlx5/mlx5_flow_dv.c +132 -24
210 lines not on this page · raw message
drivers/net/mlx5/mlx5_flow_verbs.c +5 -4
@@ -1312,10 +1312,11 @@ }break ;case RTE_FLOW_ITEM_TYPE_IPV4 : - ret =mlx5_flow_validate_item_ipv4 (items, item_flags, - last_item, - ether_type,NULL , - error); + ret =mlx5_flow_validate_item_ipv4 + (items, item_flags, + last_item, ether_type,NULL , +MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret; last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV4 :
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 07/11] net/mlx5: support match on IPv4 fragment packets
Hi
Quoted 11 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 07/11] net/mlx5: support match on IPv4 fragment packetsThis patch adds to MLX5 PMD the support of matching on IPv4 fragmented and non-fragmented packets, using the IPv4 header
fragment_offsetfield.Signed-off-by Dekel Peled <[email protected]>---
Thanks,
Ori
PATCH v2 8/11 net/mlx5: support match on IPv6 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv6 fragmented and non-fragmented packets, using the new field frag_ext_exist, added to rte_flow following RFC [1].
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- drivers/net/mlx5/mlx5_flow_dv.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/mlx5/mlx5_flow_dv.c +5 -0
@@ -5211,6 +5211,7 @@ struct field_modify_info modify_tcp[] = { .proto = 0xff, .hop_limits = 0xff, }, + .frag_ext_exist = 1, };const struct rte_flow_item_ecpri nic_ecpri_mask = { .hdr = {
@@ -6519,6 +6520,10 @@ struct field_modify_info modify_tcp[] = { ipv6_m->hdr.hop_limits);MLX5_SET (fte_match_set_lyr_2_4, headers_v, ip_ttl_hoplimit, ipv6_v->hdr.hop_limits & ipv6_m->hdr.hop_limits); +MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag, + !!(ipv6_m->frag_ext_exist)); +MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag, + !!(ipv6_v->frag_ext_exist & ipv6_m->frag_ext_exist)); }/**
Signature · 1 line
1.8.3.1
PATCH v2 9/11 net/mlx5: support match on IPv6 fragment ext. item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch adds to MLX5 PMD the option to match on this item type.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- drivers/net/mlx5/mlx5_flow.h | 4 + drivers/net/mlx5/mlx5_flow_dv.c | 209 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 213 insertions(+)
drivers/net/mlx5/mlx5_flow.h +4 -0
@@ -122,6 +122,10 @@ enum mlx5_feature_name {/* Pattern eCPRI Layer bit. */ #define MLX5_FLOW_LAYER_ECPRI (UINT64_C(1) << 29) +/* IPv6 Fragment Extension Header bit. */ +#define MLX5_FLOW_LAYER_OUTER_L3_IPV6_FRAG_EXT (1u << 30) +#define MLX5_FLOW_LAYER_INNER_L3_IPV6_FRAG_EXT (1u << 31) +/* Outer Masks. */ #define MLX5_FLOW_LAYER_OUTER_L3 \ (MLX5_FLOW_LAYER_OUTER_L3_IPV4 | MLX5_FLOW_LAYER_OUTER_L3_IPV6)
drivers/net/mlx5/mlx5_flow_dv.c +209 -0
233 lines not on this page · raw message
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 09/11] net/mlx5: support match on IPv6 fragment ext. item
Hi
Quoted 17 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 09/11] net/mlx5: support match on IPv6 fragment ext. item
rte_flowupdate, following RFC [1], added to ethdev therte_flowitemipv6_frag_ext.
This patch adds to MLX5 PMD the option to match on this item type.[1]
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpd
k.org%2Farchives%2Fdev%2F2020- March%2F160255.html&data=02%7C01%7Corika%40nvidia.com%7C93b63 53b89ee433d65b408d8664f4f70%7C43083d15727340c1b7db39efd9ccc17a%7C 0%7C1%7C637371838110046254&sdata=2kZqkNxjkTaK4c3uGSF5SeMcL9R C%2FXMvaWj2k1N3%2BzQ%3D&reserved=0
Quoted 2 lines
Signed-off-by Dekel Peled <[email protected]>---
Thanks,
Ori
PATCH v2 10/11 doc: update release notes for MLX5 L3 frag support
In reply to Dekel PeledThis patch updates 20.11 release notes with the changes included in patches of this series:
1) MLX5 support of matching on IPv4/IPv6 fragmented/non-fragmented packets.
2) ABI change in ethdev struct rte_flow_item_ipv6.
--- doc/guides/rel_notes/release_20_11.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
doc/guides/rel_notes/release_20_11.rst +10 -0
@@ -90,6 +90,11 @@ New Features * Added support for 200G PAM4 link speed. +* **Updated Mellanox mlx5 driver.** + + Updated Mellanox mlx5 driver with new features and improvements, including: + + * Added support for matching on fragmented/non-fragmented IPv4/IPv6 packets. Removed Items -------------
@@ -215,6 +220,11 @@ ABI Changes * ``ethdev`` internal functions are marked with ``__rte_internal`` tag. + * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header. Known Issues ------------
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 10/11] doc: update release notes for MLX5 L3 frag support
Hi
Quoted 48 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 10/11] doc: update release notes for MLX5 L3 frag supportThis patch updates 20.11 release notes with the changes included in patches of this series:
1) MLX5 support of matching on IPv4/IPv6 fragmented/non-fragmented packets.
2) ABI change in ethdev structrte_flow_item_ipv6.Signed-off-by Dekel Peled <[email protected]>--- doc/guides/rel_notes/release_20_11.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)doc/guides/rel_notes/release_20_11.rst +3
-0@@ -90,6 +90,11 @@ New Features * Added support for 200G PAM4 link speed. +* **Updated Mellanox mlx5 driver.** + + Updated Mellanox mlx5 driver with new features and improvements,including:
doc/guides/rel_notes/release_20_11.rst +2
-0+ + * Added support for matching on fragmented/non-fragmented IPv4/IPv6packets.
Removed Items
-------------doc/guides/rel_notes/release_20_11.rst +5
-1@@ -215,6 +220,11 @@ ABI Changes * ``ethdev`` internal functions are marked with ``__rte_internal`` tag. + * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header. Known Issues ------------ --
Quoted 1 line
1.8.3.1
Thanks,
Ori
PATCH v2 11/11 net/mlx5: enforce limitation on IPv6 next proto
In reply to Dekel PeledDue to PRM requirement, the IPv6 header item 'proto' field, indicating the next header protocol, should not be set as extension header. This patch adds the relevant validation, and documents the limitation.
--- doc/guides/nics/mlx5.rst | 7 +++++++ drivers/net/mlx5/mlx5_flow.c | 14 ++++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-)
doc/guides/nics/mlx5.rst +7 -0
@@ -311,6 +311,13 @@ Limitations for some NICs (such as ConnectX-6 Dx and BlueField 2). The capability bit ``scatter_fcs_w_decap_disable`` shows NIC support. +- IPv6 header item 'proto' field, indicating the next header protocol, should + not be set as extension header. + In case the next header is an extension header, it should not be specified in + IPv6 header item 'proto' field. + The last extension header item 'next header' field can specify the following + header protocol type. + Statistics ----------
drivers/net/mlx5/mlx5_flow.c +12 -2
@@ -1645,9 +1645,9 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"IPv6 cannot follow L2/VLAN layer " "which ether type is not IPv6"); +if (mask && spec) + next_proto = mask->hdr.proto & spec->hdr.proto;if (item_flags &MLX5_FLOW_LAYER_IPV6_ENCAP ) { -if (mask && spec) - next_proto = mask->hdr.proto & spec->hdr.proto;if (next_proto ==IPPROTO_IPIP || next_proto ==IPPROTO_IPV6 ) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
@@ -1655,6 +1655,16 @@ struct mlx5_flow_tunnel_info {"multiple tunnel " "not supported"); } +if (next_proto ==IPPROTO_HOPOPTS || + next_proto ==IPPROTO_ROUTING || + next_proto ==IPPROTO_FRAGMENT || + next_proto ==IPPROTO_ESP || + next_proto ==IPPROTO_AH || + next_proto ==IPPROTO_DSTOPTS ) +return rte_flow_error_set (error,EINVAL , +RTE_FLOW_ERROR_TYPE_ITEM , item, +"IPv6 proto (next header) should " +"not be set as extension header" );if (item_flags &MLX5_FLOW_LAYER_IPIP ) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM, item,
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 11/11] net/mlx5: enforce limitation on IPv6 next proto
Hi
Quoted 69 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Friday, October 2, 2020 12:15 AM
Subject: [PATCH v2 11/11] net/mlx5: enforce limitation on IPv6 next protoDue to PRM requirement, the IPv6 header item 'proto' field, indicating the next header protocol, should not be set as extension header. This patch adds the relevant validation, and documents the limitation.
Signed-off-by Dekel Peled <[email protected]>--- doc/guides/nics/mlx5.rst | 7 +++++++ drivers/net/mlx5/mlx5_flow.c | 14 ++++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-)doc/guides/nics/mlx5.rst +7
-0@@ -311,6 +311,13 @@ Limitations for some NICs (such as ConnectX-6 Dx and BlueField 2). The capability bit ``scatter_fcs_w_decap_disable`` shows NIC support. +- IPv6 header item 'proto' field, indicating the next header protocol, should + not be set as extension header. + In case the next header is an extension header, it should not be specified in + IPv6 header item 'proto' field. + The last extension header item 'next header' field can specify the following + header protocol type. + Statistics ----------drivers/net/mlx5/mlx5_flow.c +2
-2@@ -1645,9 +1645,9 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"IPv6 cannot follow L2/VLAN layer " "which ether type is not IPv6"); +if (mask && spec) + next_proto = mask->hdr.proto & spec->hdr.proto;if (item_flags &MLX5_FLOW_LAYER_IPV6_ENCAP ) { -if (mask && spec) - next_proto = mask->hdr.proto & spec->hdr.proto;if (next_proto ==IPPROTO_IPIP || next_proto ==IPPROTO_IPV6 )return rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ITEM,drivers/net/mlx5/mlx5_flow.c +10
-0@@ -1655,6 +1655,16 @@ struct mlx5_flow_tunnel_info {"multiple tunnel " "not supported"); } +if (next_proto ==IPPROTO_HOPOPTS || + next_proto ==IPPROTO_ROUTING || + next_proto ==IPPROTO_FRAGMENT || + next_proto ==IPPROTO_ESP || + next_proto ==IPPROTO_AH || + next_proto ==IPPROTO_DSTOPTS ) +return rte_flow_error_set (error,EINVAL , +RTE_FLOW_ERROR_TYPE_ITEM , item, +"IPv6 proto (next header) should " +"not be set as extension header" );if (item_flags &MLX5_FLOW_LAYER_IPIP ) return rte_flow_error_set(error, EINVAL,
Quoted 4 lines
RTE_FLOW_ERROR_TYPE_ITEM,
item,
--
1.8.3.1
Thanks,
Ori
v3 cover support match on L3 fragmented packets
In reply to Dekel PeledThis series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
In MLX5 PMD, support match on IPv4 fragmented packets, IPv6 fragmented packets, and IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
---
Dekel Peled (11):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item net/mlx5: remove handling of ICMP fragmented packets net/mlx5: support match on IPv4 fragment packets net/mlx5: support match on IPv6 fragment packets net/mlx5: support match on IPv6 fragment ext. item
doc: update release notes for MLX5 L3 frag support net/mlx5: enforce limitation on IPv6 next proto
app/test-pmd/cmdline_flow.c | 53 +++++ doc/guides/nics/mlx5.rst | 7 + doc/guides/prog_guide/rte_flow.rst | 28 ++- doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/mlx5/mlx5_flow.c | 62 ++++-- drivers/net/mlx5/mlx5_flow.h | 14 ++ drivers/net/mlx5/mlx5_flow_dv.c | 382 +++++++++++++++++++++++++++++---- drivers/net/mlx5/mlx5_flow_verbs.c | 9 +- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 45 +++- lib/librte_ip_frag/rte_ip_frag.h | 26 +-- lib/librte_net/rte_ip.h | 26 ++- 12 files changed, 573 insertions(+), 90 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v3 1/11 ethdev: add extensions attributes to IPv6 item
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- doc/guides/prog_guide/rte_flow.rst | 16 +++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 36 insertions(+), 5 deletions(-)
doc/guides/prog_guide/rte_flow.rst +13 -3
@@ -946,11 +946,21 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension header exists. +- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.h +23 -2
@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v3 01/11] ethdev: add extensions attributes to IPv6 item
Quoted 41 lines · Dekel Peled
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header.[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
Signed-off-by Dekel Peled <[email protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 16 +++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 36 insertions(+), 5 deletions(-)doc/guides/prog_guide/rte_flow.rst +0
-0
doc/guides/prog_guide/rte_flow.rst Item: ``IPV6`` · line 951
Quoted 8 lines
doc/guides/prog_guide/rte_flow.rst +3
-2@@ -946,11 +946,21 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_.
Can you add how the PMD should interpret if these flags are not set by the application.
There is a mention of some of that in the testpmd commit log. I think it is good to spell it out here.
Quoted 58 lines
doc/guides/prog_guide/rte_flow.rst +10
-1- ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension header exists. +- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^lib/librte_ethdev/rte_flow.h +23
-3@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */ --1.8.3.1
Re: [dpdk-dev] [PATCH v3 01/11] ethdev: add extensions attributes to IPv6 item
Thanks, PSB.
Quoted 62 lines
-----Original Message-----
From: Ajit Khaparde <[email protected]>
Sent: Wednesday, October 7, 2020 2:44 AM
To: Dekel Peled <[email protected]>
Cc: Ori Kam <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Ferruh Yigit <[email protected]>; Andrew Rybchenko <[email protected]>; Ananyev, Konstantin <[email protected]>; Olivier Matz <[email protected]>; Wenzhuo Lu <[email protected]>; Beilei Xing <[email protected]>; Iremonger, Bernard <[email protected]>; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; dpdk-dev <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v3 01/11] ethdev: add extensions attributes to IPv6 itemQuoted 11 lines · Dekel Peled
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.For example, fragmented IPv6 packets contain a dedicated extension
header
Quoted 18 lines
(which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header.[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
Review
Quoted 8 lines
Signed-off-by Dekel Peled <[email protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 16 +++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 36 insertions(+), 5 deletions(-)(quoted diff) +0
-0
b/doc/guides/prog_guide/rte_flow.rstQuoted 7 lines
index 119b128..0b476da 100644
doc/guides/prog_guide/rte_flow.rst +0
-0@@ -946,11 +946,21 @@ Item: ``IPV6`` Matches an IPv6 header.
Quoted 10 lines
doc/guides/prog_guide/rte_flow.rst Item: ``IPV6`` · line 951
Quoted 5 lines
doc/guides/prog_guide/rte_flow.rst +3
-2-Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_.Can you add how the PMD should interpret if these flags are not set by the application.
There is a mention of some of that in the testpmd commit log. I think it is good to spell it out here.
Agree, I will add it in the git log for next version.
Quoted 60 lines
doc/guides/prog_guide/rte_flow.rst Item: ``IPV6``
Quoted 9 lines
doc/guides/prog_guide/rte_flow.rst +5
-1- ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension headerexists.
Quoted 50 lines
doc/guides/prog_guide/rte_flow.rst +5
-0+- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^lib/librte_ethdev/rte_flow.h +23
-3@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */ --1.8.3.1
PATCH v3 2/11 ethdev: add IPv6 fragment extension header item
In reply to Dekel PeledApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].
Relevant definitions are moved from lib/librte_ip_frag/rte_ip_frag.h to lib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. struct ipv6_extension_fragment renamed to rte_ipv6_fragment_ext to adapt it to the common naming convention.
Default mask is not defined, since all fields are optional.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++-- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 20 ++++++++++++++++++++ lib/librte_ip_frag/rte_ip_frag.h | 26 ++------------------------ lib/librte_net/rte_ip.h | 26 ++++++++++++++++++++++++-- 5 files changed, 61 insertions(+), 28 deletions(-)
doc/guides/prog_guide/rte_flow.rst +14 -2
@@ -947,8 +947,8 @@ Item: ``IPV6`` Matches an IPv6 header. Dedicated flags indicate existence of specific extension headers. -Every type of extension header can use a dedicated pattern item, or -the generic `Item: IPV6_EXT`_. +Every type of extension header can use a dedicated pattern item, +for example `Item: IPV6_FRAG_EXT`_, or the generic `Item: IPV6_EXT`_. - ``hdr``: IPv6 header definition (``rte_ip.h``). - ``hop_ext_exist``: Hop-by-Hop Options extension header exists.
@@ -1187,6 +1187,18 @@ Normally preceded by any of: - `Item: IPV6`_ - `Item: IPV6_EXT`_ +Item: ``IPV6_FRAG_EXT`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Matches the presence of IPv6 fragment extension header. + +- ``hdr``: IPv6 fragment extension header definition (``rte_ip.h``). + +Normally preceded by any of: + +- `Item: IPV6`_ +- `Item: IPV6_EXT`_ + Item: ``ICMP6`` ^^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.c +1 -0
@@ -72,6 +72,7 @@ struct rte_flow_desc_data {MK_FLOW_ITEM (VXLAN_GPE ,sizeof (struct rte_flow_item_vxlan_gpe )),MK_FLOW_ITEM (ARP_ETH_IPV4 ,sizeof (struct rte_flow_item_arp_eth_ipv4 )),MK_FLOW_ITEM (IPV6_EXT ,sizeof (struct rte_flow_item_ipv6_ext )), +MK_FLOW_ITEM (IPV6_FRAG_EXT ,sizeof (struct rte_flow_item_ipv6_frag_ext )),MK_FLOW_ITEM (ICMP6 ,sizeof (struct rte_flow_item_icmp6 )),MK_FLOW_ITEM (ICMP6_ND_NS ,sizeof (struct rte_flow_item_icmp6_nd_ns )), MK_FLOW_ITEM(ICMP6_ND_NA, sizeof(struct rte_flow_item_icmp6_nd_na)),
lib/librte_ethdev/rte_flow.h +20 -0
@@ -537,6 +537,12 @@ enum rte_flow_item_type {*/ RTE_FLOW_ITEM_TYPE_ECPRI , +/** +* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, };/**
@@ -1188,6 +1194,20 @@ struct rte_flow_item_ipv6_ext rte_flow_item_ipv6_ext_mask = {#endif /** +* RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT +* +* Matches the presence of IPv6 fragment extension header. +* +* Preceded by any of: +* +* - RTE_FLOW_ITEM_TYPE_IPV6 +* - RTE_FLOW_ITEM_TYPE_IPV6_EXT +*/ +struct rte_flow_item_ipv6_frag_ext { +struct rte_ipv6_fragment_ext hdr; +}; + +/** * RTE_FLOW_ITEM_TYPE_ICMP6 * * Matches any ICMPv6 header.
lib/librte_ip_frag/rte_ip_frag.h +2 -24
@@ -110,30 +110,8 @@ struct rte_ip_frag_tbl { __extension__struct ip_frag_pkt pkt[0 ];/**< hash table. */ }; -/** IPv6 fragment extension header */ -#define RTE_IPV6_EHDR_MF_SHIFT 0 -#define RTE_IPV6_EHDR_MF_MASK 1 -#define RTE_IPV6_EHDR_FO_SHIFT 3 -#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) -#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_FRAG_USED_MASK \ - (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) - -#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) -#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ - (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) - -struct ipv6_extension_fragment { -uint8_t next_header;/**< Next header type */ -uint8_t reserved;/**< Reserved */ -uint16_t frag_data;/**< All fragmentation data */ -uint32_t id;/**< Packet ID */ -} __rte_packed; - - +/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */ +#define ipv6_extension_fragment rte_ipv6_fragment_ext/** * Create a new IP fragmentation table.
lib/librte_net/rte_ip.h +24 -2
@@ -456,8 +456,30 @@ struct rte_ipv6_hdr {return (uint16_t )cksum; } -/* IPv6 fragmentation header size */ -#define RTE_IPV6_FRAG_HDR_SIZE 8 +/** IPv6 fragment extension header. */ +#define RTE_IPV6_EHDR_MF_SHIFT 0 +#define RTE_IPV6_EHDR_MF_MASK 1 +#define RTE_IPV6_EHDR_FO_SHIFT 3 +#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) +#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_FRAG_USED_MASK (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) + +#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) +#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ + (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) + +struct rte_ipv6_fragment_ext { +uint8_t next_header;/**< Next header type */ +uint8_t reserved;/**< Reserved */ +rte_be16_t frag_data;/**< All fragmentation data */ +rte_be32_t id;/**< Packet ID */ +} __rte_packed; + +/* IPv6 fragment extension header size */ +#define RTE_IPV6_FRAG_HDR_SIZE sizeof(struct rte_ipv6_fragment_ext)/** * Parse next IPv6 header extension
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v3 02/11] ethdev: add IPv6 fragment extension header item
Hi,
Quoted 26 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Monday, October 5, 2020 11:36 AM
Subject: [PATCH v3 02/11] ethdev: add IPv6 fragment extension header itemApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].Relevant definitions are moved from
lib/librte_ip_frag/rte_ip_frag.htolib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. structipv6_extension_fragmentrenamed torte_ipv6_fragment_extto adapt it to the common naming convention.Default mask is not defined, since all fields are optional.
[1]
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpd
k.org%2Farchives%2Fdev%2F2020- March%2F160255.html&data=02%7C01%7Corika%40nvidia.com%7C96f18 79f1da24462291408d86909c793%7C43083d15727340c1b7db39efd9ccc17a%7C 0%7C1%7C637374838007797661&sdata=AW5ZK%2BfqiCgto8SpVIUL1z0qJ Qd2Vhv2%2BTGNJoIturE%3D&reserved=0
Quoted 2 lines
Signed-off-by Dekel Peled <[email protected]>---
Thanks,
Ori
PATCH v3 3/11 app/testpmd: support IPv4 fragments
In reply to Dekel PeledThis patch updates testpmd CLI to support fragment_offset field of IPv4 header item.
To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 0 fragment_offset mask 0x3fff ... To match on fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 1 fragment_offset last 0x3fff fragment_offset mask 0x3fff ...
(Use the full available range 1 to 0x3fff to include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, the fragment_offset field should not be specified for match.
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -129,6 +129,7 @@ enum index {ITEM_VLAN_INNER_TYPE ,ITEM_IPV4 ,ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO , ITEM_IPV4_SRC,
@@ -873,6 +874,7 @@ struct parse_action_priv {static const enum index item_ipv4[] = {ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO ,ITEM_IPV4_SRC ,
@@ -2097,6 +2099,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, hdr.type_of_service)), }, + [ITEM_IPV4_FRAGMENT_OFFSET] = { + .name = "fragment_offset", + .help = "fragmentation flags and fragment offset", + .next = NEXT(item_ipv4, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, + hdr.fragment_offset)), + }, [ITEM_IPV4_TTL] = { .name = "ttl", .help = "time to live",
Signature · 1 line
1.8.3.1
PATCH v3 4/11 app/testpmd: support IPv6 fragments
In reply to Dekel Peledrte_flow update, following RFC [1], introduced frag_ext_exist field for IPv6 header item, used to indicate match on fragmented/non-fragmented packets.
This patch updates testpmd CLI to support the new field.
To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 0 frag_ext_exist mask 1 ... To match on fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 1 frag_ext_exist mask 1 ... To match on any IPv6 packets, the frag_ext_exist field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -141,6 +141,7 @@ enum index {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_ICMP ,ITEM_ICMP_TYPE , ITEM_ICMP_CODE,
@@ -890,6 +891,7 @@ struct parse_action_priv {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_NEXT , ZERO, };
@@ -2185,6 +2187,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6, hdr.dst_addr)), }, + [ITEM_IPV6_FRAG_EXT_EXIST] = { + .name = "frag_ext_exist", + .help = "fragment packet attribute", + .next = NEXT(item_ipv6, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6, + frag_ext_exist, 1)), + }, [ITEM_ICMP] = { .name = "icmp", .help = "match ICMP header",
Signature · 1 line
1.8.3.1
PATCH v3 5/11 app/testpmd: support IPv6 fragment extension item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.
To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 / ipv6_frag_ext ...
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- app/test-pmd/cmdline_flow.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
app/test-pmd/cmdline_flow.c +35 -0
@@ -195,6 +195,9 @@ enum index {ITEM_ARP_ETH_IPV4_TPA ,ITEM_IPV6_EXT ,ITEM_IPV6_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT , +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA ,ITEM_ICMP6 ,ITEM_ICMP6_TYPE , ITEM_ICMP6_CODE,
@@ -786,6 +789,7 @@ struct parse_action_priv {ITEM_VXLAN_GPE ,ITEM_ARP_ETH_IPV4 ,ITEM_IPV6_EXT , +ITEM_IPV6_FRAG_EXT ,ITEM_ICMP6 ,ITEM_ICMP6_ND_NS , ITEM_ICMP6_ND_NA,
@@ -1007,6 +1011,13 @@ struct parse_action_priv { ZERO, }; +static const enum index item_ipv6_frag_ext[] = { +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA , +ITEM_NEXT , +ZERO , +}; +static const enum index item_icmp6[] = {ITEM_ICMP6_TYPE ,ITEM_ICMP6_CODE ,
@@ -2578,6 +2589,30 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_ext, next_hdr)), }, + [ITEM_IPV6_FRAG_EXT] = { + .name = "ipv6_frag_ext", + .help = "match presence of IPv6 fragment extension header", + .priv =PRIV_ITEM (IPV6_FRAG_EXT , + sizeof(struct rte_flow_item_ipv6_frag_ext)), + .next = NEXT(item_ipv6_frag_ext), + .call = parse_vc, + }, + [ITEM_IPV6_FRAG_EXT_NEXT_HDR] = { + .name = "next_hdr", + .help = "next header", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ipv6_frag_ext, + hdr.next_header)), + }, + [ITEM_IPV6_FRAG_EXT_FRAG_DATA] = { + .name = "frag_data", + .help = "Fragment flags and offset", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext, + hdr.frag_data)), + }, [ITEM_ICMP6] = { .name = "icmp6", .help = "match any ICMPv6 header",
Signature · 1 line
1.8.3.1
PATCH v3 6/11 net/mlx5: remove handling of ICMP fragmented packets
In reply to Dekel PeledCommit [1] forced setting of match on 'frag' bit mask 1 and value 0. Previous patch in this series added support of match on fragmented and non-fragmented packets on L3 items, so this setting is now redundant.
This patch removes the changes done in [1].
[1] commit 85407db9f60d ("net/mlx5: fix matching for ICMP fragments")
--- drivers/net/mlx5/mlx5_flow_dv.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/net/mlx5/mlx5_flow_dv.c +0 -12
@@ -7345,12 +7345,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp6_m) icmp6_m = &rte_flow_item_icmp6_mask; -/* -* Force flow only to match the non-fragmented IPv6 ICMPv6 packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmpv6_type, icmp6_m->type);MLX5_SET (fte_match_set_misc3, misc3_v, icmpv6_type, icmp6_v->type & icmp6_m->type);
@@ -7398,12 +7392,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp_m) icmp_m = &rte_flow_item_icmp_mask; -/* -* Force flow only to match the non-fragmented IPv4 ICMP packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmp_type, icmp_m->hdr.icmp_type); MLX5_SET(fte_match_set_misc3, misc3_v, icmp_type,
Signature · 1 line
1.8.3.1
PATCH v3 7/11 net/mlx5: support match on IPv4 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv4 fragmented and non-fragmented packets, using the IPv4 header fragment_offset field.
--- drivers/net/mlx5/mlx5_flow.c | 48 ++++++++---- drivers/net/mlx5/mlx5_flow.h | 10 +++ drivers/net/mlx5/mlx5_flow_dv.c | 156 +++++++++++++++++++++++++++++++------ drivers/net/mlx5/mlx5_flow_verbs.c | 9 ++- 4 files changed, 178 insertions(+), 45 deletions(-)
drivers/net/mlx5/mlx5_flow.c +31 -17
@@ -474,6 +474,8 @@ struct mlx5_flow_tunnel_info {* Bit-masks covering supported fields by the NIC to compare with user mask. * @param[in] size * Bit-masks size in bytes. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -485,6 +487,7 @@ struct mlx5_flow_tunnel_info {const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error) { unsigned int i;
@@ -502,7 +505,7 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"mask/last without a spec is not" " supported"); -if (item->spec && item->last) { +if (item->spec && item->last && !range_accepted) {uint8_t spec[size];uint8_t last[size];unsigned int i;
@@ -1277,7 +1280,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp6_mask, -sizeof (struct rte_flow_item_icmp6 ), error); +sizeof (struct rte_flow_item_icmp6 ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1329,7 +1333,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp_mask, -sizeof (struct rte_flow_item_icmp ), error); +sizeof (struct rte_flow_item_icmp ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1384,7 +1389,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_eth ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -1438,7 +1443,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_vlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (!tunnel && mask->tci !=RTE_BE16 (0x0fff )) {
@@ -1502,6 +1507,7 @@ struct mlx5_flow_tunnel_info {uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error) { const struct rte_flow_item_ipv4 *mask = item->mask;
@@ -1572,7 +1578,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv4 ), - error); + range_accepted, error);if (ret <0 )return ret;return 0 ;
@@ -1592,6 +1598,8 @@ struct mlx5_flow_tunnel_info {* @param[in] acc_mask * Acceptable mask, if NULL default internal default mask * will be used to check whether item fields are supported. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -1671,7 +1679,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv6 ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error);if (ret <0 )return ret;return 0 ;
@@ -1726,7 +1734,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_udp_mask, -sizeof (struct rte_flow_item_udp ), error); +sizeof (struct rte_flow_item_udp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -1781,7 +1790,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)flow_mask, -sizeof (struct rte_flow_item_tcp ), error); +sizeof (struct rte_flow_item_tcp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -1835,7 +1845,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_mask,sizeof (struct rte_flow_item_vxlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -1906,7 +1916,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_gpe_mask,sizeof (struct rte_flow_item_vxlan_gpe ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -1980,7 +1990,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&gre_key_default_mask, -sizeof (rte_be32_t), error); +sizeof (rte_be32_t),MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -2032,7 +2042,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_gre ), error); +sizeof (struct rte_flow_item_gre ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;#ifndef HAVE_MLX5DV_DR
@@ -2107,7 +2118,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_geneve ), error); +sizeof (struct rte_flow_item_geneve ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (spec) {
@@ -2190,7 +2202,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_mpls_mask, -sizeof (struct rte_flow_item_mpls ), error); +sizeof (struct rte_flow_item_mpls ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2245,7 +2258,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_nvgre_mask, -sizeof (struct rte_flow_item_nvgre ), error); +sizeof (struct rte_flow_item_nvgre ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2339,7 +2353,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ecpri ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error); }/* Allocate unique ID for the split Q/RSS subflows. */
drivers/net/mlx5/mlx5_flow.h +10 -0
@@ -330,6 +330,14 @@ enum mlx5_feature_name {#define MLX5_ENCAPSULATION_DECISION_SIZE (sizeof(struct rte_flow_item_eth) + \ sizeof(struct rte_flow_item_ipv4)) +/* IPv4 fragment_offset field contains relevant data in bits 2 to 15. */ +#define MLX5_IPV4_FRAG_OFFSET_MASK \ + (RTE_IPV4_HDR_OFFSET_MASK | RTE_IPV4_HDR_MF_FLAG) + +/* Specific item's fields can accept a range of values (using spec and last). */ +#define MLX5_ITEM_RANGE_NOT_ACCEPTED false +#define MLX5_ITEM_RANGE_ACCEPTED true +/* Software header modify action numbers of a flow. */ #define MLX5_ACT_NUM_MDF_IPV4 1#define MLX5_ACT_NUM_MDF_IPV6 4
@@ -985,6 +993,7 @@ int mlx5_flow_item_acceptable(const struct rte_flow_item *item,const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_eth(const struct rte_flow_item *item, uint64_t item_flags,
@@ -1002,6 +1011,7 @@ int mlx5_flow_validate_item_ipv4(const struct rte_flow_item *item,uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_ipv6(const struct rte_flow_item *item, uint64_t item_flags,
drivers/net/mlx5/mlx5_flow_dv.c +132 -24
210 lines not on this page · raw message
drivers/net/mlx5/mlx5_flow_verbs.c +5 -4
@@ -1312,10 +1312,11 @@ }break ;case RTE_FLOW_ITEM_TYPE_IPV4 : - ret =mlx5_flow_validate_item_ipv4 (items, item_flags, - last_item, - ether_type,NULL , - error); + ret =mlx5_flow_validate_item_ipv4 + (items, item_flags, + last_item, ether_type,NULL , +MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret; last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV4 :
Signature · 1 line
1.8.3.1
PATCH v3 8/11 net/mlx5: support match on IPv6 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv6 fragmented and non-fragmented packets, using the new field frag_ext_exist, added to rte_flow following RFC [1].
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- drivers/net/mlx5/mlx5_flow_dv.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/mlx5/mlx5_flow_dv.c +5 -0
@@ -5211,6 +5211,7 @@ struct field_modify_info modify_tcp[] = { .proto = 0xff, .hop_limits = 0xff, }, + .frag_ext_exist = 1, };const struct rte_flow_item_ecpri nic_ecpri_mask = { .hdr = {
@@ -6519,6 +6520,10 @@ struct field_modify_info modify_tcp[] = { ipv6_m->hdr.hop_limits);MLX5_SET (fte_match_set_lyr_2_4, headers_v, ip_ttl_hoplimit, ipv6_v->hdr.hop_limits & ipv6_m->hdr.hop_limits); +MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag, + !!(ipv6_m->frag_ext_exist)); +MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag, + !!(ipv6_v->frag_ext_exist & ipv6_m->frag_ext_exist)); }/**
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v3 08/11] net/mlx5: support match on IPv6 fragment packets
Hi
Quoted 47 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Monday, October 5, 2020 11:36 AM
Subject: [PATCH v3 08/11] net/mlx5: support match on IPv6 fragment packetsThis patch adds to MLX5 PMD the support of matching on IPv6 fragmented and non-fragmented packets, using the new field
frag_ext_exist, added torte_flowfollowing RFC [1].[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dp
dk.org%2Farchives%2Fdev%2F2020- August%2F177257.html&data=02%7C01%7Corika%40nvidia.com%7Cbdd7c 0dab63e4dee1c5a08d86909f193%7C43083d15727340c1b7db39efd9ccc17a%7C 0%7C1%7C637374838713645970&sdata=DqFljgZKStcjqIiwKYh63by%2FmC 1t9slR5bobh7jcM70%3D&reserved=0Signed-off-by Dekel Peled <[email protected]>--- drivers/net/mlx5/mlx5_flow_dv.c | 5 +++++ 1 file changed, 5 insertions(+)drivers/net/mlx5/mlx5_flow_dv.c +5
-1@@ -5211,6 +5211,7 @@ struct field_modify_info modify_tcp[] = { .proto = 0xff, .hop_limits = 0xff, }, + .frag_ext_exist = 1, };const struct rte_flow_item_ecpri nic_ecpri_mask = { .hdr = {@@ -6519,6 +6520,10 @@ struct field_modify_info modify_tcp[] = { ipv6_m->hdr.hop_limits);MLX5_SET (fte_match_set_lyr_2_4, headers_v, ip_ttl_hoplimit, ipv6_v->hdr.hop_limits & ipv6_m->hdr.hop_limits); +MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag, + !!(ipv6_m->frag_ext_exist)); +MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag, + !!(ipv6_v->frag_ext_exist & ipv6_m->frag_ext_exist)); }/** --
Quoted 1 line
1.8.3.1
Thanks,
Ori
PATCH v3 9/11 net/mlx5: support match on IPv6 fragment ext. item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch adds to MLX5 PMD the option to match on this item type.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- drivers/net/mlx5/mlx5_flow.h | 4 + drivers/net/mlx5/mlx5_flow_dv.c | 209 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 213 insertions(+)
drivers/net/mlx5/mlx5_flow.h +4 -0
@@ -122,6 +122,10 @@ enum mlx5_feature_name {/* Pattern eCPRI Layer bit. */ #define MLX5_FLOW_LAYER_ECPRI (UINT64_C(1) << 29) +/* IPv6 Fragment Extension Header bit. */ +#define MLX5_FLOW_LAYER_OUTER_L3_IPV6_FRAG_EXT (1u << 30) +#define MLX5_FLOW_LAYER_INNER_L3_IPV6_FRAG_EXT (1u << 31) +/* Outer Masks. */ #define MLX5_FLOW_LAYER_OUTER_L3 \ (MLX5_FLOW_LAYER_OUTER_L3_IPV4 | MLX5_FLOW_LAYER_OUTER_L3_IPV6)
drivers/net/mlx5/mlx5_flow_dv.c +209 -0
233 lines not on this page · raw message
Signature · 1 line
1.8.3.1
PATCH v3 10/11 doc: update release notes for MLX5 L3 frag support
In reply to Dekel PeledThis patch updates 20.11 release notes with the changes included in patches of this series:
1) MLX5 support of matching on IPv4/IPv6 fragmented/non-fragmented packets.
2) ABI change in ethdev struct rte_flow_item_ipv6.
--- doc/guides/rel_notes/release_20_11.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
doc/guides/rel_notes/release_20_11.rst +10 -0
@@ -109,6 +109,11 @@ New Features * Extern objects and functions can be plugged into the pipeline. * Transaction-oriented table updates. +* **Updated Mellanox mlx5 driver.** + + Updated Mellanox mlx5 driver with new features and improvements, including: + + * Added support for matching on fragmented/non-fragmented IPv4/IPv6 packets. Removed Items -------------
@@ -238,6 +243,11 @@ ABI Changes * ``ethdev`` internal functions are marked with ``__rte_internal`` tag. + * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header. Known Issues ------------
Signature · 1 line
1.8.3.1
PATCH v3 11/11 net/mlx5: enforce limitation on IPv6 next proto
In reply to Dekel PeledDue to PRM requirement, the IPv6 header item 'proto' field, indicating the next header protocol, should not be set as extension header. This patch adds the relevant validation, and documents the limitation.
--- doc/guides/nics/mlx5.rst | 7 +++++++ drivers/net/mlx5/mlx5_flow.c | 14 ++++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-)
doc/guides/nics/mlx5.rst +7 -0
@@ -311,6 +311,13 @@ Limitations for some NICs (such as ConnectX-6 Dx and BlueField 2). The capability bit ``scatter_fcs_w_decap_disable`` shows NIC support. +- IPv6 header item 'proto' field, indicating the next header protocol, should + not be set as extension header. + In case the next header is an extension header, it should not be specified in + IPv6 header item 'proto' field. + The last extension header item 'next header' field can specify the following + header protocol type. + Statistics ----------
drivers/net/mlx5/mlx5_flow.c +12 -2
@@ -1645,9 +1645,9 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"IPv6 cannot follow L2/VLAN layer " "which ether type is not IPv6"); +if (mask && spec) + next_proto = mask->hdr.proto & spec->hdr.proto;if (item_flags &MLX5_FLOW_LAYER_IPV6_ENCAP ) { -if (mask && spec) - next_proto = mask->hdr.proto & spec->hdr.proto;if (next_proto ==IPPROTO_IPIP || next_proto ==IPPROTO_IPV6 ) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
@@ -1655,6 +1655,16 @@ struct mlx5_flow_tunnel_info {"multiple tunnel " "not supported"); } +if (next_proto ==IPPROTO_HOPOPTS || + next_proto ==IPPROTO_ROUTING || + next_proto ==IPPROTO_FRAGMENT || + next_proto ==IPPROTO_ESP || + next_proto ==IPPROTO_AH || + next_proto ==IPPROTO_DSTOPTS ) +return rte_flow_error_set (error,EINVAL , +RTE_FLOW_ERROR_TYPE_ITEM , item, +"IPv6 proto (next header) should " +"not be set as extension header" );if (item_flags &MLX5_FLOW_LAYER_IPIP ) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM, item,
Signature · 1 line
1.8.3.1
v4 cover support match on L3 fragmented packets
In reply to Dekel PeledThis series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
In MLX5 PMD, support match on IPv4 fragmented packets, IPv6 fragmented packets, and IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
v4: update rte_flow documentation to clarify use of IPv6 extension header flags.
---
Dekel Peled (11):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item net/mlx5: remove handling of ICMP fragmented packets net/mlx5: support match on IPv4 fragment packets net/mlx5: support match on IPv6 fragment packets net/mlx5: support match on IPv6 fragment ext. item
doc: update release notes for MLX5 L3 frag support net/mlx5: enforce limitation on IPv6 next proto
app/test-pmd/cmdline_flow.c | 53 +++++ doc/guides/nics/mlx5.rst | 7 + doc/guides/prog_guide/rte_flow.rst | 34 ++- doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/mlx5/mlx5_flow.c | 62 ++++-- drivers/net/mlx5/mlx5_flow.h | 14 ++ drivers/net/mlx5/mlx5_flow_dv.c | 382 +++++++++++++++++++++++++++++---- drivers/net/mlx5/mlx5_flow_verbs.c | 9 +- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 45 +++- lib/librte_ip_frag/rte_ip_frag.h | 26 +-- lib/librte_net/rte_ip.h | 26 ++- 12 files changed, 579 insertions(+), 90 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v4 1/11 ethdev: add extensions attributes to IPv6 item
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header. To match on non-fragmented IPv6 packets, need to use frag_ext_exist 0. To match on fragmented IPv6 packets, need to use frag_ext_exist 1. To match on any IPv6 packets, the frag_ext_exist field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- doc/guides/prog_guide/rte_flow.rst | 22 +++++++++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 42 insertions(+), 5 deletions(-)
doc/guides/prog_guide/rte_flow.rst +19 -3
@@ -946,11 +946,27 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_. +To match on packets containing a specific extension header, an application +should match on the dedicated flag set to 1. +To match on packets not containing a specific extension header, an application +should match on the dedicated flag clear to 0. +In case application doesn't care about the existence of a specific extension +header, it should not specify the dedicated flag for matching. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension header exists. +- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.h +23 -2
@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v4 01/11] ethdev: add extensions attributes to IPv6 item
Quoted 19 lines · Dekel Peled
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
Quoted 8 lines
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header. To match on non-fragmented IPv6 packets, need to usefrag_ext_exist0.
Suggest:
"To match on non-fragmented IPv6 packets, applications should set frag_ext_exist 0."
Quoted 1 line
To match on fragmented IPv6 packets, need to use
frag_ext_exist1.
Suggest:
To match on fragmented IPv6 packets, applications should set frag_ext_exist to 1.
Quoted 89 lines
To match on any IPv6 packets, the
frag_ext_existfield should not be specified for match.[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
Signed-off-by Dekel Peled <[email protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 22 +++++++++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 42 insertions(+), 5 deletions(-)doc/guides/prog_guide/rte_flow.rst +19
-3@@ -946,11 +946,27 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_. +To match on packets containing a specific extension header, an application +should match on the dedicated flag set to 1. +To match on packets not containing a specific extension header, an application +should match on the dedicated flag clear to 0. +In case application doesn't care about the existence of a specific extension +header, it should not specify the dedicated flag for matching. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension header exists. +- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^lib/librte_ethdev/rte_flow.h +23
-3@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */ --1.8.3.1
Re: [dpdk-dev] [PATCH v4 01/11] ethdev: add extensions attributes to IPv6 item
Thanks, PSB.
Quoted 44 lines
-----Original Message-----
From: Ajit Khaparde <[email protected]>
Sent: Thursday, October 8, 2020 6:14 AM
To: Dekel Peled <[email protected]>
Cc: Ori Kam <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Ferruh Yigit <[email protected]>; Andrew Rybchenko <[email protected]>; Ananyev, Konstantin <[email protected]>; Olivier Matz <[email protected]>; Wenzhuo Lu <[email protected]>; Beilei Xing <[email protected]>; Iremonger, Bernard <[email protected]>; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; dpdk-dev <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v4 01/11] ethdev: add extensions attributes to IPv6 itemQuoted 11 lines · Dekel Peled
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.For example, fragmented IPv6 packets contain a dedicated extension
header
Quoted 8 lines
(which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.Quoted 8 lines
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header. To match on non-fragmented IPv6 packets, need to usefrag_ext_exist0.
Quoted 8 lines
Suggest:
"To match on non-fragmented IPv6 packets, applications should setfrag_ext_exist0."Quoted 1 line
To match on fragmented IPv6 packets, need to use
frag_ext_exist1.Suggest:
To match on fragmented IPv6 packets, applications should setfrag_ext_existto 1.
In the git log I abbreviated a little.
In the actual documentation rst file I wrote it clearly.
Quoted 95 lines
Quoted 7 lines
To match on any IPv6 packets, the
frag_ext_existfield should not be specified for match.[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
Review
Quoted 8 lines
Signed-off-by Dekel Peled <[email protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 22 +++++++++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 42 insertions(+), 5 deletions(-)(quoted diff) +0
-0
b/doc/guides/prog_guide/rte_flow.rstQuoted 5 lines
index 119b128..ae090db 100644
doc/guides/prog_guide/rte_flow.rst +0
-0@@ -946,11 +946,27 @@ Item: ``IPV6``doc/guides/prog_guide/rte_flow.rst Item: ``IPV6`` · line 954
Quoted 10 lines
doc/guides/prog_guide/rte_flow.rst +6
-2Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_. +To match on packets containing a specific extension header, an application +should match on the dedicated flag set to 1. +To match on packets not containing a specific extension header, anapplication
doc/guides/prog_guide/rte_flow.rst Item: ``IPV6`` · line 956
Quoted 2 lines
doc/guides/prog_guide/rte_flow.rst +2
-0+should match on the dedicated flag clear to 0. +In case application doesn't care about the existence of a specificextension
doc/guides/prog_guide/rte_flow.rst Item: ``IPV6``
Quoted 9 lines
doc/guides/prog_guide/rte_flow.rst +6
-1+header, it should not specify the dedicated flag for matching. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension headerexists.
Quoted 50 lines
doc/guides/prog_guide/rte_flow.rst +5
-0+- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^lib/librte_ethdev/rte_flow.h +23
-3@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */ --1.8.3.1
Re: [dpdk-dev] [PATCH v4 01/11] ethdev: add extensions attributes to IPv6 item
In reply to Dekel PeledQuoted 31 lines · Dekel Peled
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header. To match on non-fragmented IPv6 packets, need to usefrag_ext_exist0. To match on fragmented IPv6 packets, need to usefrag_ext_exist1. To match on any IPv6 packets, thefrag_ext_existfield should not be specified for match.
Quoted 4 lines
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
Signed-off-by Dekel Peled <[email protected]>Acked-by Ori Kam <[email protected]>
Quoted 82 lines
--- doc/guides/prog_guide/rte_flow.rst | 22 +++++++++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 42 insertions(+), 5 deletions(-)doc/guides/prog_guide/rte_flow.rst +19
-3@@ -946,11 +946,27 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_. +To match on packets containing a specific extension header, an application +should match on the dedicated flag set to 1. +To match on packets not containing a specific extension header, an application +should match on the dedicated flag clear to 0. +In case application doesn't care about the existence of a specific extension +header, it should not specify the dedicated flag for matching. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension header exists. +- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^lib/librte_ethdev/rte_flow.h +23
-3@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */ --1.8.3.1
PATCH v4 2/11 ethdev: add IPv6 fragment extension header item
In reply to Dekel PeledApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].
Relevant definitions are moved from lib/librte_ip_frag/rte_ip_frag.h to lib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. struct ipv6_extension_fragment renamed to rte_ipv6_fragment_ext to adapt it to the common naming convention.
Default mask is not defined, since all fields are optional.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++-- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 20 ++++++++++++++++++++ lib/librte_ip_frag/rte_ip_frag.h | 26 ++------------------------ lib/librte_net/rte_ip.h | 26 ++++++++++++++++++++++++-- 5 files changed, 61 insertions(+), 28 deletions(-)
doc/guides/prog_guide/rte_flow.rst +14 -2
@@ -947,8 +947,8 @@ Item: ``IPV6`` Matches an IPv6 header. Dedicated flags indicate existence of specific extension headers. -Every type of extension header can use a dedicated pattern item, or -the generic `Item: IPV6_EXT`_. +Every type of extension header can use a dedicated pattern item, +for example `Item: IPV6_FRAG_EXT`_, or the generic `Item: IPV6_EXT`_. To match on packets containing a specific extension header, an application should match on the dedicated flag set to 1. To match on packets not containing a specific extension header, an application
@@ -1193,6 +1193,18 @@ Normally preceded by any of: - `Item: IPV6`_ - `Item: IPV6_EXT`_ +Item: ``IPV6_FRAG_EXT`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Matches the presence of IPv6 fragment extension header. + +- ``hdr``: IPv6 fragment extension header definition (``rte_ip.h``). + +Normally preceded by any of: + +- `Item: IPV6`_ +- `Item: IPV6_EXT`_ + Item: ``ICMP6`` ^^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.c +1 -0
@@ -72,6 +72,7 @@ struct rte_flow_desc_data {MK_FLOW_ITEM (VXLAN_GPE ,sizeof (struct rte_flow_item_vxlan_gpe )),MK_FLOW_ITEM (ARP_ETH_IPV4 ,sizeof (struct rte_flow_item_arp_eth_ipv4 )),MK_FLOW_ITEM (IPV6_EXT ,sizeof (struct rte_flow_item_ipv6_ext )), +MK_FLOW_ITEM (IPV6_FRAG_EXT ,sizeof (struct rte_flow_item_ipv6_frag_ext )),MK_FLOW_ITEM (ICMP6 ,sizeof (struct rte_flow_item_icmp6 )),MK_FLOW_ITEM (ICMP6_ND_NS ,sizeof (struct rte_flow_item_icmp6_nd_ns )), MK_FLOW_ITEM(ICMP6_ND_NA, sizeof(struct rte_flow_item_icmp6_nd_na)),
lib/librte_ethdev/rte_flow.h +20 -0
@@ -537,6 +537,12 @@ enum rte_flow_item_type {*/ RTE_FLOW_ITEM_TYPE_ECPRI , +/** +* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, };/**
@@ -1188,6 +1194,20 @@ struct rte_flow_item_ipv6_ext rte_flow_item_ipv6_ext_mask = {#endif /** +* RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT +* +* Matches the presence of IPv6 fragment extension header. +* +* Preceded by any of: +* +* - RTE_FLOW_ITEM_TYPE_IPV6 +* - RTE_FLOW_ITEM_TYPE_IPV6_EXT +*/ +struct rte_flow_item_ipv6_frag_ext { +struct rte_ipv6_fragment_ext hdr; +}; + +/** * RTE_FLOW_ITEM_TYPE_ICMP6 * * Matches any ICMPv6 header.
lib/librte_ip_frag/rte_ip_frag.h +2 -24
@@ -110,30 +110,8 @@ struct rte_ip_frag_tbl { __extension__struct ip_frag_pkt pkt[0 ];/**< hash table. */ }; -/** IPv6 fragment extension header */ -#define RTE_IPV6_EHDR_MF_SHIFT 0 -#define RTE_IPV6_EHDR_MF_MASK 1 -#define RTE_IPV6_EHDR_FO_SHIFT 3 -#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) -#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_FRAG_USED_MASK \ - (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) - -#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) -#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ - (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) - -struct ipv6_extension_fragment { -uint8_t next_header;/**< Next header type */ -uint8_t reserved;/**< Reserved */ -uint16_t frag_data;/**< All fragmentation data */ -uint32_t id;/**< Packet ID */ -} __rte_packed; - - +/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */ +#define ipv6_extension_fragment rte_ipv6_fragment_ext/** * Create a new IP fragmentation table.
lib/librte_net/rte_ip.h +24 -2
@@ -456,8 +456,30 @@ struct rte_ipv6_hdr {return (uint16_t )cksum; } -/* IPv6 fragmentation header size */ -#define RTE_IPV6_FRAG_HDR_SIZE 8 +/** IPv6 fragment extension header. */ +#define RTE_IPV6_EHDR_MF_SHIFT 0 +#define RTE_IPV6_EHDR_MF_MASK 1 +#define RTE_IPV6_EHDR_FO_SHIFT 3 +#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) +#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_FRAG_USED_MASK (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) + +#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) +#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ + (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) + +struct rte_ipv6_fragment_ext { +uint8_t next_header;/**< Next header type */ +uint8_t reserved;/**< Reserved */ +rte_be16_t frag_data;/**< All fragmentation data */ +rte_be32_t id;/**< Packet ID */ +} __rte_packed; + +/* IPv6 fragment extension header size */ +#define RTE_IPV6_FRAG_HDR_SIZE sizeof(struct rte_ipv6_fragment_ext)/** * Parse next IPv6 header extension
Signature · 1 line
1.8.3.1
PATCH v4 3/11 app/testpmd: support IPv4 fragments
In reply to Dekel PeledThis patch updates testpmd CLI to support fragment_offset field of IPv4 header item.
To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 0 fragment_offset mask 0x3fff ... To match on fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 1 fragment_offset last 0x3fff fragment_offset mask 0x3fff ...
(Use the full available range 1 to 0x3fff to include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, the fragment_offset field should not be specified for match.
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -129,6 +129,7 @@ enum index {ITEM_VLAN_INNER_TYPE ,ITEM_IPV4 ,ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO , ITEM_IPV4_SRC,
@@ -873,6 +874,7 @@ struct parse_action_priv {static const enum index item_ipv4[] = {ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO ,ITEM_IPV4_SRC ,
@@ -2097,6 +2099,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, hdr.type_of_service)), }, + [ITEM_IPV4_FRAGMENT_OFFSET] = { + .name = "fragment_offset", + .help = "fragmentation flags and fragment offset", + .next = NEXT(item_ipv4, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, + hdr.fragment_offset)), + }, [ITEM_IPV4_TTL] = { .name = "ttl", .help = "time to live",
Signature · 1 line
1.8.3.1
PATCH v4 4/11 app/testpmd: support IPv6 fragments
In reply to Dekel Peledrte_flow update, following RFC [1], introduced frag_ext_exist field for IPv6 header item, used to indicate match on fragmented/non-fragmented packets.
This patch updates testpmd CLI to support the new field.
To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 0 frag_ext_exist mask 1 ... To match on fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 1 frag_ext_exist mask 1 ... To match on any IPv6 packets, the frag_ext_exist field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -141,6 +141,7 @@ enum index {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_ICMP ,ITEM_ICMP_TYPE , ITEM_ICMP_CODE,
@@ -890,6 +891,7 @@ struct parse_action_priv {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_NEXT , ZERO, };
@@ -2185,6 +2187,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6, hdr.dst_addr)), }, + [ITEM_IPV6_FRAG_EXT_EXIST] = { + .name = "frag_ext_exist", + .help = "fragment packet attribute", + .next = NEXT(item_ipv6, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6, + frag_ext_exist, 1)), + }, [ITEM_ICMP] = { .name = "icmp", .help = "match ICMP header",
Signature · 1 line
1.8.3.1
PATCH v4 5/11 app/testpmd: support IPv6 fragment extension item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.
To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 / ipv6_frag_ext ...
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- app/test-pmd/cmdline_flow.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
app/test-pmd/cmdline_flow.c +35 -0
@@ -195,6 +195,9 @@ enum index {ITEM_ARP_ETH_IPV4_TPA ,ITEM_IPV6_EXT ,ITEM_IPV6_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT , +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA ,ITEM_ICMP6 ,ITEM_ICMP6_TYPE , ITEM_ICMP6_CODE,
@@ -786,6 +789,7 @@ struct parse_action_priv {ITEM_VXLAN_GPE ,ITEM_ARP_ETH_IPV4 ,ITEM_IPV6_EXT , +ITEM_IPV6_FRAG_EXT ,ITEM_ICMP6 ,ITEM_ICMP6_ND_NS , ITEM_ICMP6_ND_NA,
@@ -1007,6 +1011,13 @@ struct parse_action_priv { ZERO, }; +static const enum index item_ipv6_frag_ext[] = { +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA , +ITEM_NEXT , +ZERO , +}; +static const enum index item_icmp6[] = {ITEM_ICMP6_TYPE ,ITEM_ICMP6_CODE ,
@@ -2578,6 +2589,30 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_ext, next_hdr)), }, + [ITEM_IPV6_FRAG_EXT] = { + .name = "ipv6_frag_ext", + .help = "match presence of IPv6 fragment extension header", + .priv =PRIV_ITEM (IPV6_FRAG_EXT , + sizeof(struct rte_flow_item_ipv6_frag_ext)), + .next = NEXT(item_ipv6_frag_ext), + .call = parse_vc, + }, + [ITEM_IPV6_FRAG_EXT_NEXT_HDR] = { + .name = "next_hdr", + .help = "next header", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ipv6_frag_ext, + hdr.next_header)), + }, + [ITEM_IPV6_FRAG_EXT_FRAG_DATA] = { + .name = "frag_data", + .help = "Fragment flags and offset", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext, + hdr.frag_data)), + }, [ITEM_ICMP6] = { .name = "icmp6", .help = "match any ICMPv6 header",
Signature · 1 line
1.8.3.1
PATCH v4 6/11 net/mlx5: remove handling of ICMP fragmented packets
In reply to Dekel PeledCommit [1] forced setting of match on 'frag' bit mask 1 and value 0. Previous patch in this series added support of match on fragmented and non-fragmented packets on L3 items, so this setting is now redundant.
This patch removes the changes done in [1].
[1] commit 85407db9f60d ("net/mlx5: fix matching for ICMP fragments")
--- drivers/net/mlx5/mlx5_flow_dv.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/net/mlx5/mlx5_flow_dv.c +0 -12
@@ -7345,12 +7345,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp6_m) icmp6_m = &rte_flow_item_icmp6_mask; -/* -* Force flow only to match the non-fragmented IPv6 ICMPv6 packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmpv6_type, icmp6_m->type);MLX5_SET (fte_match_set_misc3, misc3_v, icmpv6_type, icmp6_v->type & icmp6_m->type);
@@ -7398,12 +7392,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp_m) icmp_m = &rte_flow_item_icmp_mask; -/* -* Force flow only to match the non-fragmented IPv4 ICMP packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmp_type, icmp_m->hdr.icmp_type); MLX5_SET(fte_match_set_misc3, misc3_v, icmp_type,
Signature · 1 line
1.8.3.1
PATCH v4 7/11 net/mlx5: support match on IPv4 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv4 fragmented and non-fragmented packets, using the IPv4 header fragment_offset field.
--- drivers/net/mlx5/mlx5_flow.c | 48 ++++++++---- drivers/net/mlx5/mlx5_flow.h | 10 +++ drivers/net/mlx5/mlx5_flow_dv.c | 156 +++++++++++++++++++++++++++++++------ drivers/net/mlx5/mlx5_flow_verbs.c | 9 ++- 4 files changed, 178 insertions(+), 45 deletions(-)
drivers/net/mlx5/mlx5_flow.c +31 -17
@@ -474,6 +474,8 @@ struct mlx5_flow_tunnel_info {* Bit-masks covering supported fields by the NIC to compare with user mask. * @param[in] size * Bit-masks size in bytes. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -485,6 +487,7 @@ struct mlx5_flow_tunnel_info {const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error) { unsigned int i;
@@ -502,7 +505,7 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"mask/last without a spec is not" " supported"); -if (item->spec && item->last) { +if (item->spec && item->last && !range_accepted) {uint8_t spec[size];uint8_t last[size];unsigned int i;
@@ -1277,7 +1280,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp6_mask, -sizeof (struct rte_flow_item_icmp6 ), error); +sizeof (struct rte_flow_item_icmp6 ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1329,7 +1333,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp_mask, -sizeof (struct rte_flow_item_icmp ), error); +sizeof (struct rte_flow_item_icmp ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1384,7 +1389,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_eth ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -1438,7 +1443,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_vlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (!tunnel && mask->tci !=RTE_BE16 (0x0fff )) {
@@ -1502,6 +1507,7 @@ struct mlx5_flow_tunnel_info {uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error) { const struct rte_flow_item_ipv4 *mask = item->mask;
@@ -1572,7 +1578,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv4 ), - error); + range_accepted, error);if (ret <0 )return ret;return 0 ;
@@ -1592,6 +1598,8 @@ struct mlx5_flow_tunnel_info {* @param[in] acc_mask * Acceptable mask, if NULL default internal default mask * will be used to check whether item fields are supported. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -1671,7 +1679,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv6 ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error);if (ret <0 )return ret;return 0 ;
@@ -1726,7 +1734,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_udp_mask, -sizeof (struct rte_flow_item_udp ), error); +sizeof (struct rte_flow_item_udp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -1781,7 +1790,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)flow_mask, -sizeof (struct rte_flow_item_tcp ), error); +sizeof (struct rte_flow_item_tcp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -1835,7 +1845,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_mask,sizeof (struct rte_flow_item_vxlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -1906,7 +1916,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_gpe_mask,sizeof (struct rte_flow_item_vxlan_gpe ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -1980,7 +1990,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&gre_key_default_mask, -sizeof (rte_be32_t), error); +sizeof (rte_be32_t),MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -2032,7 +2042,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_gre ), error); +sizeof (struct rte_flow_item_gre ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;#ifndef HAVE_MLX5DV_DR
@@ -2107,7 +2118,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_geneve ), error); +sizeof (struct rte_flow_item_geneve ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (spec) {
@@ -2190,7 +2202,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_mpls_mask, -sizeof (struct rte_flow_item_mpls ), error); +sizeof (struct rte_flow_item_mpls ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2245,7 +2258,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_nvgre_mask, -sizeof (struct rte_flow_item_nvgre ), error); +sizeof (struct rte_flow_item_nvgre ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2339,7 +2353,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ecpri ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error); }/* Allocate unique ID for the split Q/RSS subflows. */
drivers/net/mlx5/mlx5_flow.h +10 -0
@@ -330,6 +330,14 @@ enum mlx5_feature_name {#define MLX5_ENCAPSULATION_DECISION_SIZE (sizeof(struct rte_flow_item_eth) + \ sizeof(struct rte_flow_item_ipv4)) +/* IPv4 fragment_offset field contains relevant data in bits 2 to 15. */ +#define MLX5_IPV4_FRAG_OFFSET_MASK \ + (RTE_IPV4_HDR_OFFSET_MASK | RTE_IPV4_HDR_MF_FLAG) + +/* Specific item's fields can accept a range of values (using spec and last). */ +#define MLX5_ITEM_RANGE_NOT_ACCEPTED false +#define MLX5_ITEM_RANGE_ACCEPTED true +/* Software header modify action numbers of a flow. */ #define MLX5_ACT_NUM_MDF_IPV4 1#define MLX5_ACT_NUM_MDF_IPV6 4
@@ -985,6 +993,7 @@ int mlx5_flow_item_acceptable(const struct rte_flow_item *item,const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_eth(const struct rte_flow_item *item, uint64_t item_flags,
@@ -1002,6 +1011,7 @@ int mlx5_flow_validate_item_ipv4(const struct rte_flow_item *item,uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_ipv6(const struct rte_flow_item *item, uint64_t item_flags,
drivers/net/mlx5/mlx5_flow_dv.c +132 -24
210 lines not on this page · raw message
drivers/net/mlx5/mlx5_flow_verbs.c +5 -4
@@ -1312,10 +1312,11 @@ }break ;case RTE_FLOW_ITEM_TYPE_IPV4 : - ret =mlx5_flow_validate_item_ipv4 (items, item_flags, - last_item, - ether_type,NULL , - error); + ret =mlx5_flow_validate_item_ipv4 + (items, item_flags, + last_item, ether_type,NULL , +MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret; last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV4 :
Signature · 1 line
1.8.3.1
PATCH v4 8/11 net/mlx5: support match on IPv6 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv6 fragmented and non-fragmented packets, using the new field frag_ext_exist, added to rte_flow following RFC [1].
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- drivers/net/mlx5/mlx5_flow_dv.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/mlx5/mlx5_flow_dv.c +5 -0
@@ -5211,6 +5211,7 @@ struct field_modify_info modify_tcp[] = { .proto = 0xff, .hop_limits = 0xff, }, + .frag_ext_exist = 1, };const struct rte_flow_item_ecpri nic_ecpri_mask = { .hdr = {
@@ -6519,6 +6520,10 @@ struct field_modify_info modify_tcp[] = { ipv6_m->hdr.hop_limits);MLX5_SET (fte_match_set_lyr_2_4, headers_v, ip_ttl_hoplimit, ipv6_v->hdr.hop_limits & ipv6_m->hdr.hop_limits); +MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag, + !!(ipv6_m->frag_ext_exist)); +MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag, + !!(ipv6_v->frag_ext_exist & ipv6_m->frag_ext_exist)); }/**
Signature · 1 line
1.8.3.1
PATCH v4 9/11 net/mlx5: support match on IPv6 fragment ext. item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch adds to MLX5 PMD the option to match on this item type.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- drivers/net/mlx5/mlx5_flow.h | 4 + drivers/net/mlx5/mlx5_flow_dv.c | 209 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 213 insertions(+)
drivers/net/mlx5/mlx5_flow.h +4 -0
@@ -122,6 +122,10 @@ enum mlx5_feature_name {/* Pattern eCPRI Layer bit. */ #define MLX5_FLOW_LAYER_ECPRI (UINT64_C(1) << 29) +/* IPv6 Fragment Extension Header bit. */ +#define MLX5_FLOW_LAYER_OUTER_L3_IPV6_FRAG_EXT (1u << 30) +#define MLX5_FLOW_LAYER_INNER_L3_IPV6_FRAG_EXT (1u << 31) +/* Outer Masks. */ #define MLX5_FLOW_LAYER_OUTER_L3 \ (MLX5_FLOW_LAYER_OUTER_L3_IPV4 | MLX5_FLOW_LAYER_OUTER_L3_IPV6)
drivers/net/mlx5/mlx5_flow_dv.c +209 -0
233 lines not on this page · raw message
Signature · 1 line
1.8.3.1
PATCH v4 10/11 doc: update release notes for MLX5 L3 frag support
In reply to Dekel PeledThis patch updates 20.11 release notes with the changes included in patches of this series:
1) MLX5 support of matching on IPv4/IPv6 fragmented/non-fragmented packets.
2) ABI change in ethdev struct rte_flow_item_ipv6.
--- doc/guides/rel_notes/release_20_11.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
doc/guides/rel_notes/release_20_11.rst +10 -0
@@ -109,6 +109,11 @@ New Features * Extern objects and functions can be plugged into the pipeline. * Transaction-oriented table updates. +* **Updated Mellanox mlx5 driver.** + + Updated Mellanox mlx5 driver with new features and improvements, including: + + * Added support for matching on fragmented/non-fragmented IPv4/IPv6 packets. Removed Items -------------
@@ -240,6 +245,11 @@ ABI Changes * ``ethdev`` internal functions are marked with ``__rte_internal`` tag. + * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header. Known Issues ------------
Signature · 1 line
1.8.3.1
PATCH v4 11/11 net/mlx5: enforce limitation on IPv6 next proto
In reply to Dekel PeledDue to PRM requirement, the IPv6 header item 'proto' field, indicating the next header protocol, should not be set as extension header. This patch adds the relevant validation, and documents the limitation.
--- doc/guides/nics/mlx5.rst | 7 +++++++ drivers/net/mlx5/mlx5_flow.c | 14 ++++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-)
doc/guides/nics/mlx5.rst +7 -0
@@ -311,6 +311,13 @@ Limitations for some NICs (such as ConnectX-6 Dx and BlueField 2). The capability bit ``scatter_fcs_w_decap_disable`` shows NIC support. +- IPv6 header item 'proto' field, indicating the next header protocol, should + not be set as extension header. + In case the next header is an extension header, it should not be specified in + IPv6 header item 'proto' field. + The last extension header item 'next header' field can specify the following + header protocol type. + Statistics ----------
drivers/net/mlx5/mlx5_flow.c +12 -2
@@ -1645,9 +1645,9 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"IPv6 cannot follow L2/VLAN layer " "which ether type is not IPv6"); +if (mask && spec) + next_proto = mask->hdr.proto & spec->hdr.proto;if (item_flags &MLX5_FLOW_LAYER_IPV6_ENCAP ) { -if (mask && spec) - next_proto = mask->hdr.proto & spec->hdr.proto;if (next_proto ==IPPROTO_IPIP || next_proto ==IPPROTO_IPV6 ) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
@@ -1655,6 +1655,16 @@ struct mlx5_flow_tunnel_info {"multiple tunnel " "not supported"); } +if (next_proto ==IPPROTO_HOPOPTS || + next_proto ==IPPROTO_ROUTING || + next_proto ==IPPROTO_FRAGMENT || + next_proto ==IPPROTO_ESP || + next_proto ==IPPROTO_AH || + next_proto ==IPPROTO_DSTOPTS ) +return rte_flow_error_set (error,EINVAL , +RTE_FLOW_ERROR_TYPE_ITEM , item, +"IPv6 proto (next header) should " +"not be set as extension header" );if (item_flags &MLX5_FLOW_LAYER_IPIP ) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM, item,
Signature · 1 line
1.8.3.1
Hi Dekel,
Quoted 52 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, October 7, 2020 1:54 PM
Subject: [PATCH v4 00/11] support match on L3 fragmented packetsThis series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
In MLX5 PMD, support match on IPv4 fragmented packets, IPv6 fragmented packets, and IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
v4: updaterte_flowdocumentation to clarify use of IPv6 extension header flags.
---Dekel Peled (11):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item net/mlx5: remove handling of ICMP fragmented packets net/mlx5: support match on IPv4 fragment packets net/mlx5: support match on IPv6 fragment packets net/mlx5: support match on IPv6 fragment ext. item
doc: update release notes for MLX5 L3 frag support net/mlx5: enforce limitation on IPv6 next protoapp/test-pmd/cmdline_flow.c | 53 +++++ doc/guides/nics/mlx5.rst | 7 + doc/guides/prog_guide/rte_flow.rst | 34 ++- doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/mlx5/mlx5_flow.c | 62 ++++-- drivers/net/mlx5/mlx5_flow.h | 14 ++ drivers/net/mlx5/mlx5_flow_dv.c | 382 +++++++++++++++++++++++++++++---- drivers/net/mlx5/mlx5_flow_verbs.c | 9 +- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 45 +++- lib/librte_ip_frag/rte_ip_frag.h | 26 +-- lib/librte_net/rte_ip.h | 26 ++- 12 files changed, 579 insertions(+), 90 deletions(-)
Quoted 2 lines
--
1.8.3.1
Thanks,
Ori
v5 cover support match on L3 fragmented packets
In reply to Dekel PeledThis series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
In MLX5 PMD, support match on IPv4 fragmented packets, IPv6 fragmented packets, and IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
v4: update rte_flow documentation to clarify use of IPv6 extension header flags.
v5: update following rebase on recent ICMP changes.
---
Dekel Peled (11):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item net/mlx5: remove handling of ICMP fragmented packets net/mlx5: support match on IPv4 fragment packets net/mlx5: support match on IPv6 fragment packets net/mlx5: support match on IPv6 fragment ext. item
doc: update release notes for MLX5 L3 frag support net/mlx5: enforce limitation on IPv6 next proto
app/test-pmd/cmdline_flow.c | 53 +++++ doc/guides/nics/mlx5.rst | 7 + doc/guides/prog_guide/rte_flow.rst | 34 ++- doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/mlx5/mlx5_flow.c | 62 ++++-- drivers/net/mlx5/mlx5_flow.h | 14 ++ drivers/net/mlx5/mlx5_flow_dv.c | 382 +++++++++++++++++++++++++++++---- drivers/net/mlx5/mlx5_flow_verbs.c | 9 +- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 45 +++- lib/librte_ip_frag/rte_ip_frag.h | 26 +-- lib/librte_net/rte_ip.h | 26 ++- 12 files changed, 579 insertions(+), 90 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v5 1/11 ethdev: add extensions attributes to IPv6 item
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header. To match on non-fragmented IPv6 packets, need to use frag_ext_exist 0. To match on fragmented IPv6 packets, need to use frag_ext_exist 1. To match on any IPv6 packets, the frag_ext_exist field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- doc/guides/prog_guide/rte_flow.rst | 22 +++++++++++++++++++--- lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- 2 files changed, 42 insertions(+), 5 deletions(-)
doc/guides/prog_guide/rte_flow.rst +19 -3
@@ -946,11 +946,27 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate existence of specific extension headers. +Every type of extension header can use a dedicated pattern item, or +the generic `Item: IPV6_EXT`_. +To match on packets containing a specific extension header, an application +should match on the dedicated flag set to 1. +To match on packets not containing a specific extension header, an application +should match on the dedicated flag clear to 0. +In case application doesn't care about the existence of a specific extension +header, it should not specify the dedicated flag for matching. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists. +- ``rout_ext_exist``: Routing extension header exists. +- ``frag_ext_exist``: Fragment extension header exists. +- ``auth_ext_exist``: Authentication extension header exists. +- ``esp_ext_exist``: Encapsulation Security Payload extension header exists. +- ``dest_ext_exist``: Destination Options extension header exists. +- ``mobil_ext_exist``: Mobility extension header exists. +- ``hip_ext_exist``: Host Identity Protocol extension header exists. +- ``shim6_ext_exist``: Shim6 Protocol extension header exists. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.h +23 -2
@@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate existence of specific extension headers. +* Every type of extension header can use a dedicated pattern item, or +* the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t hop_ext_exist:1 ; +/**< Hop-by-Hop Options extension header exists. */ +uint32_t rout_ext_exist:1 ; +/**< Routing extension header exists. */ +uint32_t frag_ext_exist:1 ; +/**< Fragment extension header exists. */ +uint32_t auth_ext_exist:1 ; +/**< Authentication extension header exists. */ +uint32_t esp_ext_exist:1 ; +/**< Encapsulation Security Payload extension header exists. */ +uint32_t dest_ext_exist:1 ; +/**< Destination Options extension header exists. */ +uint32_t mobil_ext_exist:1 ; +/**< Mobility extension header exists. */ +uint32_t hip_ext_exist:1 ; +/**< Host Identity Protocol extension header exists. */ +uint32_t shim6_ext_exist:1 ; +/**< Shim6 Protocol extension header exists. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v5 01/11] ethdev: add extensions attributes to IPv6 item
12/10/2020 12:43, Dekel Peled:
Quoted 5 lines
- * Note: IPv6 options are handled by dedicated pattern items, see
- *RTE_FLOW_ITEM_TYPE_IPV6_EXT.
+ * Dedicated flags indicate existence of specific extension headers.
+ * Every type of extension header can use a dedicated pattern item, or
+ * the generic itemRTE_FLOW_ITEM_TYPE_IPV6_EXT.
I don't understand this last sentence.
lib/librte_ethdev/rte_flow.h struct rte_flow_item_ipv4 { · line 803
Quoted 6 lines
*/
structrte_flow_item_ipv6{lib/librte_ethdev/rte_flow.h +3
-0struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ + uint32_t hop_ext_exist:1; +/**< Hop-by-Hop Options extension header exists. */ + uint32_t rout_ext_exist:1;
"rout" looks weird. Would be "route" appropriate?
Quoted 5 lines
lib/librte_ethdev/rte_flow.h +5
-0+/**< Routing extension header exists. */ + uint32_t frag_ext_exist:1; +/**< Fragment extension header exists. */ + uint32_t auth_ext_exist:1; +/**< Authentication extension header exists. */
lib/librte_ethdev/rte_flow.h struct rte_flow_item_ipv4 { · line 818
Quoted 10 lines
lib/librte_ethdev/rte_flow.h +10
-0+ uint32_t esp_ext_exist:1; +/**< Encapsulation Security Payload extension header exists. */ + uint32_t dest_ext_exist:1; +/**< Destination Options extension header exists. */ + uint32_t mobil_ext_exist:1; +/**< Mobility extension header exists. */ + uint32_t hip_ext_exist:1; +/**< Host Identity Protocol extension header exists. */ + uint32_t shim6_ext_exist:1; +/**< Shim6 Protocol extension header exists. */
About the field names, the "_exist" suffix is pretty clear, but without being able to say why, I feel it is a strange name. I was thinking about renaming the fields with a "has_" prefix. Does it look better?
Re: [dpdk-dev] [PATCH v5 01/11] ethdev: add extensions attributes to IPv6 item
Thanks, PSB.
Quoted 14 lines
-----Original Message-----
From: Thomas Monjalon <[email protected]>
Sent: Monday, October 12, 2020 11:42 PM
To: Ori Kam <[email protected]>; Dekel Peled <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; Asaf Penso <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v5 01/11] ethdev: add extensions attributes to IPv6 item12/10/2020 12:43, Dekel Peled:
Quoted 8 lines
Quoted 6 lines
- * Note: IPv6 options are handled by dedicated pattern items, see
- *RTE_FLOW_ITEM_TYPE_IPV6_EXT.
+ * Dedicated flags indicate existence of specific extension headers.
+ * Every type of extension header can use a dedicated pattern item,
+ or
+ * the generic itemRTE_FLOW_ITEM_TYPE_IPV6_EXT.I don't understand this last sentence.
I'll rephrase.
Quoted 9 lines
lib/librte_ethdev/rte_flow.h struct rte_flow_item_ipv4 { · line 803
Quoted 7 lines
*/
structrte_flow_item_ipv6{lib/librte_ethdev/rte_flow.h +3
-0struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ + uint32_t hop_ext_exist:1; +/**< Hop-by-Hop Options extension header exists. */ + uint32_t rout_ext_exist:1;"rout" looks weird. Would be "route" appropriate?
I'll change to "route".
Quoted 13 lines
Quoted 13 lines
lib/librte_ethdev/rte_flow.h +12
-0+/**< Routing extension header exists. */ + uint32_t frag_ext_exist:1; +/**< Fragment extension header exists. */ + uint32_t auth_ext_exist:1; +/**< Authentication extension header exists. */ + uint32_t esp_ext_exist:1; +/**< Encapsulation Security Payload extension header exists. */ + uint32_t dest_ext_exist:1; +/**< Destination Options extension header exists. */ + uint32_t mobil_ext_exist:1; +/**< Mobility extension header exists. */ + uint32_t hip_ext_exist:1;
Quoted 8 lines
lib/librte_ethdev/rte_flow.h struct rte_flow_item_ipv4 { · line 818
Quoted 3 lines
lib/librte_ethdev/rte_flow.h +3
-0+/**< Host Identity Protocol extension header exists. */ + uint32_t shim6_ext_exist:1; +/**< Shim6 Protocol extension header exists. */ About the field names, the "
_exist" suffix is pretty clear, but without being able to say why, I feel it is a strange name.
I was thinking about renaming the fields with a "has_" prefix. Does it look better?
I'm afraid a "has_" prefix doesn't look appropriate IMHO. I still prefer the "_exist" suffix.
Quoted 1 line
PATCH v5 2/11 ethdev: add IPv6 fragment extension header item
In reply to Dekel PeledApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].
Relevant definitions are moved from lib/librte_ip_frag/rte_ip_frag.h to lib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. struct ipv6_extension_fragment renamed to rte_ipv6_fragment_ext to adapt it to the common naming convention.
Default mask is not defined, since all fields are optional.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++-- lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 20 ++++++++++++++++++++ lib/librte_ip_frag/rte_ip_frag.h | 26 ++------------------------ lib/librte_net/rte_ip.h | 26 ++++++++++++++++++++++++-- 5 files changed, 61 insertions(+), 28 deletions(-)
doc/guides/prog_guide/rte_flow.rst +14 -2
@@ -947,8 +947,8 @@ Item: ``IPV6`` Matches an IPv6 header. Dedicated flags indicate existence of specific extension headers. -Every type of extension header can use a dedicated pattern item, or -the generic `Item: IPV6_EXT`_. +Every type of extension header can use a dedicated pattern item, +for example `Item: IPV6_FRAG_EXT`_, or the generic `Item: IPV6_EXT`_. To match on packets containing a specific extension header, an application should match on the dedicated flag set to 1. To match on packets not containing a specific extension header, an application
@@ -1193,6 +1193,18 @@ Normally preceded by any of: - `Item: IPV6`_ - `Item: IPV6_EXT`_ +Item: ``IPV6_FRAG_EXT`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Matches the presence of IPv6 fragment extension header. + +- ``hdr``: IPv6 fragment extension header definition (``rte_ip.h``). + +Normally preceded by any of: + +- `Item: IPV6`_ +- `Item: IPV6_EXT`_ + Item: ``ICMP6`` ^^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.c +1 -0
@@ -72,6 +72,7 @@ struct rte_flow_desc_data {MK_FLOW_ITEM (VXLAN_GPE ,sizeof (struct rte_flow_item_vxlan_gpe )),MK_FLOW_ITEM (ARP_ETH_IPV4 ,sizeof (struct rte_flow_item_arp_eth_ipv4 )),MK_FLOW_ITEM (IPV6_EXT ,sizeof (struct rte_flow_item_ipv6_ext )), +MK_FLOW_ITEM (IPV6_FRAG_EXT ,sizeof (struct rte_flow_item_ipv6_frag_ext )),MK_FLOW_ITEM (ICMP6 ,sizeof (struct rte_flow_item_icmp6 )),MK_FLOW_ITEM (ICMP6_ND_NS ,sizeof (struct rte_flow_item_icmp6_nd_ns )), MK_FLOW_ITEM(ICMP6_ND_NA, sizeof(struct rte_flow_item_icmp6_nd_na)),
lib/librte_ethdev/rte_flow.h +20 -0
@@ -537,6 +537,12 @@ enum rte_flow_item_type {*/ RTE_FLOW_ITEM_TYPE_ECPRI , +/** +* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, };/**
@@ -1188,6 +1194,20 @@ struct rte_flow_item_ipv6_ext rte_flow_item_ipv6_ext_mask = {#endif /** +* RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT +* +* Matches the presence of IPv6 fragment extension header. +* +* Preceded by any of: +* +* - RTE_FLOW_ITEM_TYPE_IPV6 +* - RTE_FLOW_ITEM_TYPE_IPV6_EXT +*/ +struct rte_flow_item_ipv6_frag_ext { +struct rte_ipv6_fragment_ext hdr; +}; + +/** * RTE_FLOW_ITEM_TYPE_ICMP6 * * Matches any ICMPv6 header.
lib/librte_ip_frag/rte_ip_frag.h +2 -24
@@ -110,30 +110,8 @@ struct rte_ip_frag_tbl { __extension__struct ip_frag_pkt pkt[0 ];/**< hash table. */ }; -/** IPv6 fragment extension header */ -#define RTE_IPV6_EHDR_MF_SHIFT 0 -#define RTE_IPV6_EHDR_MF_MASK 1 -#define RTE_IPV6_EHDR_FO_SHIFT 3 -#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) -#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_FRAG_USED_MASK \ - (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) - -#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) -#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ - (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) - -struct ipv6_extension_fragment { -uint8_t next_header;/**< Next header type */ -uint8_t reserved;/**< Reserved */ -uint16_t frag_data;/**< All fragmentation data */ -uint32_t id;/**< Packet ID */ -} __rte_packed; - - +/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */ +#define ipv6_extension_fragment rte_ipv6_fragment_ext/** * Create a new IP fragmentation table.
lib/librte_net/rte_ip.h +24 -2
@@ -461,8 +461,30 @@ struct rte_ipv6_hdr {return (uint16_t )cksum; } -/* IPv6 fragmentation header size */ -#define RTE_IPV6_FRAG_HDR_SIZE 8 +/** IPv6 fragment extension header. */ +#define RTE_IPV6_EHDR_MF_SHIFT 0 +#define RTE_IPV6_EHDR_MF_MASK 1 +#define RTE_IPV6_EHDR_FO_SHIFT 3 +#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) +#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_FRAG_USED_MASK (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) + +#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) +#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ + (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) + +struct rte_ipv6_fragment_ext { +uint8_t next_header;/**< Next header type */ +uint8_t reserved;/**< Reserved */ +rte_be16_t frag_data;/**< All fragmentation data */ +rte_be32_t id;/**< Packet ID */ +} __rte_packed; + +/* IPv6 fragment extension header size */ +#define RTE_IPV6_FRAG_HDR_SIZE sizeof(struct rte_ipv6_fragment_ext)/** * Parse next IPv6 header extension
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v5 02/11] ethdev: add IPv6 fragment extension header item
12/10/2020 12:43, Dekel Peled:
lib/librte_ip_frag/rte_ip_frag.h struct rte_ip_frag_tbl { · line 114
Quoted 4 lines
lib/librte_ip_frag/rte_ip_frag.h +2
-0+/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */ +#define ipv6_extension_fragment rte_ipv6_fragment_ext
This struct name did not have rte_ prefix,
so I suggest deprecating it during next year. Please Dekel, could you propose a deprecation notice later?
Re: [dpdk-dev] [PATCH v5 02/11] ethdev: add IPv6 fragment extension header item
Yes, thanks.
Quoted 24 lines
-----Original Message-----
From: Thomas Monjalon <[email protected]>
Sent: Monday, October 12, 2020 11:50 PM
To: Dekel Peled <[email protected]>
Cc: Ori Kam <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]
Subject: Re: [dpdk-dev] [PATCH v5 02/11] ethdev: add IPv6 fragment extension header item12/10/2020 12:43, Dekel Peled:
lib/librte_ip_frag/rte_ip_frag.h
Quoted 3 lines
lib/librte_ip_frag/rte_ip_frag.h +1
-0+/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */
Quoted 1 line
+#define
ipv6_extension_fragmentrte_ipv6_fragment_extThis struct name did not have
rte_prefix, so I suggest deprecating it during next year.
Please Dekel, could you propose a deprecation notice later?
PATCH v5 3/11 app/testpmd: support IPv4 fragments
In reply to Dekel PeledThis patch updates testpmd CLI to support fragment_offset field of IPv4 header item.
To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 0 fragment_offset mask 0x3fff ... To match on fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 1 fragment_offset last 0x3fff fragment_offset mask 0x3fff ...
(Use the full available range 1 to 0x3fff to include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, the fragment_offset field should not be specified for match.
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -129,6 +129,7 @@ enum index {ITEM_VLAN_INNER_TYPE ,ITEM_IPV4 ,ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO , ITEM_IPV4_SRC,
@@ -873,6 +874,7 @@ struct parse_action_priv {static const enum index item_ipv4[] = {ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO ,ITEM_IPV4_SRC ,
@@ -2097,6 +2099,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, hdr.type_of_service)), }, + [ITEM_IPV4_FRAGMENT_OFFSET] = { + .name = "fragment_offset", + .help = "fragmentation flags and fragment offset", + .next = NEXT(item_ipv4, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, + hdr.fragment_offset)), + }, [ITEM_IPV4_TTL] = { .name = "ttl", .help = "time to live",
Signature · 1 line
1.8.3.1
PATCH v5 4/11 app/testpmd: support IPv6 fragments
In reply to Dekel Peledrte_flow update, following RFC [1], introduced frag_ext_exist field for IPv6 header item, used to indicate match on fragmented/non-fragmented packets.
This patch updates testpmd CLI to support the new field.
To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 0 frag_ext_exist mask 1 ... To match on fragmented IPv6 packets, need to use pattern:
... ipv6 frag_ext_exist spec 1 frag_ext_exist mask 1 ... To match on any IPv6 packets, the frag_ext_exist field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -141,6 +141,7 @@ enum index {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_ICMP ,ITEM_ICMP_TYPE , ITEM_ICMP_CODE,
@@ -890,6 +891,7 @@ struct parse_action_priv {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_FRAG_EXT_EXIST ,ITEM_NEXT , ZERO, };
@@ -2185,6 +2187,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6, hdr.dst_addr)), }, + [ITEM_IPV6_FRAG_EXT_EXIST] = { + .name = "frag_ext_exist", + .help = "fragment packet attribute", + .next = NEXT(item_ipv6, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6, + frag_ext_exist, 1)), + }, [ITEM_ICMP] = { .name = "icmp", .help = "match ICMP header",
Signature · 1 line
1.8.3.1
PATCH v5 5/11 app/testpmd: support IPv6 fragment extension item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.
To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 / ipv6_frag_ext ...
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- app/test-pmd/cmdline_flow.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
app/test-pmd/cmdline_flow.c +35 -0
@@ -195,6 +195,9 @@ enum index {ITEM_ARP_ETH_IPV4_TPA ,ITEM_IPV6_EXT ,ITEM_IPV6_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT , +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA ,ITEM_ICMP6 ,ITEM_ICMP6_TYPE , ITEM_ICMP6_CODE,
@@ -786,6 +789,7 @@ struct parse_action_priv {ITEM_VXLAN_GPE ,ITEM_ARP_ETH_IPV4 ,ITEM_IPV6_EXT , +ITEM_IPV6_FRAG_EXT ,ITEM_ICMP6 ,ITEM_ICMP6_ND_NS , ITEM_ICMP6_ND_NA,
@@ -1007,6 +1011,13 @@ struct parse_action_priv { ZERO, }; +static const enum index item_ipv6_frag_ext[] = { +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA , +ITEM_NEXT , +ZERO , +}; +static const enum index item_icmp6[] = {ITEM_ICMP6_TYPE ,ITEM_ICMP6_CODE ,
@@ -2578,6 +2589,30 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_ext, next_hdr)), }, + [ITEM_IPV6_FRAG_EXT] = { + .name = "ipv6_frag_ext", + .help = "match presence of IPv6 fragment extension header", + .priv =PRIV_ITEM (IPV6_FRAG_EXT , + sizeof(struct rte_flow_item_ipv6_frag_ext)), + .next = NEXT(item_ipv6_frag_ext), + .call = parse_vc, + }, + [ITEM_IPV6_FRAG_EXT_NEXT_HDR] = { + .name = "next_hdr", + .help = "next header", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ipv6_frag_ext, + hdr.next_header)), + }, + [ITEM_IPV6_FRAG_EXT_FRAG_DATA] = { + .name = "frag_data", + .help = "Fragment flags and offset", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext, + hdr.frag_data)), + }, [ITEM_ICMP6] = { .name = "icmp6", .help = "match any ICMPv6 header",
Signature · 1 line
1.8.3.1
PATCH v5 6/11 net/mlx5: remove handling of ICMP fragmented packets
In reply to Dekel PeledCommit [1] forced setting of match on 'frag' bit mask 1 and value 0. Previous patch in this series added support of match on fragmented and non-fragmented packets on L3 items, so this setting is now redundant.
This patch removes the changes done in [1].
[1] commit 85407db9f60d ("net/mlx5: fix matching for ICMP fragments")
--- drivers/net/mlx5/mlx5_flow_dv.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/net/mlx5/mlx5_flow_dv.c +0 -12
@@ -7345,12 +7345,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp6_m) icmp6_m = &rte_flow_item_icmp6_mask; -/* -* Force flow only to match the non-fragmented IPv6 ICMPv6 packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmpv6_type, icmp6_m->type);MLX5_SET (fte_match_set_misc3, misc3_v, icmpv6_type, icmp6_v->type & icmp6_m->type);
@@ -7400,12 +7394,6 @@ struct field_modify_info modify_tcp[] = {return ;if (!icmp_m) icmp_m = &rte_flow_item_icmp_mask; -/* -* Force flow only to match the non-fragmented IPv4 ICMP packets. -* If only the protocol is specified, no need to match the frag. -*/ -MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag,1 ); -MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag,0 );MLX5_SET (fte_match_set_misc3, misc3_m, icmp_type, icmp_m->hdr.icmp_type); MLX5_SET(fte_match_set_misc3, misc3_v, icmp_type,
Signature · 1 line
1.8.3.1
PATCH v5 7/11 net/mlx5: support match on IPv4 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv4 fragmented and non-fragmented packets, using the IPv4 header fragment_offset field.
--- drivers/net/mlx5/mlx5_flow.c | 48 ++++++++---- drivers/net/mlx5/mlx5_flow.h | 10 +++ drivers/net/mlx5/mlx5_flow_dv.c | 156 +++++++++++++++++++++++++++++++------ drivers/net/mlx5/mlx5_flow_verbs.c | 9 ++- 4 files changed, 178 insertions(+), 45 deletions(-)
drivers/net/mlx5/mlx5_flow.c +31 -17
@@ -800,6 +800,8 @@ struct mlx5_flow_tunnel_info {* Bit-masks covering supported fields by the NIC to compare with user mask. * @param[in] size * Bit-masks size in bytes. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -811,6 +813,7 @@ struct mlx5_flow_tunnel_info {const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error) { unsigned int i;
@@ -828,7 +831,7 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"mask/last without a spec is not" " supported"); -if (item->spec && item->last) { +if (item->spec && item->last && !range_accepted) {uint8_t spec[size];uint8_t last[size];unsigned int i;
@@ -1603,7 +1606,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_icmp6_mask, -sizeof (struct rte_flow_item_icmp6 ), error); +sizeof (struct rte_flow_item_icmp6 ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1661,7 +1665,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_icmp ), error); +sizeof (struct rte_flow_item_icmp ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -1716,7 +1721,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_eth ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -1770,7 +1775,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_vlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (!tunnel && mask->tci !=RTE_BE16 (0x0fff )) {
@@ -1822,6 +1827,8 @@ struct mlx5_flow_tunnel_info {* @param[in] acc_mask * Acceptable mask, if NULL default internal default mask * will be used to check whether item fields are supported. +* @param[in] range_accepted +* True if range of values is accepted for specific fields, false otherwise. * @param[out] error * Pointer to error structure. *
@@ -1834,6 +1841,7 @@ struct mlx5_flow_tunnel_info {uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error) { const struct rte_flow_item_ipv4 *mask = item->mask;
@@ -1904,7 +1912,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv4 ), - error); + range_accepted, error);if (ret <0 )return ret;return 0 ;
@@ -2003,7 +2011,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ipv6 ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error);if (ret <0 )return ret;return 0 ;
@@ -2058,7 +2066,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_udp_mask, -sizeof (struct rte_flow_item_udp ), error); +sizeof (struct rte_flow_item_udp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -2113,7 +2122,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)flow_mask, -sizeof (struct rte_flow_item_tcp ), error); +sizeof (struct rte_flow_item_tcp ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;return 0 ;
@@ -2167,7 +2177,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_mask,sizeof (struct rte_flow_item_vxlan ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -2238,7 +2248,7 @@ struct mlx5_flow_tunnel_info { (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_vxlan_gpe_mask,sizeof (struct rte_flow_item_vxlan_gpe ), - error); +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;if (spec) {
@@ -2312,7 +2322,7 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&gre_key_default_mask, -sizeof (rte_be32_t), error); +sizeof (rte_be32_t),MLX5_ITEM_RANGE_NOT_ACCEPTED , error);return ret; }
@@ -2364,7 +2374,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_gre ), error); +sizeof (struct rte_flow_item_gre ),MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret;#ifndef HAVE_MLX5DV_DR
@@ -2439,7 +2450,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&nic_mask, -sizeof (struct rte_flow_item_geneve ), error); +sizeof (struct rte_flow_item_geneve ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret)return ret;if (spec) {
@@ -2522,7 +2534,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_mpls_mask, -sizeof (struct rte_flow_item_mpls ), error); +sizeof (struct rte_flow_item_mpls ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2577,7 +2590,8 @@ struct mlx5_flow_tunnel_info { ret =mlx5_flow_item_acceptable (item, (const uint8_t *)mask, (const uint8_t *)&rte_flow_item_nvgre_mask, -sizeof (struct rte_flow_item_nvgre ), error); +sizeof (struct rte_flow_item_nvgre ), +MLX5_ITEM_RANGE_NOT_ACCEPTED , error);if (ret <0 )return ret;return 0 ;
@@ -2671,7 +2685,7 @@ struct mlx5_flow_tunnel_info { acc_mask ? (const uint8_t *)acc_mask : (const uint8_t *)&nic_mask,sizeof (struct rte_flow_item_ecpri ), - error); + MLX5_ITEM_RANGE_NOT_ACCEPTED, error); }/* Allocate unique ID for the split Q/RSS subflows. */
drivers/net/mlx5/mlx5_flow.h +10 -0
@@ -330,6 +330,14 @@ enum mlx5_feature_name {#define MLX5_ENCAPSULATION_DECISION_SIZE (sizeof(struct rte_flow_item_eth) + \ sizeof(struct rte_flow_item_ipv4)) +/* IPv4 fragment_offset field contains relevant data in bits 2 to 15. */ +#define MLX5_IPV4_FRAG_OFFSET_MASK \ + (RTE_IPV4_HDR_OFFSET_MASK | RTE_IPV4_HDR_MF_FLAG) + +/* Specific item's fields can accept a range of values (using spec and last). */ +#define MLX5_ITEM_RANGE_NOT_ACCEPTED false +#define MLX5_ITEM_RANGE_ACCEPTED true +/* Software header modify action numbers of a flow. */ #define MLX5_ACT_NUM_MDF_IPV4 1#define MLX5_ACT_NUM_MDF_IPV6 4
@@ -985,6 +993,7 @@ int mlx5_flow_item_acceptable(const struct rte_flow_item *item,const uint8_t *mask, const uint8_t *nic_mask, unsigned int size, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_eth(const struct rte_flow_item *item, uint64_t item_flags,
@@ -1002,6 +1011,7 @@ int mlx5_flow_validate_item_ipv4(const struct rte_flow_item *item,uint64_t last_item, uint16_t ether_type, const struct rte_flow_item_ipv4 *acc_mask, + bool range_accepted, struct rte_flow_error *error); int mlx5_flow_validate_item_ipv6(const struct rte_flow_item *item, uint64_t item_flags,
drivers/net/mlx5/mlx5_flow_dv.c +132 -24
210 lines not on this page · raw message
drivers/net/mlx5/mlx5_flow_verbs.c +5 -4
@@ -1312,10 +1312,11 @@ }break ;case RTE_FLOW_ITEM_TYPE_IPV4 : - ret =mlx5_flow_validate_item_ipv4 (items, item_flags, - last_item, - ether_type,NULL , - error); + ret =mlx5_flow_validate_item_ipv4 + (items, item_flags, + last_item, ether_type,NULL , +MLX5_ITEM_RANGE_NOT_ACCEPTED , + error);if (ret <0 )return ret; last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV4 :
Signature · 1 line
1.8.3.1
PATCH v5 8/11 net/mlx5: support match on IPv6 fragment packets
In reply to Dekel PeledThis patch adds to MLX5 PMD the support of matching on IPv6 fragmented and non-fragmented packets, using the new field frag_ext_exist, added to rte_flow following RFC [1].
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- drivers/net/mlx5/mlx5_flow_dv.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/mlx5/mlx5_flow_dv.c +5 -0
@@ -5211,6 +5211,7 @@ struct field_modify_info modify_tcp[] = { .proto = 0xff, .hop_limits = 0xff, }, + .frag_ext_exist = 1, };const struct rte_flow_item_ecpri nic_ecpri_mask = { .hdr = {
@@ -6519,6 +6520,10 @@ struct field_modify_info modify_tcp[] = { ipv6_m->hdr.hop_limits);MLX5_SET (fte_match_set_lyr_2_4, headers_v, ip_ttl_hoplimit, ipv6_v->hdr.hop_limits & ipv6_m->hdr.hop_limits); +MLX5_SET (fte_match_set_lyr_2_4, headers_m, frag, + !!(ipv6_m->frag_ext_exist)); +MLX5_SET (fte_match_set_lyr_2_4, headers_v, frag, + !!(ipv6_v->frag_ext_exist & ipv6_m->frag_ext_exist)); }/**
Signature · 1 line
1.8.3.1
PATCH v5 9/11 net/mlx5: support match on IPv6 fragment ext. item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch adds to MLX5 PMD the option to match on this item type.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- drivers/net/mlx5/mlx5_flow.h | 4 + drivers/net/mlx5/mlx5_flow_dv.c | 209 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 213 insertions(+)
drivers/net/mlx5/mlx5_flow.h +4 -0
@@ -122,6 +122,10 @@ enum mlx5_feature_name {/* Pattern eCPRI Layer bit. */ #define MLX5_FLOW_LAYER_ECPRI (UINT64_C(1) << 29) +/* IPv6 Fragment Extension Header bit. */ +#define MLX5_FLOW_LAYER_OUTER_L3_IPV6_FRAG_EXT (1u << 30) +#define MLX5_FLOW_LAYER_INNER_L3_IPV6_FRAG_EXT (1u << 31) +/* Outer Masks. */ #define MLX5_FLOW_LAYER_OUTER_L3 \ (MLX5_FLOW_LAYER_OUTER_L3_IPV4 | MLX5_FLOW_LAYER_OUTER_L3_IPV6)
drivers/net/mlx5/mlx5_flow_dv.c +209 -0
233 lines not on this page · raw message
Signature · 1 line
1.8.3.1
PATCH v5 10/11 doc: update release notes for MLX5 L3 frag support
In reply to Dekel PeledThis patch updates 20.11 release notes with the changes included in patches of this series:
1) MLX5 support of matching on IPv4/IPv6 fragmented/non-fragmented packets.
2) ABI change in ethdev struct rte_flow_item_ipv6.
--- doc/guides/rel_notes/release_20_11.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
doc/guides/rel_notes/release_20_11.rst +10 -0
@@ -148,6 +148,11 @@ New Features * Extern objects and functions can be plugged into the pipeline. * Transaction-oriented table updates. +* **Updated Mellanox mlx5 driver.** + + Updated Mellanox mlx5 driver with new features and improvements, including: + + * Added support for matching on fragmented/non-fragmented IPv4/IPv6 packets. Removed Items -------------
@@ -300,6 +305,11 @@ ABI Changes * ``ethdev`` internal functions are marked with ``__rte_internal`` tag. + * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header. Known Issues ------------
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v5 10/11] doc: update release notes for MLX5 L3 frag support
12/10/2020 12:43, Dekel Peled:
Quoted 8 lines
This patch updates 20.11 release notes with the changes included in patches of this series:
1) MLX5 support of matching on IPv4/IPv6 fragmented/non-fragmented packets.
2) ABI change in ethdev structrte_flow_item_ipv6.Signed-off-by Dekel Peled <[email protected]>Acked-by Ori Kam <[email protected]>
Please merge the release notes changes with the code changes in the appropriate patches.
PATCH v5 11/11 net/mlx5: enforce limitation on IPv6 next proto
In reply to Dekel PeledDue to PRM requirement, the IPv6 header item 'proto' field, indicating the next header protocol, should not be set as extension header. This patch adds the relevant validation, and documents the limitation.
--- doc/guides/nics/mlx5.rst | 7 +++++++ drivers/net/mlx5/mlx5_flow.c | 14 ++++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-)
doc/guides/nics/mlx5.rst +7 -0
@@ -311,6 +311,13 @@ Limitations for some NICs (such as ConnectX-6 Dx and BlueField 2). The capability bit ``scatter_fcs_w_decap_disable`` shows NIC support. +- IPv6 header item 'proto' field, indicating the next header protocol, should + not be set as extension header. + In case the next header is an extension header, it should not be specified in + IPv6 header item 'proto' field. + The last extension header item 'next header' field can specify the following + header protocol type. + Statistics ----------
drivers/net/mlx5/mlx5_flow.c +12 -2
@@ -1977,9 +1977,9 @@ struct mlx5_flow_tunnel_info {RTE_FLOW_ERROR_TYPE_ITEM , item,"IPv6 cannot follow L2/VLAN layer " "which ether type is not IPv6"); +if (mask && spec) + next_proto = mask->hdr.proto & spec->hdr.proto;if (item_flags &MLX5_FLOW_LAYER_IPV6_ENCAP ) { -if (mask && spec) - next_proto = mask->hdr.proto & spec->hdr.proto;if (next_proto ==IPPROTO_IPIP || next_proto ==IPPROTO_IPV6 ) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
@@ -1987,6 +1987,16 @@ struct mlx5_flow_tunnel_info {"multiple tunnel " "not supported"); } +if (next_proto ==IPPROTO_HOPOPTS || + next_proto ==IPPROTO_ROUTING || + next_proto ==IPPROTO_FRAGMENT || + next_proto ==IPPROTO_ESP || + next_proto ==IPPROTO_AH || + next_proto ==IPPROTO_DSTOPTS ) +return rte_flow_error_set (error,EINVAL , +RTE_FLOW_ERROR_TYPE_ITEM , item, +"IPv6 proto (next header) should " +"not be set as extension header" );if (item_flags &MLX5_FLOW_LAYER_IPIP ) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM, item,
Signature · 1 line
1.8.3.1
v6 cover support match on L3 fragmented packets
In reply to Dekel PeledThis series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
v4: update rte_flow documentation to clarify use of IPv6 extension header flags.
v5: update following rebase on recent ICMP changes.
v6: - move MLX5 PMD patches to separate series.
- rename IPv6 extension flags for clarity (e.g. frag_ext_exist renamed to has_frag_ext).
---
*** BLURB HERE ***
Dekel Peled (5):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item
app/test-pmd/cmdline_flow.c | 53 ++++++++++++++++++++++++++++++++++ doc/guides/prog_guide/rte_flow.rst | 32 ++++++++++++++++++-- doc/guides/rel_notes/release_20_11.rst | 5 ++++ lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 43 +++++++++++++++++++++++++-- lib/librte_ip_frag/rte_ip_frag.h | 26 ++--------------- lib/librte_net/rte_ip.h | 26 +++++++++++++++-- 7 files changed, 155 insertions(+), 31 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v6 1/5 ethdev: add extensions attributes to IPv6 item
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header. To match on non-fragmented IPv6 packets, need to use has_frag_ext 0. To match on fragmented IPv6 packets, need to use has_frag_ext 1. To match on any IPv6 packets, the has_frag_ext field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- doc/guides/prog_guide/rte_flow.rst | 20 +++++++++++++++++--- doc/guides/rel_notes/release_20_11.rst | 5 +++++ lib/librte_ethdev/rte_flow.h | 23 +++++++++++++++++++++-- 3 files changed, 43 insertions(+), 5 deletions(-)
doc/guides/prog_guide/rte_flow.rst +17 -3
@@ -946,11 +946,25 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate if header contains specific extension headers. +To match on packets containing a specific extension header, an application +should match on the dedicated flag set to 1. +To match on packets not containing a specific extension header, an application +should match on the dedicated flag clear to 0. +In case application doesn't care about the existence of a specific extension +header, it should not specify the dedicated flag for matching. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``has_hop_ext``: header contains Hop-by-Hop Options extension header. +- ``has_route_ext``: header contains Routing extension header. +- ``has_frag_ext``: header contains Fragment extension header. +- ``has_auth_ext``: header contains Authentication extension header. +- ``has_esp_ext``: header contains Encapsulation Security Payload extension header. +- ``has_dest_ext``: header contains Destination Options extension header. +- ``has_mobil_ext``: header contains Mobility extension header. +- ``has_hip_ext``: header contains Host Identity Protocol extension header. +- ``has_shim6_ext``: header contains Shim6 Protocol extension header. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^
doc/guides/rel_notes/release_20_11.rst +5 -0
@@ -314,6 +314,11 @@ ABI Changes * ``ethdev`` internal functions are marked with ``__rte_internal`` tag. + * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header. Known Issues ------------
lib/librte_ethdev/rte_flow.h +21 -2
@@ -792,11 +792,30 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate if header contains specific extension headers. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t has_hop_ext:1 ; +/**< Header contains Hop-by-Hop Options extension header. */ +uint32_t has_route_ext:1 ; +/**< Header contains Routing extension header. */ +uint32_t has_frag_ext:1 ; +/**< Header contains Fragment extension header. */ +uint32_t has_auth_ext:1 ; +/**< Header contains Authentication extension header. */ +uint32_t has_esp_ext:1 ; +/**< Header contains Encapsulation Security Payload extension header. */ +uint32_t has_dest_ext:1 ; +/**< Header contains Destination Options extension header. */ +uint32_t has_mobil_ext:1 ; +/**< Header contains Mobility extension header. */ +uint32_t has_hip_ext:1 ; +/**< Header contains Host Identity Protocol extension header. */ +uint32_t has_shim6_ext:1 ; +/**< Header contains Shim6 Protocol extension header. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v6 1/5] ethdev: add extensions attributes to IPv6 item
13/10/2020 15:32, Dekel Peled:
doc/guides/rel_notes/release_20_11.rst ABI Changes · line 321
Quoted 7 lines
doc/guides/rel_notes/release_20_11.rst +5
-0+ * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header.
You should remove the notice from doc/guides/rel_notes/deprecation.rst
With this change,
PATCH v6 2/5 ethdev: add IPv6 fragment extension header item
In reply to Dekel PeledApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].
Relevant definitions are moved from lib/librte_ip_frag/rte_ip_frag.h to lib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. struct ipv6_extension_fragment renamed to rte_ipv6_fragment_ext to adapt it to the common naming convention.
Default mask is not defined, since all fields are optional.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++ lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 20 ++++++++++++++++++++ lib/librte_ip_frag/rte_ip_frag.h | 26 ++------------------------ lib/librte_net/rte_ip.h | 26 ++++++++++++++++++++++++-- 5 files changed, 59 insertions(+), 26 deletions(-)
doc/guides/prog_guide/rte_flow.rst +12 -0
@@ -1191,6 +1191,18 @@ Normally preceded by any of: - `Item: IPV6`_ - `Item: IPV6_EXT`_ +Item: ``IPV6_FRAG_EXT`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Matches the presence of IPv6 fragment extension header. + +- ``hdr``: IPv6 fragment extension header definition (``rte_ip.h``). + +Normally preceded by any of: + +- `Item: IPV6`_ +- `Item: IPV6_EXT`_ + Item: ``ICMP6`` ^^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.c +1 -0
@@ -72,6 +72,7 @@ struct rte_flow_desc_data {MK_FLOW_ITEM (VXLAN_GPE ,sizeof (struct rte_flow_item_vxlan_gpe )),MK_FLOW_ITEM (ARP_ETH_IPV4 ,sizeof (struct rte_flow_item_arp_eth_ipv4 )),MK_FLOW_ITEM (IPV6_EXT ,sizeof (struct rte_flow_item_ipv6_ext )), +MK_FLOW_ITEM (IPV6_FRAG_EXT ,sizeof (struct rte_flow_item_ipv6_frag_ext )),MK_FLOW_ITEM (ICMP6 ,sizeof (struct rte_flow_item_icmp6 )),MK_FLOW_ITEM (ICMP6_ND_NS ,sizeof (struct rte_flow_item_icmp6_nd_ns )), MK_FLOW_ITEM(ICMP6_ND_NA, sizeof(struct rte_flow_item_icmp6_nd_na)),
lib/librte_ethdev/rte_flow.h +20 -0
@@ -537,6 +537,12 @@ enum rte_flow_item_type {*/ RTE_FLOW_ITEM_TYPE_ECPRI , +/** +* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, };/**
@@ -1186,6 +1192,20 @@ struct rte_flow_item_ipv6_ext rte_flow_item_ipv6_ext_mask = {#endif /** +* RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT +* +* Matches the presence of IPv6 fragment extension header. +* +* Preceded by any of: +* +* - RTE_FLOW_ITEM_TYPE_IPV6 +* - RTE_FLOW_ITEM_TYPE_IPV6_EXT +*/ +struct rte_flow_item_ipv6_frag_ext { +struct rte_ipv6_fragment_ext hdr; +}; + +/** * RTE_FLOW_ITEM_TYPE_ICMP6 * * Matches any ICMPv6 header.
lib/librte_ip_frag/rte_ip_frag.h +2 -24
@@ -110,30 +110,8 @@ struct rte_ip_frag_tbl { __extension__struct ip_frag_pkt pkt[0 ];/**< hash table. */ }; -/** IPv6 fragment extension header */ -#define RTE_IPV6_EHDR_MF_SHIFT 0 -#define RTE_IPV6_EHDR_MF_MASK 1 -#define RTE_IPV6_EHDR_FO_SHIFT 3 -#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) -#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_FRAG_USED_MASK \ - (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) - -#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) -#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ - (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) - -struct ipv6_extension_fragment { -uint8_t next_header;/**< Next header type */ -uint8_t reserved;/**< Reserved */ -uint16_t frag_data;/**< All fragmentation data */ -uint32_t id;/**< Packet ID */ -} __rte_packed; - - +/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */ +#define ipv6_extension_fragment rte_ipv6_fragment_ext/** * Create a new IP fragmentation table.
lib/librte_net/rte_ip.h +24 -2
@@ -461,8 +461,30 @@ struct rte_ipv6_hdr {return (uint16_t )cksum; } -/* IPv6 fragmentation header size */ -#define RTE_IPV6_FRAG_HDR_SIZE 8 +/** IPv6 fragment extension header. */ +#define RTE_IPV6_EHDR_MF_SHIFT 0 +#define RTE_IPV6_EHDR_MF_MASK 1 +#define RTE_IPV6_EHDR_FO_SHIFT 3 +#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) +#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_FRAG_USED_MASK (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) + +#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) +#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ + (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) + +struct rte_ipv6_fragment_ext { +uint8_t next_header;/**< Next header type */ +uint8_t reserved;/**< Reserved */ +rte_be16_t frag_data;/**< All fragmentation data */ +rte_be32_t id;/**< Packet ID */ +} __rte_packed; + +/* IPv6 fragment extension header size */ +#define RTE_IPV6_FRAG_HDR_SIZE sizeof(struct rte_ipv6_fragment_ext)/** * Parse next IPv6 header extension
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v6 2/5] ethdev: add IPv6 fragment extension header item
13/10/2020 15:32, Dekel Peled:
Quoted 11 lines
Applications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].Relevant definitions are moved from
lib/librte_ip_frag/rte_ip_frag.htolib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. structipv6_extension_fragmentrenamed torte_ipv6_fragment_extto adapt it to the common naming convention.
Quoted 6 lines
Default mask is not defined, since all fields are optional.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
Signed-off-by Dekel Peled <[email protected]>Acked-by Ori Kam <[email protected]>
PATCH v6 3/5 app/testpmd: support IPv4 fragments
In reply to Dekel PeledThis patch updates testpmd CLI to support fragment_offset field of IPv4 header item.
To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 0 fragment_offset mask 0x3fff ... To match on fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 1 fragment_offset last 0x3fff fragment_offset mask 0x3fff ...
(Use the full available range 1 to 0x3fff to include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, the fragment_offset field should not be specified for match.
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -130,6 +130,7 @@ enum index {ITEM_VLAN_INNER_TYPE ,ITEM_IPV4 ,ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO , ITEM_IPV4_SRC,
@@ -874,6 +875,7 @@ struct parse_action_priv {static const enum index item_ipv4[] = {ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO ,ITEM_IPV4_SRC ,
@@ -2098,6 +2100,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, hdr.type_of_service)), }, + [ITEM_IPV4_FRAGMENT_OFFSET] = { + .name = "fragment_offset", + .help = "fragmentation flags and fragment offset", + .next = NEXT(item_ipv4, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, + hdr.fragment_offset)), + }, [ITEM_IPV4_TTL] = { .name = "ttl", .help = "time to live",
Signature · 1 line
1.8.3.1
PATCH v6 4/5 app/testpmd: support IPv6 fragments
In reply to Dekel Peledrte_flow update, following RFC [1], introduced has_frag_ext field for IPv6 header item, used to indicate match on fragmented/non-fragmented packets.
This patch updates testpmd CLI to support the new field.
To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6 has_frag_ext spec 0 has_frag_ext mask 1 ... To match on fragmented IPv6 packets, need to use pattern:
... ipv6 has_frag_ext spec 1 has_frag_ext mask 1 ... To match on any IPv6 packets, the has_frag_ext field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -142,6 +142,7 @@ enum index {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_HAS_FRAG_EXT ,ITEM_ICMP ,ITEM_ICMP_TYPE , ITEM_ICMP_CODE,
@@ -891,6 +892,7 @@ struct parse_action_priv {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_HAS_FRAG_EXT ,ITEM_NEXT , ZERO, };
@@ -2186,6 +2188,13 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6, hdr.dst_addr)), }, + [ITEM_IPV6_HAS_FRAG_EXT] = { + .name = "has_frag_ext", + .help = "fragment packet attribute", + .next = NEXT(item_ipv6, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6, + has_frag_ext, 1)), + }, [ITEM_ICMP] = { .name = "icmp", .help = "match ICMP header",
Signature · 1 line
1.8.3.1
PATCH v6 5/5 app/testpmd: support IPv6 fragment extension item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.
To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 / ipv6_frag_ext ...
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- app/test-pmd/cmdline_flow.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
app/test-pmd/cmdline_flow.c +35 -0
@@ -196,6 +196,9 @@ enum index {ITEM_ARP_ETH_IPV4_TPA ,ITEM_IPV6_EXT ,ITEM_IPV6_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT , +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA ,ITEM_ICMP6 ,ITEM_ICMP6_TYPE , ITEM_ICMP6_CODE,
@@ -787,6 +790,7 @@ struct parse_action_priv {ITEM_VXLAN_GPE ,ITEM_ARP_ETH_IPV4 ,ITEM_IPV6_EXT , +ITEM_IPV6_FRAG_EXT ,ITEM_ICMP6 ,ITEM_ICMP6_ND_NS , ITEM_ICMP6_ND_NA,
@@ -1008,6 +1012,13 @@ struct parse_action_priv { ZERO, }; +static const enum index item_ipv6_frag_ext[] = { +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA , +ITEM_NEXT , +ZERO , +}; +static const enum index item_icmp6[] = {ITEM_ICMP6_TYPE ,ITEM_ICMP6_CODE ,
@@ -2579,6 +2590,30 @@ static int comp_set_raw_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_ext, next_hdr)), }, + [ITEM_IPV6_FRAG_EXT] = { + .name = "ipv6_frag_ext", + .help = "match presence of IPv6 fragment extension header", + .priv =PRIV_ITEM (IPV6_FRAG_EXT , + sizeof(struct rte_flow_item_ipv6_frag_ext)), + .next = NEXT(item_ipv6_frag_ext), + .call = parse_vc, + }, + [ITEM_IPV6_FRAG_EXT_NEXT_HDR] = { + .name = "next_hdr", + .help = "next header", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ipv6_frag_ext, + hdr.next_header)), + }, + [ITEM_IPV6_FRAG_EXT_FRAG_DATA] = { + .name = "frag_data", + .help = "Fragment flags and offset", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext, + hdr.frag_data)), + }, [ITEM_ICMP6] = { .name = "icmp6", .help = "match any ICMPv6 header",
Signature · 1 line
1.8.3.1
v7 cover support match on L3 fragmented packets
In reply to Dekel PeledThis series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
v4: update rte_flow documentation to clarify use of IPv6 extension header flags.
v5: update following rebase on recent ICMP changes.
v6: - move MLX5 PMD patches to separate series.
- rename IPv6 extension flags for clarity (e.g. frag_ext_exist renamed to has_frag_ext).
v7: remove the announcement from deprecation file.
---
Dekel Peled (5):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item
app/test-pmd/cmdline_flow.c | 53 ++++++++++++++++++++++++++++++++++ doc/guides/prog_guide/rte_flow.rst | 32 ++++++++++++++++++-- doc/guides/rel_notes/deprecation.rst | 5 ---- doc/guides/rel_notes/release_20_11.rst | 5 ++++ lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 43 +++++++++++++++++++++++++-- lib/librte_ip_frag/rte_ip_frag.h | 26 ++--------------- lib/librte_net/rte_ip.h | 26 +++++++++++++++-- 8 files changed, 155 insertions(+), 36 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v7 1/5 ethdev: add extensions attributes to IPv6 item
Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header.
Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header. To match on non-fragmented IPv6 packets, need to use has_frag_ext 0. To match on fragmented IPv6 packets, need to use has_frag_ext 1. To match on any IPv6 packets, the has_frag_ext field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- doc/guides/prog_guide/rte_flow.rst | 20 +++++++++++++++++--- doc/guides/rel_notes/deprecation.rst | 5 ----- doc/guides/rel_notes/release_20_11.rst | 5 +++++ lib/librte_ethdev/rte_flow.h | 23 +++++++++++++++++++++-- 4 files changed, 43 insertions(+), 10 deletions(-)
doc/guides/prog_guide/rte_flow.rst +17 -3
@@ -946,11 +946,25 @@ Item: ``IPV6`` Matches an IPv6 header. -Note: IPv6 options are handled by dedicated pattern items, see `Item: -IPV6_EXT`_. +Dedicated flags indicate if header contains specific extension headers. +To match on packets containing a specific extension header, an application +should match on the dedicated flag set to 1. +To match on packets not containing a specific extension header, an application +should match on the dedicated flag clear to 0. +In case application doesn't care about the existence of a specific extension +header, it should not specify the dedicated flag for matching. - ``hdr``: IPv6 header definition (``rte_ip.h``). -- Default ``mask`` matches source and destination addresses only. +- ``has_hop_ext``: header contains Hop-by-Hop Options extension header. +- ``has_route_ext``: header contains Routing extension header. +- ``has_frag_ext``: header contains Fragment extension header. +- ``has_auth_ext``: header contains Authentication extension header. +- ``has_esp_ext``: header contains Encapsulation Security Payload extension header. +- ``has_dest_ext``: header contains Destination Options extension header. +- ``has_mobil_ext``: header contains Mobility extension header. +- ``has_hip_ext``: header contains Host Identity Protocol extension header. +- ``has_shim6_ext``: header contains Shim6 Protocol extension header. +- Default ``mask`` matches ``hdr`` source and destination addresses only. Item: ``ICMP`` ^^^^^^^^^^^^^^
doc/guides/rel_notes/deprecation.rst +0 -5
@@ -159,11 +159,6 @@ Deprecation Notices or absence of a VLAN header following the current header, as proposed in RFC https://mails.dpdk.org/archives/dev/2020-August/177536.html. -* ethdev: The ``struct rte_flow_item_ipv6`` struct will be modified to include - additional values, indicating existence or absence of IPv6 extension headers - following the IPv6 header, as proposed in RFC - https://mails.dpdk.org/archives/dev/2020-August/177257.html. - * security: The API ``rte_security_session_create`` takes only single mempool for session and session private data. So the application need to create mempool for twice the number of sessions needed and will also lead to
doc/guides/rel_notes/release_20_11.rst +5 -0
@@ -351,6 +351,11 @@ ABI Changes * ``ethdev`` internal functions are marked with ``__rte_internal`` tag. + * Added extensions' attributes to struct ``rte_flow_item_ipv6``. + A set of additional values added to struct, indicating the existence of + every defined extension header type. + Applications should use the new values for identification of existing + extensions in the packet header. Known Issues ------------
lib/librte_ethdev/rte_flow.h +21 -2
@@ -792,11 +792,30 @@ struct rte_flow_item_ipv4 {* * Matches an IPv6 header. * -* Note: IPv6 options are handled by dedicated pattern items, see -* RTE_FLOW_ITEM_TYPE_IPV6_EXT. +* Dedicated flags indicate if header contains specific extension headers. */ struct rte_flow_item_ipv6 {struct rte_ipv6_hdr hdr;/**< IPv6 header definition. */ +uint32_t has_hop_ext:1 ; +/**< Header contains Hop-by-Hop Options extension header. */ +uint32_t has_route_ext:1 ; +/**< Header contains Routing extension header. */ +uint32_t has_frag_ext:1 ; +/**< Header contains Fragment extension header. */ +uint32_t has_auth_ext:1 ; +/**< Header contains Authentication extension header. */ +uint32_t has_esp_ext:1 ; +/**< Header contains Encapsulation Security Payload extension header. */ +uint32_t has_dest_ext:1 ; +/**< Header contains Destination Options extension header. */ +uint32_t has_mobil_ext:1 ; +/**< Header contains Mobility extension header. */ +uint32_t has_hip_ext:1 ; +/**< Header contains Host Identity Protocol extension header. */ +uint32_t has_shim6_ext:1 ; +/**< Header contains Shim6 Protocol extension header. */ +uint32_t reserved:23 ; +/**< Reserved for future extension headers, must be zero. */ };/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
Signature · 1 line
1.8.3.1
PATCH v7 2/5 ethdev: add IPv6 fragment extension header item
In reply to Dekel PeledApplications handling fragmented IPv6 packets need to match on IPv6 fragment extension header, in order to identify the fragments order and location in the packet.
This patch introduces the IPv6 fragment extension header item, proposed in [1].
Relevant definitions are moved from lib/librte_ip_frag/rte_ip_frag.h to lib/librte_net/rte_ip.h, as they are needed for IPv6 header handling. struct ipv6_extension_fragment renamed to rte_ipv6_fragment_ext to adapt it to the common naming convention.
Default mask is not defined, since all fields are optional.
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++ lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 20 ++++++++++++++++++++ lib/librte_ip_frag/rte_ip_frag.h | 26 ++------------------------ lib/librte_net/rte_ip.h | 26 ++++++++++++++++++++++++-- 5 files changed, 59 insertions(+), 26 deletions(-)
doc/guides/prog_guide/rte_flow.rst +12 -0
@@ -1191,6 +1191,18 @@ Normally preceded by any of: - `Item: IPV6`_ - `Item: IPV6_EXT`_ +Item: ``IPV6_FRAG_EXT`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Matches the presence of IPv6 fragment extension header. + +- ``hdr``: IPv6 fragment extension header definition (``rte_ip.h``). + +Normally preceded by any of: + +- `Item: IPV6`_ +- `Item: IPV6_EXT`_ + Item: ``ICMP6`` ^^^^^^^^^^^^^^^
lib/librte_ethdev/rte_flow.c +1 -0
@@ -72,6 +72,7 @@ struct rte_flow_desc_data {MK_FLOW_ITEM (VXLAN_GPE ,sizeof (struct rte_flow_item_vxlan_gpe )),MK_FLOW_ITEM (ARP_ETH_IPV4 ,sizeof (struct rte_flow_item_arp_eth_ipv4 )),MK_FLOW_ITEM (IPV6_EXT ,sizeof (struct rte_flow_item_ipv6_ext )), +MK_FLOW_ITEM (IPV6_FRAG_EXT ,sizeof (struct rte_flow_item_ipv6_frag_ext )),MK_FLOW_ITEM (ICMP6 ,sizeof (struct rte_flow_item_icmp6 )),MK_FLOW_ITEM (ICMP6_ND_NS ,sizeof (struct rte_flow_item_icmp6_nd_ns )), MK_FLOW_ITEM(ICMP6_ND_NA, sizeof(struct rte_flow_item_icmp6_nd_na)),
lib/librte_ethdev/rte_flow.h +20 -0
@@ -537,6 +537,12 @@ enum rte_flow_item_type {*/ RTE_FLOW_ITEM_TYPE_ECPRI , +/** +* Matches the presence of IPv6 fragment extension header. +* +* See struct rte_flow_item_ipv6_frag_ext. +*/ + RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT, };/**
@@ -1186,6 +1192,20 @@ struct rte_flow_item_ipv6_ext rte_flow_item_ipv6_ext_mask = {#endif /** +* RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT +* +* Matches the presence of IPv6 fragment extension header. +* +* Preceded by any of: +* +* - RTE_FLOW_ITEM_TYPE_IPV6 +* - RTE_FLOW_ITEM_TYPE_IPV6_EXT +*/ +struct rte_flow_item_ipv6_frag_ext { +struct rte_ipv6_fragment_ext hdr; +}; + +/** * RTE_FLOW_ITEM_TYPE_ICMP6 * * Matches any ICMPv6 header.
lib/librte_ip_frag/rte_ip_frag.h +2 -24
@@ -110,30 +110,8 @@ struct rte_ip_frag_tbl { __extension__struct ip_frag_pkt pkt[0 ];/**< hash table. */ }; -/** IPv6 fragment extension header */ -#define RTE_IPV6_EHDR_MF_SHIFT 0 -#define RTE_IPV6_EHDR_MF_MASK 1 -#define RTE_IPV6_EHDR_FO_SHIFT 3 -#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) -#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_FRAG_USED_MASK \ - (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) - -#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) -#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) - -#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ - (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) - -struct ipv6_extension_fragment { -uint8_t next_header;/**< Next header type */ -uint8_t reserved;/**< Reserved */ -uint16_t frag_data;/**< All fragmentation data */ -uint32_t id;/**< Packet ID */ -} __rte_packed; - - +/* struct ipv6_extension_fragment moved to librte_net/rte_ip.h and renamed. */ +#define ipv6_extension_fragment rte_ipv6_fragment_ext/** * Create a new IP fragmentation table.
lib/librte_net/rte_ip.h +24 -2
@@ -464,8 +464,30 @@ struct rte_ipv6_hdr {return (uint16_t )cksum; } -/* IPv6 fragmentation header size */ -#define RTE_IPV6_FRAG_HDR_SIZE 8 +/** IPv6 fragment extension header. */ +#define RTE_IPV6_EHDR_MF_SHIFT 0 +#define RTE_IPV6_EHDR_MF_MASK 1 +#define RTE_IPV6_EHDR_FO_SHIFT 3 +#define RTE_IPV6_EHDR_FO_MASK (~((1 << RTE_IPV6_EHDR_FO_SHIFT) - 1)) +#define RTE_IPV6_EHDR_FO_ALIGN (1 << RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_FRAG_USED_MASK (RTE_IPV6_EHDR_MF_MASK | RTE_IPV6_EHDR_FO_MASK) + +#define RTE_IPV6_GET_MF (x) ((x) & RTE_IPV6_EHDR_MF_MASK) +#define RTE_IPV6_GET_FO (x) ((x) >> RTE_IPV6_EHDR_FO_SHIFT) + +#define RTE_IPV6_SET_FRAG_DATA (fo, mf) \ + (((fo) & RTE_IPV6_EHDR_FO_MASK) | ((mf) & RTE_IPV6_EHDR_MF_MASK)) + +struct rte_ipv6_fragment_ext { +uint8_t next_header;/**< Next header type */ +uint8_t reserved;/**< Reserved */ +rte_be16_t frag_data;/**< All fragmentation data */ +rte_be32_t id;/**< Packet ID */ +} __rte_packed; + +/* IPv6 fragment extension header size */ +#define RTE_IPV6_FRAG_HDR_SIZE sizeof(struct rte_ipv6_fragment_ext)/** * Parse next IPv6 header extension
Signature · 1 line
1.8.3.1
PATCH v7 3/5 app/testpmd: support IPv4 fragments
In reply to Dekel PeledThis patch updates testpmd CLI to support fragment_offset field of IPv4 header item.
To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 0 fragment_offset mask 0x3fff ... To match on fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 1 fragment_offset last 0x3fff fragment_offset mask 0x3fff ...
(Use the full available range 1 to 0x3fff to include all possible values.)
To match on any IPv4 packets, fragmented and non-fragmented, the fragment_offset field should not be specified for match.
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -132,6 +132,7 @@ enum index {ITEM_VLAN_INNER_TYPE ,ITEM_IPV4 ,ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO , ITEM_IPV4_SRC,
@@ -898,6 +899,7 @@ struct parse_action_priv {static const enum index item_ipv4[] = {ITEM_IPV4_TOS , +ITEM_IPV4_FRAGMENT_OFFSET ,ITEM_IPV4_TTL ,ITEM_IPV4_PROTO ,ITEM_IPV4_SRC ,
@@ -2154,6 +2156,13 @@ static int comp_set_sample_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, hdr.type_of_service)), }, + [ITEM_IPV4_FRAGMENT_OFFSET] = { + .name = "fragment_offset", + .help = "fragmentation flags and fragment offset", + .next = NEXT(item_ipv4, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4, + hdr.fragment_offset)), + }, [ITEM_IPV4_TTL] = { .name = "ttl", .help = "time to live",
Signature · 1 line
1.8.3.1
PATCH v7 4/5 app/testpmd: support IPv6 fragments
In reply to Dekel Peledrte_flow update, following RFC [1], introduced has_frag_ext field for IPv6 header item, used to indicate match on fragmented/non-fragmented packets.
This patch updates testpmd CLI to support the new field.
To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6 has_frag_ext spec 0 has_frag_ext mask 1 ... To match on fragmented IPv6 packets, need to use pattern:
... ipv6 has_frag_ext spec 1 has_frag_ext mask 1 ... To match on any IPv6 packets, the has_frag_ext field should not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
--- app/test-pmd/cmdline_flow.c | 9 +++++++++ 1 file changed, 9 insertions(+)
app/test-pmd/cmdline_flow.c +9 -0
@@ -144,6 +144,7 @@ enum index {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_HAS_FRAG_EXT ,ITEM_ICMP ,ITEM_ICMP_TYPE , ITEM_ICMP_CODE,
@@ -915,6 +916,7 @@ struct parse_action_priv {ITEM_IPV6_HOP ,ITEM_IPV6_SRC ,ITEM_IPV6_DST , +ITEM_IPV6_HAS_FRAG_EXT ,ITEM_NEXT , ZERO, };
@@ -2242,6 +2244,13 @@ static int comp_set_sample_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6, hdr.dst_addr)), }, + [ITEM_IPV6_HAS_FRAG_EXT] = { + .name = "has_frag_ext", + .help = "fragment packet attribute", + .next = NEXT(item_ipv6, NEXT_ENTRY(UNSIGNED), item_param), + .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6, + has_frag_ext, 1)), + }, [ITEM_ICMP] = { .name = "icmp", .help = "match ICMP header",
Signature · 1 line
1.8.3.1
PATCH v7 5/5 app/testpmd: support IPv6 fragment extension item
In reply to Dekel Peledrte_flow update, following RFC [1], added to ethdev the rte_flow item ipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.
To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 / ipv6_frag_ext ...
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
--- app/test-pmd/cmdline_flow.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
app/test-pmd/cmdline_flow.c +35 -0
@@ -198,6 +198,9 @@ enum index {ITEM_ARP_ETH_IPV4_TPA ,ITEM_IPV6_EXT ,ITEM_IPV6_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT , +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA ,ITEM_ICMP6 ,ITEM_ICMP6_TYPE , ITEM_ICMP6_CODE,
@@ -811,6 +814,7 @@ struct parse_action_priv {ITEM_VXLAN_GPE ,ITEM_ARP_ETH_IPV4 ,ITEM_IPV6_EXT , +ITEM_IPV6_FRAG_EXT ,ITEM_ICMP6 ,ITEM_ICMP6_ND_NS , ITEM_ICMP6_ND_NA,
@@ -1032,6 +1036,13 @@ struct parse_action_priv { ZERO, }; +static const enum index item_ipv6_frag_ext[] = { +ITEM_IPV6_FRAG_EXT_NEXT_HDR , +ITEM_IPV6_FRAG_EXT_FRAG_DATA , +ITEM_NEXT , +ZERO , +}; +static const enum index item_icmp6[] = {ITEM_ICMP6_TYPE ,ITEM_ICMP6_CODE ,
@@ -2635,6 +2646,30 @@ static int comp_set_sample_index(struct context *, const struct token *, .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_ext, next_hdr)), }, + [ITEM_IPV6_FRAG_EXT] = { + .name = "ipv6_frag_ext", + .help = "match presence of IPv6 fragment extension header", + .priv =PRIV_ITEM (IPV6_FRAG_EXT , + sizeof(struct rte_flow_item_ipv6_frag_ext)), + .next = NEXT(item_ipv6_frag_ext), + .call = parse_vc, + }, + [ITEM_IPV6_FRAG_EXT_NEXT_HDR] = { + .name = "next_hdr", + .help = "next header", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ipv6_frag_ext, + hdr.next_header)), + }, + [ITEM_IPV6_FRAG_EXT_FRAG_DATA] = { + .name = "frag_data", + .help = "Fragment flags and offset", + .next =NEXT (item_ipv6_frag_ext,NEXT_ENTRY (UNSIGNED ), + item_param), + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext, + hdr.frag_data)), + }, [ITEM_ICMP6] = { .name = "icmp6", .help = "match any ICMPv6 header",
Signature · 1 line
1.8.3.1
Quoted 19 lines · Dekel Peled
This series implements support of matching on packets based on the fragmentation attribute of the packet, i.e. if packet is a fragment of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically the IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
v4: updaterte_flowdocumentation to clarify use of IPv6 extension header flags.
v5: update following rebase on recent ICMP changes.
v6: - move MLX5 PMD patches to separate series.
- rename IPv6 extension flags for clarity (e.g.frag_ext_existrenamed tohas_frag_ext).
v7: remove the announcement from deprecation file.
---
Quoted 7 lines
Dekel Peled (5):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item app/testpmd: support IPv4 fragments app/testpmd: support IPv6 fragments app/testpmd: support IPv6 fragment extension item
Series applied to dpdk-next-net/main, thanks.