[dpdk-dev] [PATCH v2 3/3] app/testpmd: reduce tunnel parsing code duplication
From: Ophir Munk
This is a cleanup commit. It assembles all tunnel outer updates into one
function call to avoid code duplications.
It defines RTE_VXLAN_GPE_DEFAULT_PORT (4790) in accordance with all
other tunnel protocol definitions.
Signed-off-by: Ophir Munk
---
app/test-pmd/csumonly.c| 72 +-
lib/librte_net/rte_vxlan.h | 1 +
2 files changed, 21 insertions(+), 52 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 5f29868..3a0e46e 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -63,7 +63,7 @@
#define _htons(x) (x)
#endif
-uint16_t vxlan_gpe_udp_port = 4790;
+uint16_t vxlan_gpe_udp_port = RTE_VXLAN_GPE_DEFAULT_PORT;
uint16_t geneve_udp_port = RTE_GENEVE_DEFAULT_PORT;
/* structure that caches offload info for the current packet */
@@ -181,6 +181,17 @@ parse_ethernet(struct rte_ether_hdr *eth_hdr, struct
testpmd_offload_info *info)
}
}
+/* Fill in outer layers length */
+static void
+update_tunnel_outer(struct testpmd_offload_info *info)
+{
+ info->is_tunnel = 1;
+ info->outer_ethertype = info->ethertype;
+ info->outer_l2_len = info->l2_len;
+ info->outer_l3_len = info->l3_len;
+ info->outer_l4_proto = info->l4_proto;
+}
+
/*
* Parse a GTP protocol header.
* No optional fields and next extension header type.
@@ -201,11 +212,7 @@ parse_gtp(struct rte_udp_hdr *udp_hdr,
udp_hdr->dst_port != _htons(RTE_GTPU_UDP_PORT))
return;
- info->is_tunnel = 1;
- info->outer_ethertype = info->ethertype;
- info->outer_l2_len = info->l2_len;
- info->outer_l3_len = info->l3_len;
- info->outer_l4_proto = info->l4_proto;
+ update_tunnel_outer(info);
info->l2_len = 0;
gtp_hdr = (struct rte_gtp_hdr *)((char *)udp_hdr +
@@ -257,11 +264,7 @@ parse_vxlan(struct rte_udp_hdr *udp_hdr,
RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
return;
- info->is_tunnel = 1;
- info->outer_ethertype = info->ethertype;
- info->outer_l2_len = info->l2_len;
- info->outer_l3_len = info->l3_len;
- info->outer_l4_proto = info->l4_proto;
+ update_tunnel_outer(info);
eth_hdr = (struct rte_ether_hdr *)((char *)udp_hdr +
sizeof(struct rte_udp_hdr) +
@@ -291,11 +294,7 @@ parse_vxlan_gpe(struct rte_udp_hdr *udp_hdr,
if (!vxlan_gpe_hdr->proto || vxlan_gpe_hdr->proto ==
RTE_VXLAN_GPE_TYPE_IPV4) {
- info->is_tunnel = 1;
- info->outer_ethertype = info->ethertype;
- info->outer_l2_len = info->l2_len;
- info->outer_l3_len = info->l3_len;
- info->outer_l4_proto = info->l4_proto;
+ update_tunnel_outer(info);
ipv4_hdr = (struct rte_ipv4_hdr *)((char *)vxlan_gpe_hdr +
vxlan_gpe_len);
@@ -305,11 +304,7 @@ parse_vxlan_gpe(struct rte_udp_hdr *udp_hdr,
info->l2_len = 0;
} else if (vxlan_gpe_hdr->proto == RTE_VXLAN_GPE_TYPE_IPV6) {
- info->is_tunnel = 1;
- info->outer_ethertype = info->ethertype;
- info->outer_l2_len = info->l2_len;
- info->outer_l3_len = info->l3_len;
- info->outer_l4_proto = info->l4_proto;
+ update_tunnel_outer(info);
ipv6_hdr = (struct rte_ipv6_hdr *)((char *)vxlan_gpe_hdr +
vxlan_gpe_len);
@@ -319,11 +314,7 @@ parse_vxlan_gpe(struct rte_udp_hdr *udp_hdr,
info->l2_len = 0;
} else if (vxlan_gpe_hdr->proto == RTE_VXLAN_GPE_TYPE_ETH) {
- info->is_tunnel = 1;
- info->outer_ethertype = info->ethertype;
- info->outer_l2_len = info->l2_len;
- info->outer_l3_len = info->l3_len;
- info->outer_l4_proto = info->l4_proto;
+ update_tunnel_outer(info);
eth_hdr = (struct rte_ether_hdr *)((char *)vxlan_gpe_hdr +
vxlan_gpe_len);
@@ -335,17 +326,6 @@ parse_vxlan_gpe(struct rte_udp_hdr *udp_hdr,
info->l2_len += RTE_ETHER_VXLAN_GPE_HLEN;
}
-/* Fill in outer layers length */
-static void
-update_tunnel_outer(struct testpmd_offload_info *info)
-{
- info->is_tunnel = 1;
- info->outer_ethertype = info->ethertype;
- info->outer_l2_len = info->l2_len;
- info->outer_l3_len = info->l3_len;
- info->outer_l4_proto = info->l4_proto;
-}
-
/* Parse a geneve header */
static void
parse_geneve(struct rte_udp_hdr *udp_hdr,
@@ -412,11 +392,7 @@ parse_gre(struct simple_gre_hdr *gre_hdr, struct
testpmd_offload_info *info)
gre_len += GRE_EXT_LEN;
if (gre_hdr->proto == _htons(RTE_ETHER_TYPE_IPV4)) {
- info->is_tunnel = 1;
- info->outer_ethertype = info->ethertype;
- info->outer_l2_len = info->l2_len;
-
[dpdk-dev] [PATCH v2 2/3] app/testpmd: enable configuring GENEVE port
From: Ophir Munk
IANA has assigned port 6081 as the fixed well-known destination port for
GENEVE. Nevertheless draft-ietf-nvo3-geneve-09 recommends that
implementations make this configurable. This commit enables specifying
any positive UDP destination port number for GENEVE.
Signed-off-by: Ophir Munk
---
app/test-pmd/parameters.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 7cb0e3d..0d135b0 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -70,7 +70,8 @@ usage(char* progname)
"--rxpt= | --rxht= | --rxwt= | --rxfreet= | "
"--txpt= | --txht= | --txwt= | --txfreet= | "
"--txrst= | --tx-offloads= | | --rx-offloads= | "
- "--vxlan-gpe-port= ]\n",
+ "--vxlan-gpe-port= ] "
+ "--geneve-port= ]\n",
progname);
#ifdef RTE_LIBRTE_CMDLINE
printf(" --interactive: run in interactive mode.\n");
@@ -199,6 +200,7 @@ usage(char* progname)
printf(" --rx-offloads=0x: hexadecimal bitmask of RX queue
offloads\n");
printf(" --hot-plug: enable hot plug for device.\n");
printf(" --vxlan-gpe-port=N: UPD port of tunnel VXLAN-GPE\n");
+ printf(" --geneve-port=N: UPD port of tunnel GENEVE\n");
printf(" --mlockall: lock all memory\n");
printf(" --no-mlockall: do not lock all memory\n");
printf(" --mp-alloc : mempool allocation
method.\n"
@@ -664,6 +666,7 @@ launch_args_parse(int argc, char** argv)
{ "rx-offloads",1, 0, 0 },
{ "hot-plug", 0, 0, 0 },
{ "vxlan-gpe-port", 1, 0, 0 },
+ { "geneve-port",1, 0, 0 },
{ "mlockall", 0, 0, 0 },
{ "no-mlockall",0, 0, 0 },
{ "mp-alloc", 1, 0, 0 },
@@ -1298,6 +1301,14 @@ launch_args_parse(int argc, char** argv)
rte_exit(EXIT_FAILURE,
"vxlan-gpe-port must be >=
0\n");
}
+ if (!strcmp(lgopts[opt_idx].name, "geneve-port")) {
+ n = atoi(optarg);
+ if (n >= 0)
+ geneve_udp_port = (uint16_t)n;
+ else
+ rte_exit(EXIT_FAILURE,
+"geneve-port must be >= 0\n");
+ }
if (!strcmp(lgopts[opt_idx].name, "print-event"))
if (parse_event_printing_config(optarg, 1)) {
rte_exit(EXIT_FAILURE,
--
2.8.4
[dpdk-dev] [PATCH v2 0/3] Add GENEVE protocol parsing to testpmd
This patchset adds GENEVE parsing of inner protocols (IPv4-0x0800, IPv6-0x86dd, Ethernet-0x6558) based on IETF draft-ietf-nvo3-geneve-09. v1: Initial version v2: Rebased + Minor update in protocol options field: char opts[0] ===> uint8_t opts[] Ophir Munk (3): app/testpmd: add GENEVE parsing app/testpmd: enable configuring GENEVE port app/testpmd: reduce tunnel parsing code duplication app/test-pmd/csumonly.c | 120 app/test-pmd/parameters.c | 13 - app/test-pmd/testpmd.h | 1 + lib/librte_net/Makefile | 2 +- lib/librte_net/meson.build | 3 +- lib/librte_net/rte_geneve.h | 72 ++ lib/librte_net/rte_vxlan.h | 1 + 7 files changed, 167 insertions(+), 45 deletions(-) create mode 100644 lib/librte_net/rte_geneve.h -- 2.8.4
[dpdk-dev] [PATCH v2 1/3] app/testpmd: add GENEVE parsing
From: Ophir Munk
GENEVE is a widely used tunneling protocol in modern Virtualized
Networks. testpmd already supports parsing of several tunneling
protocols including VXLAN, VXLAN-GPE, GRE. This commit adds GENEVE
parsing of inner protocols (IPv4-0x0800, IPv6-0x86dd, Ethernet-0x6558)
based on IETF draft-ietf-nvo3-geneve-09. GENEVE is considered more
flexible than the other protocols. In terms of protocol format GENEVE
header has a variable length options as opposed to other tunneling
protocols which have a fixed header size.
Signed-off-by: Ophir Munk
---
app/test-pmd/csumonly.c | 70 ++-
app/test-pmd/testpmd.h | 1 +
lib/librte_net/Makefile | 2 +-
lib/librte_net/meson.build | 3 +-
lib/librte_net/rte_geneve.h | 72 +
5 files changed, 145 insertions(+), 3 deletions(-)
create mode 100644 lib/librte_net/rte_geneve.h
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 0a96b24..5f29868 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include "testpmd.h"
@@ -63,6 +64,7 @@
#endif
uint16_t vxlan_gpe_udp_port = 4790;
+uint16_t geneve_udp_port = RTE_GENEVE_DEFAULT_PORT;
/* structure that caches offload info for the current packet */
struct testpmd_offload_info {
@@ -333,6 +335,64 @@ parse_vxlan_gpe(struct rte_udp_hdr *udp_hdr,
info->l2_len += RTE_ETHER_VXLAN_GPE_HLEN;
}
+/* Fill in outer layers length */
+static void
+update_tunnel_outer(struct testpmd_offload_info *info)
+{
+ info->is_tunnel = 1;
+ info->outer_ethertype = info->ethertype;
+ info->outer_l2_len = info->l2_len;
+ info->outer_l3_len = info->l3_len;
+ info->outer_l4_proto = info->l4_proto;
+}
+
+/* Parse a geneve header */
+static void
+parse_geneve(struct rte_udp_hdr *udp_hdr,
+ struct testpmd_offload_info *info)
+{
+ struct rte_ether_hdr *eth_hdr;
+ struct rte_ipv4_hdr *ipv4_hdr;
+ struct rte_ipv6_hdr *ipv6_hdr;
+ struct rte_geneve_hdr *geneve_hdr;
+ uint16_t geneve_len;
+
+ /* Check udp destination port. */
+ if (udp_hdr->dst_port != _htons(geneve_udp_port))
+ return;
+
+ geneve_hdr = (struct rte_geneve_hdr *)((char *)udp_hdr +
+ sizeof(struct rte_udp_hdr));
+ geneve_len = sizeof(struct rte_geneve_hdr) + geneve_hdr->opt_len * 4;
+ if (!geneve_hdr->proto || geneve_hdr->proto ==
+ _htons(RTE_GENEVE_TYPE_IPV4)) {
+ update_tunnel_outer(info);
+ ipv4_hdr = (struct rte_ipv4_hdr *)((char *)geneve_hdr +
+ geneve_len);
+ parse_ipv4(ipv4_hdr, info);
+ info->ethertype = _htons(RTE_ETHER_TYPE_IPV4);
+ info->l2_len = 0;
+ } else if (geneve_hdr->proto == _htons(RTE_GENEVE_TYPE_IPV6)) {
+ update_tunnel_outer(info);
+ ipv6_hdr = (struct rte_ipv6_hdr *)((char *)geneve_hdr +
+ geneve_len);
+ info->ethertype = _htons(RTE_ETHER_TYPE_IPV6);
+ parse_ipv6(ipv6_hdr, info);
+ info->l2_len = 0;
+
+ } else if (geneve_hdr->proto == _htons(RTE_GENEVE_TYPE_ETH)) {
+ update_tunnel_outer(info);
+ eth_hdr = (struct rte_ether_hdr *)((char *)geneve_hdr +
+ geneve_len);
+ parse_ethernet(eth_hdr, info);
+ } else
+ return;
+
+ info->l2_len +=
+ (sizeof(struct rte_udp_hdr) + sizeof(struct rte_geneve_hdr) +
+ ((struct rte_geneve_hdr *)geneve_hdr)->opt_len * 4);
+}
+
/* Parse a gre header */
static void
parse_gre(struct simple_gre_hdr *gre_hdr, struct testpmd_offload_info *info)
@@ -873,9 +933,17 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
}
parse_vxlan(udp_hdr, &info,
m->packet_type);
- if (info.is_tunnel)
+ if (info.is_tunnel) {
tx_ol_flags |=
PKT_TX_TUNNEL_VXLAN;
+ goto tunnel_update;
+ }
+ parse_geneve(udp_hdr, &info);
+ if (info.is_tunnel) {
+ tx_ol_flags |=
+ PKT_TX_TUNNEL_GENEVE;
+ goto tunnel_update;
+ }
} else if (info.l4_proto == IPPROTO_GRE) {
struct simple_gre_hdr *gre_hdr;
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 25a12b1..a60e009 100644
--- a/app/test-pmd/testpmd.h
[dpdk-dev] [PATCH 1/2] common/iavf: add GTPC support
From: Alvin Zhang
Add GTPC header and its field selector.
Signed-off-by: Alvin Zhang
---
drivers/common/iavf/virtchnl.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/common/iavf/virtchnl.h b/drivers/common/iavf/virtchnl.h
index 79515ee..0042cc0 100644
--- a/drivers/common/iavf/virtchnl.h
+++ b/drivers/common/iavf/virtchnl.h
@@ -852,6 +852,7 @@ enum virtchnl_proto_hdr_type {
VIRTCHNL_PROTO_HDR_ESP,
VIRTCHNL_PROTO_HDR_AH,
VIRTCHNL_PROTO_HDR_PFCP,
+ VIRTCHNL_PROTO_HDR_GTPC,
};
/* Protocol header field within a protocol header. */
@@ -916,6 +917,9 @@ enum virtchnl_proto_hdr_field {
VIRTCHNL_PROTO_HDR_PFCP_S_FIELD =
PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_PFCP),
VIRTCHNL_PROTO_HDR_PFCP_SEID,
+ /* GTPC */
+ VIRTCHNL_PROTO_HDR_GTPC_TEID =
+ PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_GTPC),
};
struct virtchnl_proto_hdr {
--
1.8.3.1
[dpdk-dev] [PATCH 2/2] net/iavf: support outer IP hash for GTPC
From: Alvin Zhang
Add patterns for GTPC, now outer IP hash can be configured as input set for
GTPC packet.
Signed-off-by: Alvin Zhang
---
drivers/net/iavf/iavf_generic_flow.c | 36 +++
drivers/net/iavf/iavf_generic_flow.h | 8 +++
drivers/net/iavf/iavf_hash.c | 122 ++-
3 files changed, 164 insertions(+), 2 deletions(-)
diff --git a/drivers/net/iavf/iavf_generic_flow.c
b/drivers/net/iavf/iavf_generic_flow.c
index 321a4dc..44fab4d 100644
--- a/drivers/net/iavf/iavf_generic_flow.c
+++ b/drivers/net/iavf/iavf_generic_flow.c
@@ -315,6 +315,24 @@ enum rte_flow_item_type iavf_pattern_eth_qinq_ipv6_icmp6[]
= {
RTE_FLOW_ITEM_TYPE_END,
};
+/* IPV4 GTPC */
+enum rte_flow_item_type iavf_pattern_eth_ipv4_gtpc[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPC,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+enum rte_flow_item_type iavf_pattern_eth_vlan_ipv4_gtpc[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPC,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
/* IPV4 GTPU (EH) */
enum rte_flow_item_type iavf_pattern_eth_ipv4_gtpu[] = {
RTE_FLOW_ITEM_TYPE_ETH,
@@ -333,6 +351,24 @@ enum rte_flow_item_type iavf_pattern_eth_ipv4_gtpu_eh[] = {
RTE_FLOW_ITEM_TYPE_END,
};
+/* IPV6 GTPC */
+enum rte_flow_item_type iavf_pattern_eth_ipv6_gtpc[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPC,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+enum rte_flow_item_type iavf_pattern_eth_vlan_ipv6_gtpc[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPC,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
/* IPV6 GTPU (EH) */
enum rte_flow_item_type iavf_pattern_eth_ipv6_gtpu[] = {
RTE_FLOW_ITEM_TYPE_ETH,
diff --git a/drivers/net/iavf/iavf_generic_flow.h
b/drivers/net/iavf/iavf_generic_flow.h
index f365cc3..eb466f9 100644
--- a/drivers/net/iavf/iavf_generic_flow.h
+++ b/drivers/net/iavf/iavf_generic_flow.h
@@ -182,10 +182,18 @@
extern enum rte_flow_item_type iavf_pattern_eth_vlan_ipv6_icmp6[];
extern enum rte_flow_item_type iavf_pattern_eth_qinq_ipv6_icmp6[];
+/* IPV4 GTPC */
+extern enum rte_flow_item_type iavf_pattern_eth_ipv4_gtpc[];
+extern enum rte_flow_item_type iavf_pattern_eth_vlan_ipv4_gtpc[];
+
/* IPv4 GTPU (EH) */
extern enum rte_flow_item_type iavf_pattern_eth_ipv4_gtpu[];
extern enum rte_flow_item_type iavf_pattern_eth_ipv4_gtpu_eh[];
+/* IPV4 GTPC */
+extern enum rte_flow_item_type iavf_pattern_eth_ipv6_gtpc[];
+extern enum rte_flow_item_type iavf_pattern_eth_vlan_ipv6_gtpc[];
+
/* IPv6 GTPU (EH) */
extern enum rte_flow_item_type iavf_pattern_eth_ipv6_gtpu[];
extern enum rte_flow_item_type iavf_pattern_eth_ipv6_gtpu_eh[];
diff --git a/drivers/net/iavf/iavf_hash.c b/drivers/net/iavf/iavf_hash.c
index c06b52e..7bc32b0 100644
--- a/drivers/net/iavf/iavf_hash.c
+++ b/drivers/net/iavf/iavf_hash.c
@@ -41,6 +41,8 @@ enum iavf_pattern_hint_type {
IAVF_PHINT_IPV6_GTPU_EH = 0x2000,
IAVF_PHINT_IPV6_GTPU_EH_DWNLINK = 0x4000,
IAVF_PHINT_IPV6_GTPU_EH_UPLINK = 0x8000,
+ IAVF_PHINT_IPV4_GTPC= 0x0001,
+ IAVF_PHINT_IPV6_GTPC= 0x0002,
};
#define IAVF_GTPU_EH_DWNLINK 0
@@ -189,6 +191,10 @@ struct iavf_hash_flow_cfg {
IAVF_PHINT_IPV6_TCP};
static struct iavf_pattern_match_type phint_eth_vlan_ipv6_sctp = {
IAVF_PHINT_IPV6_SCTP};
+static struct iavf_pattern_match_type phint_eth_ipv4_gtpc = {
+ IAVF_PHINT_IPV4_GTPC };
+static struct iavf_pattern_match_type phint_eth_ipv6_gtpc = {
+ IAVF_PHINT_IPV6_GTPC };
/**
* Supported pattern for hash.
@@ -281,6 +287,12 @@ struct iavf_hash_flow_cfg {
&phint_eth_vlan_ipv6_tcp},
{iavf_pattern_eth_vlan_ipv6_sctp, IAVF_INSET_NONE,
&phint_eth_vlan_ipv6_sctp},
+ {iavf_pattern_eth_ipv4_gtpc, IAVF_INSET_NONE, &phint_eth_ipv4_gtpc},
+ {iavf_pattern_eth_ipv6_gtpc, IAVF_INSET_NONE, &phint_eth_ipv6_gtpc},
+ {iavf_pattern_eth_vlan_ipv4_gtpc, IAVF_INSET_NONE,
+ &phint_eth_ipv4_gtpc},
+ {iavf_pattern_eth_vlan_ipv6_gtpc, IAVF_INSET_NONE,
+ &phint_eth_ipv6_gtpc},
{iavf_pattern_empty, IAVF_INSET_NONE, &phint_empty},
};
@@ -290,6 +302,7 @@ struct iavf_hash_flow_cfg {
#define PROTO_COUNT_ONE1
#define PROTO_COUNT_TWO2
#define PROTO_COUNT_THREE 3
+#define PROTO_COUNT_FOUR 4
#define BUFF_NOUSED0
#define F
[dpdk-dev] [PATCH v1 2/4] net/i40e: maximize vector rx burst for i40e
The limitation of burst size in vector rx was removed, since it should
retrieve as much received packets as possible. And also the scattered
receive path should use a wrapper function to achieve the goal of
burst maximizing.
Signed-off-by: Jeff Guo
---
drivers/net/i40e/i40e_rxtx_vec_altivec.c | 60
drivers/net/i40e/i40e_rxtx_vec_avx2.c| 6 +--
drivers/net/i40e/i40e_rxtx_vec_neon.c| 49 +--
drivers/net/i40e/i40e_rxtx_vec_sse.c | 51 ++--
4 files changed, 115 insertions(+), 51 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
index 6862a017e..d26b13c33 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
@@ -190,8 +190,6 @@ desc_to_ptype_v(vector unsigned long descs[4], struct
rte_mbuf **rx_pkts,
/* Notice:
* - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_I40E_VPMD_RX_BURST, only scan RTE_I40E_VPMD_RX_BURST
- * numbers of DD bits
*/
static inline uint16_t
_recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct rte_mbuf **rx_pkts,
@@ -214,9 +212,6 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
};
vector unsigned long dd_check, eop_check;
- /* nb_pkts shall be less equal than RTE_I40E_MAX_RX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, RTE_I40E_MAX_RX_BURST);
-
/* nb_pkts has to be floor-aligned to RTE_I40E_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP);
@@ -447,11 +442,10 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
return nb_pkts_recd;
}
- /* Notice:
- * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_I40E_VPMD_RX_BURST, only scan RTE_I40E_VPMD_RX_BURST
- * numbers of DD bits
- */
+/**
+ * Notice:
+ * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
+ */
uint16_t
i40e_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
@@ -459,15 +453,14 @@ i40e_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
return _recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);
}
- /* vPMD receive routine that reassembles scattered packets
- * Notice:
- * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_I40E_VPMD_RX_BURST, only scan RTE_I40E_VPMD_RX_BURST
- * numbers of DD bits
- */
-uint16_t
-i40e_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
-uint16_t nb_pkts)
+/**
+ * vPMD receive routine that reassembles scattered packets
+ * Notice:
+ * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
+ */
+static uint16_t
+i40e_recv_scattered_burst_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
{
struct i40e_rx_queue *rxq = rx_queue;
uint8_t split_flags[RTE_I40E_VPMD_RX_BURST] = {0};
@@ -500,6 +493,35 @@ i40e_recv_scattered_pkts_vec(void *rx_queue, struct
rte_mbuf **rx_pkts,
&split_flags[i]);
}
+/**
+ * vPMD receive routine that reassembles scattered packets.
+ * Main receive routine that can handle arbitrary burst sizes
+ * Notice:
+ * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
+ */
+uint16_t
+i40e_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+uint16_t nb_pkts)
+{
+ uint16_t retval = 0;
+
+ while (nb_pkts > RTE_I40E_VPMD_RX_BURST) {
+ uint16_t burst;
+
+ burst = i40e_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ RTE_I40E_VPMD_RX_BURST);
+ retval += burst;
+ nb_pkts -= burst;
+ if (burst < RTE_I40E_VPMD_RX_BURST)
+ return retval;
+ }
+
+ return retval + i40e_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ nb_pkts);
+}
+
static inline void
vtx1(volatile struct i40e_tx_desc *txdp,
struct rte_mbuf *pkt, uint64_t flags)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_avx2.c
b/drivers/net/i40e/i40e_rxtx_vec_avx2.c
index 3bcef1363..b3d3153f1 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_avx2.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_avx2.c
@@ -729,7 +729,7 @@ _recv_raw_pkts_vec_avx2(struct i40e_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
return received;
}
-/*
+/**
* Notice:
* - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
*/
@@ -740,7 +740,7 @@ i40e_recv_pkts_vec_avx2(void *rx_queue, struct rte_mbuf
**rx_pkts,
return _recv_raw_pkts_vec_avx2(rx_queue, rx_pkts, nb_pkts, NULL);
}
-/*
+/**
* vPMD receive routine that reassembles single burst of 3
[dpdk-dev] [PATCH v1 1/4] net/ixgbe: maximize vector rx burst for ixgbe
The limitation of burst size in vector rx was removed, since it should
retrieve as much received packets as possible. And also the scattered
receive path should use a wrapper function to achieve the goal of
burst maximizing.
Signed-off-by: Jeff Guo
---
drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 51 -
drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 48 ---
2 files changed, 76 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
index aa27ee177..95e40aa13 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
@@ -206,6 +206,13 @@ desc_to_ptype_v(uint64x2_t descs[4], uint16_t
pkt_type_mask,
vgetq_lane_u32(tunnel_check, 3));
}
+/**
+ * vPMD raw receive routine, only accept(nb_pkts >= RTE_IXGBE_DESCS_PER_LOOP)
+ *
+ * Notice:
+ * - nb_pkts < RTE_IXGBE_DESCS_PER_LOOP, just return no packet
+ * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
+ */
static inline uint16_t
_recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts, uint8_t *split_packet)
@@ -226,9 +233,6 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
uint16x8_t crc_adjust = {0, 0, rxq->crc_len, 0,
rxq->crc_len, 0, 0, 0};
- /* nb_pkts shall be less equal than RTE_IXGBE_MAX_RX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, RTE_IXGBE_MAX_RX_BURST);
-
/* nb_pkts has to be floor-aligned to RTE_IXGBE_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_IXGBE_DESCS_PER_LOOP);
@@ -382,7 +386,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
return nb_pkts_recd;
}
-/*
+/**
* vPMD receive routine, only accept(nb_pkts >= RTE_IXGBE_DESCS_PER_LOOP)
*
* Notice:
@@ -399,19 +403,17 @@ ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
return _recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);
}
-/*
+/**
* vPMD receive routine that reassembles scattered packets
*
* Notice:
* - don't support ol_flags for rss and csum err
* - nb_pkts < RTE_IXGBE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_IXGBE_MAX_RX_BURST, only scan RTE_IXGBE_MAX_RX_BURST
- * numbers of DD bit
* - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
*/
-uint16_t
-ixgbe_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
- uint16_t nb_pkts)
+static uint16_t
+ixgbe_recv_scattered_burst_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
{
struct ixgbe_rx_queue *rxq = rx_queue;
uint8_t split_flags[RTE_IXGBE_MAX_RX_BURST] = {0};
@@ -443,6 +445,35 @@ ixgbe_recv_scattered_pkts_vec(void *rx_queue, struct
rte_mbuf **rx_pkts,
&split_flags[i]);
}
+/**
+ * vPMD receive routine that reassembles scattered packets.
+ * Main receive routine that can handle arbitrary burst sizes
+ * Notice:
+ * - nb_pkts < RTE_IXGBE_DESCS_PER_LOOP, just return no packet
+ */
+uint16_t
+ixgbe_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
+{
+ uint16_t retval = 0;
+
+ while (nb_pkts > RTE_IXGBE_MAX_RX_BURST) {
+ uint16_t burst;
+
+ burst = ixgbe_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ RTE_IXGBE_MAX_RX_BURST);
+ retval += burst;
+ nb_pkts -= burst;
+ if (burst < RTE_IXGBE_MAX_RX_BURST)
+ return retval;
+ }
+
+ return retval + ixgbe_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ nb_pkts);
+}
+
static inline void
vtx1(volatile union ixgbe_adv_tx_desc *txdp,
struct rte_mbuf *pkt, uint64_t flags)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
index 517ca3166..96b207f94 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
@@ -302,13 +302,11 @@ desc_to_ptype_v(__m128i descs[4], uint16_t pkt_type_mask,
get_packet_type(3, pkt_info, etqf_check, tunnel_check);
}
-/*
+/**
* vPMD raw receive routine, only accept(nb_pkts >= RTE_IXGBE_DESCS_PER_LOOP)
*
* Notice:
* - nb_pkts < RTE_IXGBE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_IXGBE_MAX_RX_BURST, only scan RTE_IXGBE_MAX_RX_BURST
- * numbers of DD bit
* - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
*/
static inline uint16_t
@@ -344,9 +342,6 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
__m128i mbuf
[dpdk-dev] [PATCH v1 0/4] maximize vector rx burst for PMDs
The limitation of burst size in vector rx was removed, since it should retrieve as much received packets as possible. And also the scattered receive path should use a wrapper function to achieve the goal of burst maximizing. This patch set aims to maximize vector rx burst for for ixgbe/i40e/ice/iavf PMDs. Jeff Guo (4): net/ixgbe: maximize vector rx burst for ixgbe net/i40e: maximize vector rx burst for i40e net/ice: maximize vector rx burst for ice net/iavf: maximize vector rx burst for iavf drivers/net/i40e/i40e_rxtx_vec_altivec.c | 60 - drivers/net/i40e/i40e_rxtx_vec_avx2.c| 6 +- drivers/net/i40e/i40e_rxtx_vec_neon.c| 49 +++ drivers/net/i40e/i40e_rxtx_vec_sse.c | 51 drivers/net/iavf/iavf_rxtx_vec_sse.c | 102 +-- drivers/net/ice/ice_rxtx_vec_sse.c | 47 --- drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 51 +--- drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 48 --- 8 files changed, 301 insertions(+), 113 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v1 3/4] net/ice: maximize vector rx burst for ice
The limitation of burst size in vector rx was removed, since it should
retrieve as much received packets as possible. And also the scattered
receive path should use a wrapper function to achieve the goal of
burst maximizing.
Signed-off-by: Jeff Guo
---
drivers/net/ice/ice_rxtx_vec_sse.c | 47 +-
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ice/ice_rxtx_vec_sse.c
b/drivers/net/ice/ice_rxtx_vec_sse.c
index 382ef31f3..05f2efa10 100644
--- a/drivers/net/ice/ice_rxtx_vec_sse.c
+++ b/drivers/net/ice/ice_rxtx_vec_sse.c
@@ -207,8 +207,6 @@ ice_rx_desc_to_ptype_v(__m128i descs[4], struct rte_mbuf
**rx_pkts,
/**
* Notice:
* - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > ICE_VPMD_RX_BURST, only scan ICE_VPMD_RX_BURST
- * numbers of DD bits
*/
static inline uint16_t
_ice_recv_raw_pkts_vec(struct ice_rx_queue *rxq, struct rte_mbuf **rx_pkts,
@@ -264,9 +262,6 @@ _ice_recv_raw_pkts_vec(struct ice_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
const __m128i eop_check = _mm_set_epi64x(0x00020002LL,
0x00020002LL);
- /* nb_pkts shall be less equal than ICE_MAX_RX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, ICE_MAX_RX_BURST);
-
/* nb_pkts has to be floor-aligned to ICE_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, ICE_DESCS_PER_LOOP);
@@ -444,8 +439,6 @@ _ice_recv_raw_pkts_vec(struct ice_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
/**
* Notice:
* - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > ICE_VPMD_RX_BURST, only scan ICE_VPMD_RX_BURST
- * numbers of DD bits
*/
uint16_t
ice_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
@@ -454,15 +447,14 @@ ice_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
return _ice_recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);
}
-/* vPMD receive routine that reassembles scattered packets
+/**
+ * vPMD receive routine that reassembles scattered packets
* Notice:
* - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > ICE_VPMD_RX_BURST, only scan ICE_VPMD_RX_BURST
- * numbers of DD bits
*/
-uint16_t
-ice_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
- uint16_t nb_pkts)
+static uint16_t
+ice_recv_scattered_burst_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+uint16_t nb_pkts)
{
struct ice_rx_queue *rxq = rx_queue;
uint8_t split_flags[ICE_VPMD_RX_BURST] = {0};
@@ -496,6 +488,35 @@ ice_recv_scattered_pkts_vec(void *rx_queue, struct
rte_mbuf **rx_pkts,
&split_flags[i]);
}
+/**
+ * vPMD receive routine that reassembles scattered packets.
+ * Main receive routine that can handle arbitrary burst sizes
+ * Notice:
+ * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
+ */
+uint16_t
+ice_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
+{
+ uint16_t retval = 0;
+
+ while (nb_pkts > ICE_VPMD_RX_BURST) {
+ uint16_t burst;
+
+ burst = ice_recv_scattered_burst_vec(rx_queue,
+rx_pkts + retval,
+ICE_VPMD_RX_BURST);
+ retval += burst;
+ nb_pkts -= burst;
+ if (burst < ICE_VPMD_RX_BURST)
+ return retval;
+ }
+
+ return retval + ice_recv_scattered_burst_vec(rx_queue,
+rx_pkts + retval,
+nb_pkts);
+}
+
static inline void
ice_vtx1(volatile struct ice_tx_desc *txdp, struct rte_mbuf *pkt,
uint64_t flags)
--
2.20.1
[dpdk-dev] [PATCH v1 4/4] net/iavf: maximize vector rx burst for iavf
The limitation of burst size in vector rx was removed, since it should
retrieve as much received packets as possible. And also the scattered
receive path should use a wrapper function to achieve the goal of
burst maximizing.
Signed-off-by: Jeff Guo
---
drivers/net/iavf/iavf_rxtx_vec_sse.c | 102 ---
1 file changed, 76 insertions(+), 26 deletions(-)
diff --git a/drivers/net/iavf/iavf_rxtx_vec_sse.c
b/drivers/net/iavf/iavf_rxtx_vec_sse.c
index 85c5bd4af..a4c97e77d 100644
--- a/drivers/net/iavf/iavf_rxtx_vec_sse.c
+++ b/drivers/net/iavf/iavf_rxtx_vec_sse.c
@@ -379,10 +379,9 @@ flex_desc_to_ptype_v(__m128i descs[4], struct rte_mbuf
**rx_pkts,
rx_pkts[3]->packet_type = type_table[_mm_extract_epi16(ptype_all, 7)];
}
-/* Notice:
+/**
+ * Notice:
* - nb_pkts < IAVF_VPMD_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > IAVF_VPMD_RX_MAX_BURST, only scan IAVF_VPMD_RX_MAX_BURST
- * numbers of DD bits
*/
static inline uint16_t
_recv_raw_pkts_vec(struct iavf_rx_queue *rxq, struct rte_mbuf **rx_pkts,
@@ -413,9 +412,6 @@ _recv_raw_pkts_vec(struct iavf_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
offsetof(struct rte_mbuf, rx_descriptor_fields1) + 8);
__m128i dd_check, eop_check;
- /* nb_pkts shall be less equal than IAVF_VPMD_RX_MAX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, IAVF_VPMD_RX_MAX_BURST);
-
/* nb_pkts has to be floor-aligned to IAVF_VPMD_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, IAVF_VPMD_DESCS_PER_LOOP);
@@ -627,10 +623,9 @@ _recv_raw_pkts_vec(struct iavf_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
return nb_pkts_recd;
}
-/* Notice:
+/**
+ * Notice:
* - nb_pkts < IAVF_VPMD_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > IAVF_VPMD_RX_MAX_BURST, only scan IAVF_VPMD_RX_MAX_BURST
- * numbers of DD bits
*/
static inline uint16_t
_recv_raw_pkts_vec_flex_rxd(struct iavf_rx_queue *rxq,
@@ -688,9 +683,6 @@ _recv_raw_pkts_vec_flex_rxd(struct iavf_rx_queue *rxq,
const __m128i eop_check = _mm_set_epi64x(0x00020002LL,
0x00020002LL);
- /* nb_pkts shall be less equal than IAVF_VPMD_RX_MAX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, IAVF_VPMD_RX_MAX_BURST);
-
/* nb_pkts has to be floor-aligned to IAVF_VPMD_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, IAVF_VPMD_DESCS_PER_LOOP);
@@ -921,7 +913,8 @@ _recv_raw_pkts_vec_flex_rxd(struct iavf_rx_queue *rxq,
return nb_pkts_recd;
}
-/* Notice:
+/**
+ * Notice:
* - nb_pkts < IAVF_DESCS_PER_LOOP, just return no packet
* - nb_pkts > IAVF_VPMD_RX_MAX_BURST, only scan IAVF_VPMD_RX_MAX_BURST
* numbers of DD bits
@@ -933,7 +926,8 @@ iavf_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
return _recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);
}
-/* Notice:
+/**
+ * Notice:
* - nb_pkts < IAVF_DESCS_PER_LOOP, just return no packet
* - nb_pkts > IAVF_VPMD_RX_MAX_BURST, only scan IAVF_VPMD_RX_MAX_BURST
* numbers of DD bits
@@ -945,15 +939,14 @@ iavf_recv_pkts_vec_flex_rxd(void *rx_queue, struct
rte_mbuf **rx_pkts,
return _recv_raw_pkts_vec_flex_rxd(rx_queue, rx_pkts, nb_pkts, NULL);
}
-/* vPMD receive routine that reassembles scattered packets
+/**
+ * vPMD receive routine that reassembles scattered packets
* Notice:
* - nb_pkts < IAVF_VPMD_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > VPMD_RX_MAX_BURST, only scan IAVF_VPMD_RX_MAX_BURST
- * numbers of DD bits
*/
-uint16_t
-iavf_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
- uint16_t nb_pkts)
+static uint16_t
+iavf_recv_scattered_burst_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
{
struct iavf_rx_queue *rxq = rx_queue;
uint8_t split_flags[IAVF_VPMD_RX_MAX_BURST] = {0};
@@ -986,16 +979,44 @@ iavf_recv_scattered_pkts_vec(void *rx_queue, struct
rte_mbuf **rx_pkts,
&split_flags[i]);
}
-/* vPMD receive routine that reassembles scattered packets for flex RxD
+/**
+ * vPMD receive routine that reassembles scattered packets.
+ * Main receive routine that can handle arbitrary burst sizes
* Notice:
* - nb_pkts < IAVF_VPMD_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > VPMD_RX_MAX_BURST, only scan IAVF_VPMD_RX_MAX_BURST
- * numbers of DD bits
*/
uint16_t
-iavf_recv_scattered_pkts_vec_flex_rxd(void *rx_queue,
- struct rte_mbuf **rx_pkts,
- uint16_t nb_pkts)
+iavf_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+uint16_t nb_pkts)
+{
+ uint16_t retval = 0;
+
+ while (nb_pkts > IAVF_VPMD_RX_MAX_BURST) {
+ uint16_t burst;
+
+ burst = iavf_recv_scattered_burst_vec(rx_queue,
+ rx_pkts
[dpdk-dev] [PATCH v2] lib/telemetry: fix passing full params string to command
Telemetry only passed the first param to the command handler if multiple
were entered by the user, separated by commas. Telemetry is required to
pass the full params string to the command, by splitting by a comma
delimiter only once to remove the command part of the string. This will
enable future commands to take multiple param values.
Fixes: b1ad0e124536 ("rawdev: add telemetry callbacks")
Fixes: c190daedb9b1 ("ethdev: add telemetry callbacks")
Fixes: 6dd571fd07c3 ("telemetry: introduce new functionality")
Cc: bruce.richard...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Ciara Power
---
v2: modified log string
---
lib/librte_ethdev/rte_ethdev.c | 12 ++--
lib/librte_rawdev/rte_rawdev.c | 6 +-
lib/librte_telemetry/telemetry.c | 2 +-
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 7858ad5f11..a00a9e4d36 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -5284,11 +5284,15 @@ handle_port_xstats(const char *cmd __rte_unused,
struct rte_eth_xstat_name *xstat_names;
int port_id, num_xstats;
int i, ret;
+ char *end_param;
if (params == NULL || strlen(params) == 0 || !isdigit(*params))
return -1;
- port_id = atoi(params);
+ port_id = strtoul(params, &end_param, 0);
+ if (*end_param != '\0')
+ RTE_ETHDEV_LOG(NOTICE,
+ "Extra parameters passed to ethdev telemetry command,
ignoring");
if (!rte_eth_dev_is_valid_port(port_id))
return -1;
@@ -5330,11 +5334,15 @@ handle_port_link_status(const char *cmd __rte_unused,
static const char *status_str = "status";
int ret, port_id;
struct rte_eth_link link;
+ char *end_param;
if (params == NULL || strlen(params) == 0 || !isdigit(*params))
return -1;
- port_id = atoi(params);
+ port_id = strtoul(params, &end_param, 0);
+ if (*end_param != '\0')
+ RTE_ETHDEV_LOG(NOTICE,
+ "Extra parameters passed to ethdev telemetry command,
ignoring");
if (!rte_eth_dev_is_valid_port(port_id))
return -1;
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
index 8f84d0b228..5e5f8f0cca 100644
--- a/lib/librte_rawdev/rte_rawdev.c
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -565,11 +565,15 @@ handle_dev_xstats(const char *cmd __rte_unused,
struct rte_rawdev_xstats_name *xstat_names;
int dev_id, num_xstats, i, ret;
unsigned int *ids;
+ char *end_param;
if (params == NULL || strlen(params) == 0 || !isdigit(*params))
return -1;
- dev_id = atoi(params);
+ dev_id = strtoul(params, &end_param, 0);
+ if (*end_param != '\0')
+ RTE_RDEV_LOG(NOTICE,
+ "Extra parameters passed to rawdev telemetry command,
ignoring");
if (!rte_rawdev_pmd_is_valid_dev(dev_id))
return -1;
diff --git a/lib/librte_telemetry/telemetry.c b/lib/librte_telemetry/telemetry.c
index 0252282735..c6c2948709 100644
--- a/lib/librte_telemetry/telemetry.c
+++ b/lib/librte_telemetry/telemetry.c
@@ -248,7 +248,7 @@ client_handler(void *sock_id)
while (bytes > 0) {
buffer[bytes] = 0;
const char *cmd = strtok(buffer, ",");
- const char *param = strtok(NULL, ",");
+ const char *param = strtok(NULL, "\0");
telemetry_cb fn = unknown_command;
int i;
--
2.17.1
[dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements for nb_pkts
Jeff and Ethernet API maintainers Thomas, Ferruh and Andrew, I'm hijacking this patch thread to propose a small API modification that prevents unnecessarily performance degradations. > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jeff Guo > Sent: Thursday, August 27, 2020 9:55 AM > > The limitation of burst size in vector rx was removed, since it should > retrieve as much received packets as possible. And also the scattered > receive path should use a wrapper function to achieve the goal of > burst maximizing. > > This patch set aims to maximize vector rx burst for for > ixgbe/i40e/ice/iavf PMDs. > Now I'm going to be pedantic and say that it still doesn't conform to the rte_eth_rx_burst() API, because the API does not specify any minimum requirement for nb_pkts. In theory, that could also be fixed in the driver by calling the non-vector function from the vector functions if nb_pkts is too small for the vector implementation. However, I think that calling rte_eth_rx_burst() with a small nb_pkts is silly and not in the spirit of DPDK, and introducing an additional comparison for a small nb_pkts in the driver vector functions would degrade their performance (only slightly, but anyway). Instead, I propose that the rte_eth_rx_burst() API is updated with a minimum requirement for nb_pkts. This minimum requirement should be supported by all Ethernet drivers, instead of having minimum requirements for nb_pkts depending on driver and vector function. I also have a small comment about the description for all the main rx functions: +/** + * vPMD receive routine that reassembles scattered packets. + * Main receive routine that can handle arbitrary burst sizes + * Notice: + * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet + */ It says "can handle arbitrary burst sizes", but bears a notice that it really cannot. So please remove that line from all these functions. Med venlig hilsen / kind regards - Morten Brørup
[dpdk-dev] 回复: [PATCH v2 4/4] test/ring: add check to validate the dequeued objects
Hi, Honnappa
> -邮件原件-
> 发件人: Honnappa Nagarahalli
> 发送时间: 2020年8月27日 4:51
> 收件人: Feifei Wang ; Konstantin Ananyev
>
> 抄送: dev@dpdk.org; nd ; Feifei Wang
> ; Honnappa Nagarahalli
> ; nd
> 主题: RE: [PATCH v2 4/4] test/ring: add check to validate the dequeued objects
>
> Hi Feifei,
> Can you add this at the head of the series? It will help with proving
> that
> the test case fails and hence we need subsequent fixes.
Ok, I will adjust it to the first one of the series.
>
> > -Original Message-
> > From: Feifei Wang
> > Sent: Wednesday, August 5, 2020 1:14 AM
> > To: Honnappa Nagarahalli ; Konstantin
> > Ananyev
> > Cc: dev@dpdk.org; nd ; Feifei Wang
>
> > Subject: [PATCH v2 4/4] test/ring: add check to validate the dequeued
> > objects
> >
> > For the single element enqueue and dequeue in test_ring_basic_ex and
> > test_ring_with_exact_size, add check to validate the dequeued objects.
> >
> > Signed-off-by: Feifei Wang
> > Reviewed-by: Ruifeng Wang
> > Reviewed-by: Honnappa Nagarahalli
> > ---
> > app/test/test_ring.c | 145
> > ---
> > 1 file changed, 109 insertions(+), 36 deletions(-)
> >
> > diff --git a/app/test/test_ring.c b/app/test/test_ring.c index
> > 51bae0d48..a1ff73a05 100644
> > --- a/app/test/test_ring.c
> > +++ b/app/test/test_ring.c
> > @@ -791,15 +791,9 @@ test_ring_basic_ex(void)
> > int ret = -1;
> > unsigned int i, j;
> > struct rte_ring *rp = NULL;
> > - void *obj = NULL;
> > + void **src = NULL, **cur_src = NULL, **dst = NULL, **cur_dst = NULL;
> >
> > for (i = 0; i < RTE_DIM(esize); i++) {
> > - obj = test_ring_calloc(RING_SIZE, esize[i]);
> > - if (obj == NULL) {
> > - printf("%s: failed to alloc memory\n", __func__);
> > - goto fail_test;
> > - }
> > -
> > rp = test_ring_create("test_ring_basic_ex", esize[i], RING_SIZE,
> > SOCKET_ID_ANY,
> > RING_F_SP_ENQ | RING_F_SC_DEQ);
> > @@ -808,6 +802,23 @@ test_ring_basic_ex(void)
> > goto fail_test;
> > }
> >
> > + /* alloc dummy object pointers */
> > + src = test_ring_calloc(RING_SIZE, esize[i]);
> > + if (src == NULL) {
> > + printf("%s: failed to alloc src memory\n", __func__);
> > + goto fail_test;
> > + }
> > + test_ring_mem_init(src, RING_SIZE, esize[i]);
> > + cur_src = src;
> > +
> > + /* alloc some room for copied objects */
> > + dst = test_ring_calloc(RING_SIZE, esize[i]);
> > + if (dst == NULL) {
> > + printf("%s: failed to alloc dst memory\n", __func__);
> > + goto fail_test;
> > + }
> > + cur_dst = dst;
> > +
> > if (rte_ring_lookup("test_ring_basic_ex") != rp) {
> > printf("%s: failed to find ring\n", __func__);
> > goto fail_test;
> > @@ -823,8 +834,9 @@ test_ring_basic_ex(void)
> > rte_ring_free_count(rp));
> >
> > for (j = 0; j < RING_SIZE - 1; j++) {
> > - test_ring_enqueue(rp, obj, esize[i], 1,
> > + test_ring_enqueue(rp, cur_src, esize[i], 1,
> > TEST_RING_THREAD_DEF |
> > TEST_RING_ELEM_SINGLE);
> > + cur_src = test_ring_inc_ptr(cur_src, esize[i], 1);
> > }
> >
> > if (rte_ring_full(rp) != 1) {
> > @@ -834,8 +846,9 @@ test_ring_basic_ex(void)
> > }
> >
> > for (j = 0; j < RING_SIZE - 1; j++) {
> > - test_ring_dequeue(rp, obj, esize[i], 1,
> > + test_ring_dequeue(rp, cur_dst, esize[i], 1,
> > TEST_RING_THREAD_DEF |
> > TEST_RING_ELEM_SINGLE);
> > + cur_dst = test_ring_inc_ptr(cur_dst, esize[i], 1);
> > }
> >
> > if (rte_ring_empty(rp) != 1) {
> > @@ -844,52 +857,88 @@ test_ring_basic_ex(void)
> > goto fail_test;
> > }
> >
> > + /* check data */
> > + if (memcmp(src, dst, RTE_PTR_DIFF(cur_src, src))) {
> > + rte_hexdump(stdout, "src", src,
> > + RTE_PTR_DIFF(cur_src, src));
> > + rte_hexdump(stdout, "dst", dst,
> > + RTE_PTR_DIFF(cur_dst, dst));
> > + printf("data after dequeue is not the same\n");
> > + goto fail_test;
> > + }
> > +
> > +
> > /* Following tests use the configured flags to decide
> > * SP/SC or MP/MC.
> > */
> > + /* reset dst */
> > + if (esize[i] == -1)
> > + memset(dst, 0, RING_SIZE * sizeof(void *));
> > + else
> > + memset(dst, 0, RING_
Re: [dpdk-dev] [PATCH] ci: enable vm env for aarch64 builds
> -Original Message- > From: Juraj Linkeš > Sent: Wednesday, August 26, 2020 8:14 AM > To: 'Aaron Conole' > Cc: tho...@monjalon.net; david.march...@redhat.com; > maicolgabr...@hotmail.com; dev@dpdk.org; Kevin Laatz > > Subject: RE: [PATCH] ci: enable vm env for aarch64 builds > > > > > -Original Message- > > From: Aaron Conole > > Sent: Tuesday, August 25, 2020 4:18 PM > > To: Juraj Linkeš > > Cc: tho...@monjalon.net; david.march...@redhat.com; > > maicolgabr...@hotmail.com; dev@dpdk.org; Kevin Laatz > > > > Subject: Re: [PATCH] ci: enable vm env for aarch64 builds > > > > Juraj Linkeš writes: > > > > > Tests requiring hugepages do not work outside of VM environment > > > because of security limitations. Enable aarch64 builds which run > > > tests to run in a VM to avoid these limitations. > > > > > > Signed-off-by: Juraj Linkeš > > > --- > > > > Cool! > > > > Globally we have dist: set to 'bionic'. Does it make sense to upgrade > > all the distributions to 'focal' ? What is the rationale for not using > > 'bionic'? > > > > I tried bionic, but it ran with focal anyway, so the rationale is 'not > supported for > arm vm environments'. This was released for early adopters, so they may > expand the support to bionic later. > Couple more things. Since this new VM environment runs only on Focal, we want to leave the old jobs and add these new jobs, so we'll have bionic without hugepages and focal with hugepages. The reason is that the same test behave differently when run on a hungepage and non-hugepage environments. Does that make sense? Maybe having a non-hugepage job for just one compiler would be enough? The other thing is switching to focal for all jobs. The difference would be in different lib and compiler versions but I don't know whether we want to dig deep into that or we just want to go with the latest or what's the most important thing to consider. How did you decide in the past? > > > .travis.yml | 10 -- > > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > > > diff --git a/.travis.yml b/.travis.yml index d6eeab371..d73d3e4c5 > > > 100644 > > > --- a/.travis.yml > > > +++ b/.travis.yml > > > @@ -88,7 +88,10 @@ jobs: > > > arch: arm64 > > > compiler: gcc > > >- env: DEF_LIB="shared" RUN_TESTS=1 > > > -arch: arm64 > > > +dist: focal > > > +arch: arm64-graviton2 > > > +virt: vm > > > +group: edge > > > compiler: gcc > > >- env: DEF_LIB="shared" BUILD_DOCS=1 > > > arch: arm64 > > > @@ -103,5 +106,8 @@ jobs: > > > arch: arm64 > > > compiler: clang > > >- env: DEF_LIB="shared" RUN_TESTS=1 > > > -arch: arm64 > > > +dist: focal > > > +arch: arm64-graviton2 > > > +virt: vm > > > +group: edge > > > compiler: clang > >
[dpdk-dev] 回复: [PATCH v2 3/4] test/ring: fix the wrong number of enq/deq elements
> -邮件原件-
> 发件人: Honnappa Nagarahalli
> 发送时间: 2020年8月27日 4:51
> 收件人: Feifei Wang ; Konstantin Ananyev
> ; Olivier Matz ;
> Gavin Hu
> 抄送: dev@dpdk.org; nd ; Feifei Wang
> ; sta...@dpdk.org; Honnappa Nagarahalli
> ; nd
> 主题: RE: [PATCH v2 3/4] test/ring: fix the wrong number of enq/deq elements
>
>
>
> > Subject: [PATCH v2 3/4] test/ring: fix the wrong number of enq/deq elements
> >
> > The actual capacity of ring should be the (RING_SIZE - 1), thus only
> (RING_SIZE
> > - 1) elements can be enqueued into the ring.
> >
> > Fixes: a9fe152363e2 ("test/ring: add custom element size functional tests")
> This issue is not because of this commit. It is coming from af75078fece3.
Sorry for my mistake, I will correct it.
>
> > Cc: honnappa.nagaraha...@arm.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Feifei Wang
> > Reviewed-by: Ruifeng Wang
> > ---
> > app/test/test_ring.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test/test_ring.c b/app/test/test_ring.c index
> > c508a13a9..51bae0d48 100644
> > --- a/app/test/test_ring.c
> > +++ b/app/test/test_ring.c
> > @@ -822,7 +822,7 @@ test_ring_basic_ex(void)
> > printf("%u ring entries are now free\n",
> > rte_ring_free_count(rp));
> >
> > - for (j = 0; j < RING_SIZE; j++) {
> > + for (j = 0; j < RING_SIZE - 1; j++) {
> > test_ring_enqueue(rp, obj, esize[i], 1,
> > TEST_RING_THREAD_DEF |
> > TEST_RING_ELEM_SINGLE);
> Can you validate the return value of this function (which should have caught
> the
> error)?
Ok, only for these two loops, I will add test to validate the number of
enqueue/dequeue elements.
>
> > }
> > @@ -833,7 +833,7 @@ test_ring_basic_ex(void)
> > goto fail_test;
> > }
> >
> > - for (j = 0; j < RING_SIZE; j++) {
> > + for (j = 0; j < RING_SIZE - 1; j++) {
> > test_ring_dequeue(rp, obj, esize[i], 1,
> > TEST_RING_THREAD_DEF |
> > TEST_RING_ELEM_SINGLE);
> Same here.
>
> > }
> > --
> > 2.17.1
Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory
Hi Phil, thanks for taking a look at this. Indeed, the cmpxchg will have release semantics, but implicit barriers do not provide the same ordering guarantees as DMB ISH, ie, atomic_thread_fence(__ATOMIC_ACQ_REL). Let me try to explain the scenario. Here is a pseudo-ARM assembly with the instructions involved: STR me->locked = 1 // 1: initialize the node LDAXR pred = tail // 2: cmpxchg STLXR tail = me// 3: cmpxchg STR pred->next = me // 4: the problematic store Now, ARM allows instruction 1 and 2 to be reordered, and also instructions 3 and 4 to be reordered: LDAXR pred = tail // 2: cmpxchg (acquires can be moved up) STR me-> locked = 1 // 1: initialize the node STR pred->next = me // 4: the problematic store STLXR tail = me// 3: cmpxchg (releases can be moved down) And since stores 1 and 4 can be reordered too, the following execution is possible: LDAXR pred = tail // 2: cmpxchg STR pred->next = me // 4: the problematic store STR me-> locked = 1 // 1: initialize the node STLXR tail = me// 3: cmpxchg In this subtle situation, the locking-thread can overwrite the store to next->locked of the unlocking-thread (if it occurs between 4 and 1), and subsequently hang waiting for me->locked to become 0. We couldn't reproduce this with our available hardware, but we "reproduced" it with the RMEM model checker, which precisely models the ARM memory model (https://github.com/rems-project/rmem). The GenMC model checker (https://github.com/MPI-SWS/genmc) also finds the issue, but its intermediate memory model is slightly more general than the ARM model. The release attached to store (4) prevents (1) to reordering with it. Please, let me know if that makes sense or if I am missing something. Thanks, -Diogo -Original Message- From: Phil Yang [mailto:phil.y...@arm.com] Sent: Wednesday, August 26, 2020 12:17 PM To: Diogo Behrens Cc: dev@dpdk.org; nd ; Honnappa Nagarahalli ; nd Subject: RE: [PATCH] librte_eal: fix mcslock hang on weak memory Diogo Behrens writes: > Subject: [PATCH] librte_eal: fix mcslock hang on weak memory > > The initialization me->locked=1 in lock() must happen before > next->locked=0 in unlock(), otherwise a thread may hang forever, > waiting me->locked become 0. On weak memory systems (sHi Puch as ARMv8), > the current implementation allows me->locked=1 to be reordered with > announcing the node (pred->next=me) and, consequently, to be > reordered with next->locked=0 in unlock(). > > This fix adds a release barrier to pred->next=me, forcing > me->locked=1 to happen before this operation. > > Signed-off-by: Diogo Behrens > --- > lib/librte_eal/include/generic/rte_mcslock.h | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/lib/librte_eal/include/generic/rte_mcslock.h > b/lib/librte_eal/include/generic/rte_mcslock.h > index 2bef28351..ce553f547 100644 > --- a/lib/librte_eal/include/generic/rte_mcslock.h > +++ b/lib/librte_eal/include/generic/rte_mcslock.h > @@ -68,7 +68,14 @@ rte_mcslock_lock(rte_mcslock_t **msl, rte_mcslock_t > *me) >*/ > return; > } > - __atomic_store_n(&prev->next, me, __ATOMIC_RELAXED); > + /* The store to me->next above should also complete before the > node is > + * visible to predecessor thread releasing the lock. Hence, the store > + * prev->next also requires release semantics. Note that, for > example, > + * on ARM, the release semantics in the exchange operation is not > + * strong as a release fence and is not sufficient to enforce the > + * desired order here. Hi Diogo, I didn't quite understand why the exchange operation with ACQ_REL memory ordering is not sufficient. It emits 'stlxr' on armv8.0-a and 'swpal' on armv8.1-a (with LSE support). Both of these two instructions contain a release semantics. Please check the URL for the detail. https://gcc.godbolt.org/z/Mc4373 BTW, if you captured a deadlock issue on your testbed, could you please share your test case here? Thanks, Phil > + */ > + __atomic_store_n(&prev->next, me, __ATOMIC_RELEASE); > > /* The while-load of me->locked should not move above the previous >* store to prev->next. Otherwise it will cause a deadlock. Need a > -- > 2.28.0 >
[dpdk-dev] 回复: [PATCH v2 2/4] test/ring: fix wrong size used in memcmp
> -邮件原件-
> 发件人: Honnappa Nagarahalli
> 发送时间: 2020年8月27日 4:52
> 收件人: Feifei Wang ; Konstantin Ananyev
> ; Gavin Hu ; Olivier
> Matz
> 抄送: dev@dpdk.org; nd ; Feifei Wang
> ; sta...@dpdk.org; Honnappa Nagarahalli
> ; nd
> 主题: RE: [PATCH v2 2/4] test/ring: fix wrong size used in memcmp
>
>
>
> >
> > When using memcmp function to check data, the third param should be
> > the size of all elements, rather than the number of the elements.
> >
> > Fixes: a9fe152363e2 ("test/ring: add custom element size functional
> > tests")
> > Cc: honnappa.nagaraha...@arm.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Feifei Wang
> > Reviewed-by: Ruifeng Wang
> > ---
> > app/test/test_ring.c | 31 +--
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/app/test/test_ring.c b/app/test/test_ring.c index
> > 0ae97d341..c508a13a9 100644
> > --- a/app/test/test_ring.c
> > +++ b/app/test/test_ring.c
> > @@ -444,7 +444,12 @@ test_ring_burst_bulk_tests1(unsigned int test_idx)
> > TEST_RING_VERIFY(rte_ring_empty(r));
> >
> > /* check data */
> > - TEST_RING_VERIFY(memcmp(src, dst, rsz) == 0);
> > + if (esize[i] == -1) {
> > + TEST_RING_VERIFY(memcmp(src, dst,
> > + rsz * sizeof(void *)) == 0);
> > + } else
> > + TEST_RING_VERIFY(memcmp(src, dst,
> > + rsz * esize[i]) == 0);
> Can you implement a function similar to 'test_ring_mem_init' to do this
> comparison?
Ok, the new function named 'test_ring_mem_cmp' will be added.
>
> > }
> >
> > /* Free memory before test completed */ @@ -538,9 +543,11
> @@
> > test_ring_burst_bulk_tests2(unsigned int test_idx)
> > cur_dst = test_ring_inc_ptr(cur_dst, esize[i], MAX_BULK);
> >
> > /* check data */
> > - if (memcmp(src, dst, cur_dst - dst)) {
> > - rte_hexdump(stdout, "src", src, cur_src - src);
> > - rte_hexdump(stdout, "dst", dst, cur_dst - dst);
> > + if (memcmp(src, dst, RTE_PTR_DIFF(cur_dst, dst))) {
> > + rte_hexdump(stdout, "src", src,
> > + RTE_PTR_DIFF(cur_src, src));
> > + rte_hexdump(stdout, "dst", dst,
> > + RTE_PTR_DIFF(cur_dst, dst));
> I do not think, this change and the rest below are bug fixes. Can you please
> separate them into another commit?
Actually, in the original code, 'memcmp' wants to check all bytes and '
rte_hexdump ' wants to print all bytes.
However, 'cur_dst - dst' and 'cur_src - src' is the number of all elements
rather the bytes of all elements.
As a result, we need to correct it and make them check all bytes of the ring.
>
> > printf("data after dequeue is not the same\n");
> > goto fail;
> > }
> > @@ -614,9 +621,11 @@ test_ring_burst_bulk_tests3(unsigned int test_idx)
> > }
> >
> > /* check data */
> > - if (memcmp(src, dst, cur_dst - dst)) {
> > - rte_hexdump(stdout, "src", src, cur_src - src);
> > - rte_hexdump(stdout, "dst", dst, cur_dst - dst);
> > + if (memcmp(src, dst, RTE_PTR_DIFF(cur_dst, dst))) {
> > + rte_hexdump(stdout, "src", src,
> > + RTE_PTR_DIFF(cur_src, src));
> > + rte_hexdump(stdout, "dst", dst,
> > + RTE_PTR_DIFF(cur_dst, dst));
> > printf("data after dequeue is not the same\n");
> > goto fail;
> > }
> > @@ -747,9 +756,11 @@ test_ring_burst_bulk_tests4(unsigned int test_idx)
> > goto fail;
> >
> > /* check data */
> > - if (memcmp(src, dst, cur_dst - dst)) {
> > - rte_hexdump(stdout, "src", src, cur_src - src);
> > - rte_hexdump(stdout, "dst", dst, cur_dst - dst);
> > + if (memcmp(src, dst, RTE_PTR_DIFF(cur_dst, dst))) {
> > + rte_hexdump(stdout, "src", src,
> > + RTE_PTR_DIFF(cur_src, src));
> > + rte_hexdump(stdout, "dst", dst,
> > + RTE_PTR_DIFF(cur_dst, dst));
> > printf("data after dequeue is not the same\n");
> > goto fail;
> > }
> > --
> > 2.17.1
Re: [dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements for nb_pkts
On Thu, Aug 27, 2020 at 10:40:11AM +0200, Morten Brørup wrote: > Jeff and Ethernet API maintainers Thomas, Ferruh and Andrew, > > I'm hijacking this patch thread to propose a small API modification that > prevents unnecessarily performance degradations. > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jeff Guo > > Sent: Thursday, August 27, 2020 9:55 AM > > > > The limitation of burst size in vector rx was removed, since it should > > retrieve as much received packets as possible. And also the scattered > > receive path should use a wrapper function to achieve the goal of > > burst maximizing. > > > > This patch set aims to maximize vector rx burst for for > > ixgbe/i40e/ice/iavf PMDs. > > > > Now I'm going to be pedantic and say that it still doesn't conform to the > rte_eth_rx_burst() API, because the API does not specify any minimum > requirement for nb_pkts. > > In theory, that could also be fixed in the driver by calling the non-vector > function from the vector functions if nb_pkts is too small for the vector > implementation. > > However, I think that calling rte_eth_rx_burst() with a small nb_pkts is > silly and not in the spirit of DPDK, and introducing an additional comparison > for a small nb_pkts in the driver vector functions would degrade their > performance (only slightly, but anyway). > Actually, I'd like to see a confirmed measurement showing a slowdown before we discard such an option. :-) While I agree that using small bursts is not keeping with the design approach of DPDK of using large bursts to amortize costs and allow prefetching, there are cases where a user/app may want a small burst size, e.g. 4, for latency reasons, and we need a way to support that. Since the path selection is dynamic, we need to either: a) provide a way for the user to specify that they will use smaller bursts and so that vector functions should not be used b) have the vector functions transparently fallback to the scalar ones if used with smaller bursts Of these, option b) is simpler, and should be low cost since any check is just once per burst, and - assuming an app is written using the same request-size each time - should be entirely predictable after the first call. /Bruce
Re: [dpdk-dev] [PATCH v2] lib/telemetry: fix passing full params string to command
On Thu, Aug 27, 2020 at 09:39:22AM +0100, Ciara Power wrote:
> Telemetry only passed the first param to the command handler if multiple
> were entered by the user, separated by commas. Telemetry is required to
> pass the full params string to the command, by splitting by a comma
> delimiter only once to remove the command part of the string. This will
> enable future commands to take multiple param values.
>
> Fixes: b1ad0e124536 ("rawdev: add telemetry callbacks")
> Fixes: c190daedb9b1 ("ethdev: add telemetry callbacks")
> Fixes: 6dd571fd07c3 ("telemetry: introduce new functionality")
> Cc: bruce.richard...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ciara Power
>
Missed threading with V1, but otherwise LGTM.
Acked-by: Bruce Richardson
Re: [dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements for nb_pkts
> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Thursday, August 27, 2020 11:10 AM > > On Thu, Aug 27, 2020 at 10:40:11AM +0200, Morten Brørup wrote: > > Jeff and Ethernet API maintainers Thomas, Ferruh and Andrew, > > > > I'm hijacking this patch thread to propose a small API modification > that prevents unnecessarily performance degradations. > > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jeff Guo > > > Sent: Thursday, August 27, 2020 9:55 AM > > > > > > The limitation of burst size in vector rx was removed, since it > should > > > retrieve as much received packets as possible. And also the > scattered > > > receive path should use a wrapper function to achieve the goal of > > > burst maximizing. > > > > > > This patch set aims to maximize vector rx burst for for > > > ixgbe/i40e/ice/iavf PMDs. > > > > > > > Now I'm going to be pedantic and say that it still doesn't conform to > the rte_eth_rx_burst() API, because the API does not specify any > minimum requirement for nb_pkts. > > > > In theory, that could also be fixed in the driver by calling the non- > vector function from the vector functions if nb_pkts is too small for > the vector implementation. > > > > However, I think that calling rte_eth_rx_burst() with a small nb_pkts > is silly and not in the spirit of DPDK, and introducing an additional > comparison for a small nb_pkts in the driver vector functions would > degrade their performance (only slightly, but anyway). > > > > Actually, I'd like to see a confirmed measurement showing a slowdown > before > we discard such an option. :-) Good point! > While I agree that using small bursts is > not > keeping with the design approach of DPDK of using large bursts to > amortize > costs and allow prefetching, there are cases where a user/app may want > a > small burst size, e.g. 4, for latency reasons, and we need a way to > support > that. > I assume that calling rte_eth_rx_burst() with nb_pkts=32 returns 4 packets if only 4 packets are available, so you would need to be extremely latency sensitive to call it with a smaller nb_pkts. I guess that high frequency trading is the only real life scenario here. > Since the path selection is dynamic, we need to either: > a) provide a way for the user to specify that they will use smaller > bursts > and so that vector functions should not be used > b) have the vector functions transparently fallback to the scalar ones > if > used with smaller bursts > > Of these, option b) is simpler, and should be low cost since any check > is > just once per burst, and - assuming an app is written using the same > request-size each time - should be entirely predictable after the first > call. > Why does everyone assume that DPDK applications are so simple that the branch predictor will cover the entire data path? I hear this argument over and over again, and by principle I disagree with it! How about c): add rte_eth_rx() and rte_eth_tx() functions for receiving/transmitting a single packet. The ring library has such functions. Optimized single-packet functions might even perform better than calling the burst functions with nb_pkts=1. Great for latency focused applications. :-) > /Bruce >
Re: [dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements for nb_pkts
On Thu, Aug 27, 2020 at 11:31:15AM +0200, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > Sent: Thursday, August 27, 2020 11:10 AM > > > > On Thu, Aug 27, 2020 at 10:40:11AM +0200, Morten Brørup wrote: > > > Jeff and Ethernet API maintainers Thomas, Ferruh and Andrew, > > > > > > I'm hijacking this patch thread to propose a small API modification > > that prevents unnecessarily performance degradations. > > > > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jeff Guo > > > > Sent: Thursday, August 27, 2020 9:55 AM > > > > > > > > The limitation of burst size in vector rx was removed, since it > > should > > > > retrieve as much received packets as possible. And also the > > scattered > > > > receive path should use a wrapper function to achieve the goal of > > > > burst maximizing. > > > > > > > > This patch set aims to maximize vector rx burst for for > > > > ixgbe/i40e/ice/iavf PMDs. > > > > > > > > > > Now I'm going to be pedantic and say that it still doesn't conform to > > the rte_eth_rx_burst() API, because the API does not specify any > > minimum requirement for nb_pkts. > > > > > > In theory, that could also be fixed in the driver by calling the non- > > vector function from the vector functions if nb_pkts is too small for > > the vector implementation. > > > > > > However, I think that calling rte_eth_rx_burst() with a small nb_pkts > > is silly and not in the spirit of DPDK, and introducing an additional > > comparison for a small nb_pkts in the driver vector functions would > > degrade their performance (only slightly, but anyway). > > > > > > > Actually, I'd like to see a confirmed measurement showing a slowdown > > before > > we discard such an option. :-) > > Good point! > > > While I agree that using small bursts is > > not > > keeping with the design approach of DPDK of using large bursts to > > amortize > > costs and allow prefetching, there are cases where a user/app may want > > a > > small burst size, e.g. 4, for latency reasons, and we need a way to > > support > > that. > > > I assume that calling rte_eth_rx_burst() with nb_pkts=32 returns 4 packets if > only 4 packets are available, so you would need to be extremely latency > sensitive to call it with a smaller nb_pkts. I guess that high frequency > trading is the only real life scenario here. > Yes, it really boils down to whether you are prepared to accept lower max throughput or dropped packets in order to gain lower latency. > > Since the path selection is dynamic, we need to either: > > a) provide a way for the user to specify that they will use smaller > > bursts > > and so that vector functions should not be used > > b) have the vector functions transparently fallback to the scalar ones > > if > > used with smaller bursts > > > > Of these, option b) is simpler, and should be low cost since any check > > is > > just once per burst, and - assuming an app is written using the same > > request-size each time - should be entirely predictable after the first > > call. > > > Why does everyone assume that DPDK applications are so simple that the branch > predictor will cover the entire data path? I hear this argument over and over > again, and by principle I disagree with it! > Fair enough, that was an assumption on my part. Do you see in your apps many cases where branches are getting mispredicted despite going the same way each time though the code? > How about c): add rte_eth_rx() and rte_eth_tx() functions for > receiving/transmitting a single packet. The ring library has such functions. > > Optimized single-packet functions might even perform better than calling the > burst functions with nb_pkts=1. Great for latency focused applications. :-) > That is another option, yes. A further option is to add to the vector code a one-off switch to check first time it's called that the request size is not lower than the min supported (again basing on the assumption that one is not going to be varying the burst size asked - which may not be true in call cases but won't leave us any worse off than we are now!). /Bruce
Re: [dpdk-dev] 19.11.4 patches review and test
On 26-Aug-20 10:50 AM, Luca Boccassi wrote:
On Wed, 2020-08-26 at 02:30 +, Chen, BoX C wrote:
Hi Luca,
Update LTS 19.11.4 test result for Intel part. No new issue is found except
known issues.
Thank you!
* Intel(R) Testing
# Basic Intel(R) NIC testing
* PF(i40e):Passed
- Exception message when starting testpmd for testing external memory. It
has been fixed on 20.05.patch link: http://patches.dpdk.org/patch/66041/
Anatoly, is it safe to backport this patch to 19.11? It applies and
builds cleanly when cherry-picked:
d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
Hi Luca,
Yes, it should be safe - at least i'm not aware of any breakages ever
being reported so far. Thanks!
--
Thanks,
Anatoly
[dpdk-dev] DPDK Release Status Meeting 27/08/2020
Minutes 27 August 2020 -- Agenda: * Release Dates * Subtrees * LTS * OvS * Conferences * Opens Participants: * Arm * Broadcom * Debian/Microsoft * Intel * Marvell * Nvidia * Red Hat Release Dates - * v20.11 dates * Proposal/V1:Friday, 11 September 2020 * -rc1: Friday, 9 October 2020 * -rc2: Friday, 23 October 2020 * Release:Friday, 13 November 2020 * Nvidia Mellanox & Marvell already sent roadmap, all contributors please send roadmap for the release. Subtrees * main * No update * next-net * Doing reviews and merges, nothing critical or urgent at this stage * next-crypto * No update * next-eventdev * There is new DLB driver * next-virtio * No update * next-net-mlx, next-net-intel, next-net-brcm, next-net-mrvl * Nothing in trees yet LTS --- * 18.11.10 * Backporting going on * -rc1 can be on early September * v19.11.4-rc1 is out, please test * http://inbox.dpdk.org/dev/20200818181222.8462-1-bl...@debian.org/T/#u * Canonical, Red Hat & Intel sent test reports. Intel reported a few issues. * Following the Intel reported issues. * Target release date is 31 August. OvS --- * Validating DPDK v19.11.4, will send the report soon * Started building DPDK with meson on Travis * Zero-copy deprecated, it will be gone in 2.15 Conferences --- * DPDK Userspace summit 2020 is on September 22 & 23, schedule is online: https://events.linuxfoundation.org/dpdk-userspace-summit/program/schedule/ Opens - * Can be good to get report on Bugzilla. DPDK Release Status Meetings The DPDK Release Status Meeting is intended for DPDK Committers to discuss the status of the master tree and sub-trees, and for project managers to track progress or milestone dates. The meeting occurs on every Thursdays at 8:30 UTC. on https://meet.jit.si/DPDK If you wish to attend just send an email to "John McNamara " for the invite.
Re: [dpdk-dev] [PATCH v2 00/13] mlx5 PMD multi OS support - part #4
Hi, > -Original Message- > From: Ophir Munk > Sent: Tuesday, August 25, 2020 12:30 PM > To: dev@dpdk.org > Cc: Raslan Darawsheh ; Ophir Munk > ; Matan Azrad ; Ophir > Munk > Subject: [PATCH v2 00/13] mlx5 PMD multi OS support - part #4 > > From: Ophir Munk > > This patch series is part of preparing mlx5 PMD to compile and run under > multiple OSs. Part #4 > > v1: initial version > v2: checkpatch fixes > > Ophir Munk (13): > common/mlx5: replace strsep with strtok_r > common/mlx5: replace Linux __bexx types with rte > net/mlx5: rename mlx5 enumeration REG_NONE > net/mlx5: move mlx5_get_ifname prototype under Linux > net/mlx5: fix removal of unused inclusion files > net/mlx5: remove Netlink dependency in shared code > net/mlx5: fix unused utility macros > net/mlx5: call meter detach only if DR is supported > net/mlx5: add ICMP protocol number definition > net/mlx5: remove more DV dependencies > net/mlx5: remove ibv_* dependency in Rx/Tx objects > net/mlx5: separate VLAN strip modification > linux/mlx5: refactor VLAN > > drivers/common/mlx5/linux/mlx5_common_os.h | 111 > +++ > drivers/common/mlx5/mlx5_common_pci.c | 14 +-- > drivers/common/mlx5/mlx5_prm.h | 16 +-- > drivers/net/mlx5/Makefile | 1 + > drivers/net/mlx5/linux/meson.build | 1 + > drivers/net/mlx5/linux/mlx5_os.c | 18 > drivers/net/mlx5/linux/mlx5_os.h | 6 ++ > drivers/net/mlx5/linux/mlx5_verbs.c| 28 + > drivers/net/mlx5/linux/mlx5_vlan_os.c | 168 > + > drivers/net/mlx5/mlx5.c| 23 ++-- > drivers/net/mlx5/mlx5.h| 30 +++--- > drivers/net/mlx5/mlx5_devx.c | 48 + > drivers/net/mlx5/mlx5_devx.h | 12 +++ > drivers/net/mlx5/mlx5_flow.c | 29 +++-- > drivers/net/mlx5/mlx5_flow_dv.c| 8 +- > drivers/net/mlx5/mlx5_flow_meter.c | 4 + > drivers/net/mlx5/mlx5_mac.c| 2 - > drivers/net/mlx5/mlx5_rxq.c| 18 ++-- > drivers/net/mlx5/mlx5_rxtx.h | 24 ++--- > drivers/net/mlx5/mlx5_trigger.c| 3 +- > drivers/net/mlx5/mlx5_txpp.c | 38 --- > drivers/net/mlx5/mlx5_txq.c| 19 ++-- > drivers/net/mlx5/mlx5_utils.h | 4 - > drivers/net/mlx5/mlx5_vlan.c | 161 +-- > 24 files changed, 527 insertions(+), 259 deletions(-) > create mode 100644 drivers/net/mlx5/linux/mlx5_vlan_os.c > create mode 100644 drivers/net/mlx5/mlx5_devx.c > create mode 100644 drivers/net/mlx5/mlx5_devx.h > > -- > 2.8.4 Series applied to next-net-mlx, Kindest regards, Raslan Darawsheh
[dpdk-dev] [PATCH v2 2/5] net/i40e: maximize vector rx burst for i40e
The limitation of burst size in vector rx was removed, since it should
retrieve as much received packets as possible. And also the scattered
receive path should use a wrapper function to achieve the goal of
burst maximizing.
Signed-off-by: Jeff Guo
---
drivers/net/i40e/i40e_rxtx_vec_altivec.c | 61 +++-
drivers/net/i40e/i40e_rxtx_vec_avx2.c| 13 +
drivers/net/i40e/i40e_rxtx_vec_neon.c| 55 +
drivers/net/i40e/i40e_rxtx_vec_sse.c | 55 +
4 files changed, 111 insertions(+), 73 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
index 6862a017e..2eb45d5a5 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
@@ -188,11 +188,13 @@ desc_to_ptype_v(vector unsigned long descs[4], struct
rte_mbuf **rx_pkts,
ptype_tbl[(*(vector unsigned char *)&ptype1)[8]];
}
- /* Notice:
- * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_I40E_VPMD_RX_BURST, only scan RTE_I40E_VPMD_RX_BURST
- * numbers of DD bits
- */
+/**
+ * vPMD raw receive routine, only accept(nb_pkts >= RTE_I40E_DESCS_PER_LOOP)
+ *
+ * Notice:
+ * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
+ * - floor align nb_pkts to a RTE_I40E_DESCS_PER_LOOP power-of-two
+ */
static inline uint16_t
_recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts, uint8_t *split_packet)
@@ -214,9 +216,6 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
};
vector unsigned long dd_check, eop_check;
- /* nb_pkts shall be less equal than RTE_I40E_MAX_RX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, RTE_I40E_MAX_RX_BURST);
-
/* nb_pkts has to be floor-aligned to RTE_I40E_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP);
@@ -447,11 +446,6 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
return nb_pkts_recd;
}
- /* Notice:
- * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_I40E_VPMD_RX_BURST, only scan RTE_I40E_VPMD_RX_BURST
- * numbers of DD bits
- */
uint16_t
i40e_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
@@ -459,15 +453,12 @@ i40e_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
return _recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);
}
- /* vPMD receive routine that reassembles scattered packets
- * Notice:
- * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_I40E_VPMD_RX_BURST, only scan RTE_I40E_VPMD_RX_BURST
- * numbers of DD bits
- */
-uint16_t
-i40e_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
-uint16_t nb_pkts)
+/**
+ * vPMD receive routine that reassembles scattered packets
+ */
+static uint16_t
+i40e_recv_scattered_burst_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
{
struct i40e_rx_queue *rxq = rx_queue;
uint8_t split_flags[RTE_I40E_VPMD_RX_BURST] = {0};
@@ -500,6 +491,32 @@ i40e_recv_scattered_pkts_vec(void *rx_queue, struct
rte_mbuf **rx_pkts,
&split_flags[i]);
}
+/**
+ * vPMD receive routine that reassembles scattered packets.
+ */
+uint16_t
+i40e_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+uint16_t nb_pkts)
+{
+ uint16_t retval = 0;
+
+ while (nb_pkts > RTE_I40E_VPMD_RX_BURST) {
+ uint16_t burst;
+
+ burst = i40e_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ RTE_I40E_VPMD_RX_BURST);
+ retval += burst;
+ nb_pkts -= burst;
+ if (burst < RTE_I40E_VPMD_RX_BURST)
+ return retval;
+ }
+
+ return retval + i40e_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ nb_pkts);
+}
+
static inline void
vtx1(volatile struct i40e_tx_desc *txdp,
struct rte_mbuf *pkt, uint64_t flags)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_avx2.c
b/drivers/net/i40e/i40e_rxtx_vec_avx2.c
index 3bcef1363..690d3d2ba 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_avx2.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_avx2.c
@@ -729,10 +729,6 @@ _recv_raw_pkts_vec_avx2(struct i40e_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
return received;
}
-/*
- * Notice:
- * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
- */
uint16_t
i40e_recv_pkts_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
@@ -740,10 +736,8 @@ i40e_recv_pkts_vec_avx2(void *r
[dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs
The limitation of burst size in vector rx was removed, since it should retrieve as much received packets as possible. And also the scattered receive path should use a wrapper function to achieve the goal of burst maximizing. This patch set aims to maximize vector rx burst for for ixgbe/i40e/ice/iavf/fm10k PMDs. v2->v1: 1:add fm10k driver case 2:refine some doc Jeff Guo (5): net/ixgbe: maximize vector rx burst for ixgbe net/i40e: maximize vector rx burst for i40e net/ice: maximize vector rx burst for ice net/iavf: maximize vector rx burst for iavf net/fm10k: maximize vector rx burst for fm10k drivers/net/fm10k/fm10k_rxtx_vec.c | 39 +++-- drivers/net/i40e/i40e_rxtx_vec_altivec.c | 61 - drivers/net/i40e/i40e_rxtx_vec_avx2.c| 13 +-- drivers/net/i40e/i40e_rxtx_vec_neon.c| 55 +++- drivers/net/i40e/i40e_rxtx_vec_sse.c | 55 +++- drivers/net/iavf/iavf_rxtx_vec_avx2.c| 21 + drivers/net/iavf/iavf_rxtx_vec_sse.c | 107 ++- drivers/net/ice/ice_rxtx_vec_avx2.c | 11 +-- drivers/net/ice/ice_rxtx_vec_sse.c | 49 +++ drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 72 +++ drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 56 ++-- 11 files changed, 312 insertions(+), 227 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v2 5/5] net/fm10k: maximize vector rx burst for fm10k
The limitation of burst size in vector rx was removed, since it should
retrieve as much received packets as possible. And also the scattered
receive path should use a wrapper function to achieve the goal of
burst maximizing.
Signed-off-by: Jeff Guo
---
drivers/net/fm10k/fm10k_rxtx_vec.c | 39 +++---
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index eff3933b5..8d413b542 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -645,25 +645,20 @@ fm10k_reassemble_packets(struct fm10k_rx_queue *rxq,
return pkt_idx;
}
-/*
+/**
* vPMD receive routine that reassembles scattered packets
*
* Notice:
* - don't support ol_flags for rss and csum err
- * - nb_pkts > RTE_FM10K_MAX_RX_BURST, only scan RTE_FM10K_MAX_RX_BURST
- * numbers of DD bit
*/
-uint16_t
-fm10k_recv_scattered_pkts_vec(void *rx_queue,
- struct rte_mbuf **rx_pkts,
- uint16_t nb_pkts)
+static uint16_t
+fm10k_recv_scattered_burst_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
{
struct fm10k_rx_queue *rxq = rx_queue;
uint8_t split_flags[RTE_FM10K_MAX_RX_BURST] = {0};
unsigned i = 0;
- /* Split_flags only can support max of RTE_FM10K_MAX_RX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, RTE_FM10K_MAX_RX_BURST);
/* get some new buffers */
uint16_t nb_bufs = fm10k_recv_raw_pkts_vec(rxq, rx_pkts, nb_pkts,
split_flags);
@@ -691,6 +686,32 @@ fm10k_recv_scattered_pkts_vec(void *rx_queue,
&split_flags[i]);
}
+/**
+ * vPMD receive routine that reassembles scattered packets.
+ */
+uint16_t
+fm10k_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
+{
+ uint16_t retval = 0;
+
+ while (nb_pkts > RTE_FM10K_MAX_RX_BURST) {
+ uint16_t burst;
+
+ burst = fm10k_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ RTE_FM10K_MAX_RX_BURST);
+ retval += burst;
+ nb_pkts -= burst;
+ if (burst < RTE_FM10K_MAX_RX_BURST)
+ return retval;
+ }
+
+ return retval + fm10k_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ nb_pkts);
+}
+
static const struct fm10k_txq_ops vec_txq_ops = {
.reset = fm10k_reset_tx_queue,
};
--
2.20.1
[dpdk-dev] [PATCH v2 3/5] net/ice: maximize vector rx burst for ice
The limitation of burst size in vector rx was removed, since it should
retrieve as much received packets as possible. And also the scattered
receive path should use a wrapper function to achieve the goal of
burst maximizing.
Signed-off-by: Jeff Guo
---
drivers/net/ice/ice_rxtx_vec_avx2.c | 11 +--
drivers/net/ice/ice_rxtx_vec_sse.c | 49 -
2 files changed, 35 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ice/ice_rxtx_vec_avx2.c
b/drivers/net/ice/ice_rxtx_vec_avx2.c
index be50677c2..b7e624fda 100644
--- a/drivers/net/ice/ice_rxtx_vec_avx2.c
+++ b/drivers/net/ice/ice_rxtx_vec_avx2.c
@@ -603,10 +603,6 @@ _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue *rxq,
struct rte_mbuf **rx_pkts,
return received;
}
-/**
- * Notice:
- * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
- */
uint16_t
ice_recv_pkts_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
@@ -615,9 +611,7 @@ ice_recv_pkts_vec_avx2(void *rx_queue, struct rte_mbuf
**rx_pkts,
}
/**
- * vPMD receive routine that reassembles single burst of 32 scattered packets
- * Notice:
- * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
+ * vPMD receive routine that reassembles scattered packets
*/
static uint16_t
ice_recv_scattered_burst_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts,
@@ -657,9 +651,6 @@ ice_recv_scattered_burst_vec_avx2(void *rx_queue, struct
rte_mbuf **rx_pkts,
/**
* vPMD receive routine that reassembles scattered packets.
- * Main receive routine that can handle arbitrary burst sizes
- * Notice:
- * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
*/
uint16_t
ice_recv_scattered_pkts_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts,
diff --git a/drivers/net/ice/ice_rxtx_vec_sse.c
b/drivers/net/ice/ice_rxtx_vec_sse.c
index 382ef31f3..25ae368cc 100644
--- a/drivers/net/ice/ice_rxtx_vec_sse.c
+++ b/drivers/net/ice/ice_rxtx_vec_sse.c
@@ -205,10 +205,11 @@ ice_rx_desc_to_ptype_v(__m128i descs[4], struct rte_mbuf
**rx_pkts,
}
/**
+ * vPMD raw receive routine, only accept(nb_pkts >= ICE_DESCS_PER_LOOP)
+ *
* Notice:
* - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > ICE_VPMD_RX_BURST, only scan ICE_VPMD_RX_BURST
- * numbers of DD bits
+ * - floor align nb_pkts to a ICE_DESCS_PER_LOOP power-of-two
*/
static inline uint16_t
_ice_recv_raw_pkts_vec(struct ice_rx_queue *rxq, struct rte_mbuf **rx_pkts,
@@ -264,9 +265,6 @@ _ice_recv_raw_pkts_vec(struct ice_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
const __m128i eop_check = _mm_set_epi64x(0x00020002LL,
0x00020002LL);
- /* nb_pkts shall be less equal than ICE_MAX_RX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, ICE_MAX_RX_BURST);
-
/* nb_pkts has to be floor-aligned to ICE_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, ICE_DESCS_PER_LOOP);
@@ -444,8 +442,6 @@ _ice_recv_raw_pkts_vec(struct ice_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
/**
* Notice:
* - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > ICE_VPMD_RX_BURST, only scan ICE_VPMD_RX_BURST
- * numbers of DD bits
*/
uint16_t
ice_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
@@ -454,15 +450,12 @@ ice_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
return _ice_recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);
}
-/* vPMD receive routine that reassembles scattered packets
- * Notice:
- * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > ICE_VPMD_RX_BURST, only scan ICE_VPMD_RX_BURST
- * numbers of DD bits
+/**
+ * vPMD receive routine that reassembles scattered packets
*/
-uint16_t
-ice_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
- uint16_t nb_pkts)
+static uint16_t
+ice_recv_scattered_burst_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+uint16_t nb_pkts)
{
struct ice_rx_queue *rxq = rx_queue;
uint8_t split_flags[ICE_VPMD_RX_BURST] = {0};
@@ -496,6 +489,32 @@ ice_recv_scattered_pkts_vec(void *rx_queue, struct
rte_mbuf **rx_pkts,
&split_flags[i]);
}
+/**
+ * vPMD receive routine that reassembles scattered packets.
+ */
+uint16_t
+ice_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
+{
+ uint16_t retval = 0;
+
+ while (nb_pkts > ICE_VPMD_RX_BURST) {
+ uint16_t burst;
+
+ burst = ice_recv_scattered_burst_vec(rx_queue,
+rx_pkts + retval,
+ICE_VPMD_RX_BURST);
+ retval += burst;
+ nb_pkts -= burst;
+ if (burst < ICE_VPMD_RX_BURST)
+ return retval;
+ }
+
+ return retval + ice_recv
[dpdk-dev] [PATCH v2 4/5] net/iavf: maximize vector rx burst for iavf
The limitation of burst size in vector rx was removed, since it should retrieve as much received packets as possible. And also the scattered receive path should use a wrapper function to achieve the goal of burst maximizing. Signed-off-by: Jeff Guo --- drivers/net/iavf/iavf_rxtx_vec_avx2.c | 21 + drivers/net/iavf/iavf_rxtx_vec_sse.c | 107 -- 2 files changed, 68 insertions(+), 60 deletions(-) diff --git a/drivers/net/iavf/iavf_rxtx_vec_avx2.c b/drivers/net/iavf/iavf_rxtx_vec_avx2.c index e5e0fd309..35166d4c6 100644 --- a/drivers/net/iavf/iavf_rxtx_vec_avx2.c +++ b/drivers/net/iavf/iavf_rxtx_vec_avx2.c @@ -1224,10 +1224,6 @@ _iavf_recv_raw_pkts_vec_avx2_flex_rxd(struct iavf_rx_queue *rxq, return received; } -/** - * Notice: - * - nb_pkts < IAVF_DESCS_PER_LOOP, just return no packet - */ uint16_t iavf_recv_pkts_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts) @@ -1235,10 +1231,6 @@ iavf_recv_pkts_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts, return _iavf_recv_raw_pkts_vec_avx2(rx_queue, rx_pkts, nb_pkts, NULL); } -/** - * Notice: - * - nb_pkts < IAVF_DESCS_PER_LOOP, just return no packet - */ uint16_t iavf_recv_pkts_vec_avx2_flex_rxd(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts) @@ -1249,8 +1241,6 @@ iavf_recv_pkts_vec_avx2_flex_rxd(void *rx_queue, struct rte_mbuf **rx_pkts, /** * vPMD receive routine that reassembles single burst of 32 scattered packets - * Notice: - * - nb_pkts < IAVF_DESCS_PER_LOOP, just return no packet */ static uint16_t iavf_recv_scattered_burst_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts, @@ -1290,9 +1280,6 @@ iavf_recv_scattered_burst_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts, /** * vPMD receive routine that reassembles scattered packets. - * Main receive routine that can handle arbitrary burst sizes - * Notice: - * - nb_pkts < IAVF_DESCS_PER_LOOP, just return no packet */ uint16_t iavf_recv_scattered_pkts_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts, @@ -1313,10 +1300,7 @@ iavf_recv_scattered_pkts_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts, } /** - * vPMD receive routine that reassembles single burst of - * 32 scattered packets for flex RxD - * Notice: - * - nb_pkts < IAVF_DESCS_PER_LOOP, just return no packet + * vPMD receive routine that reassembles scattered packets for flex RxD */ static uint16_t iavf_recv_scattered_burst_vec_avx2_flex_rxd(void *rx_queue, @@ -1357,9 +1341,6 @@ iavf_recv_scattered_burst_vec_avx2_flex_rxd(void *rx_queue, /** * vPMD receive routine that reassembles scattered packets for flex RxD. - * Main receive routine that can handle arbitrary burst sizes - * Notice: - * - nb_pkts < IAVF_DESCS_PER_LOOP, just return no packet */ uint16_t iavf_recv_scattered_pkts_vec_avx2_flex_rxd(void *rx_queue, diff --git a/drivers/net/iavf/iavf_rxtx_vec_sse.c b/drivers/net/iavf/iavf_rxtx_vec_sse.c index 85c5bd4af..a78a741dd 100644 --- a/drivers/net/iavf/iavf_rxtx_vec_sse.c +++ b/drivers/net/iavf/iavf_rxtx_vec_sse.c @@ -379,10 +379,12 @@ flex_desc_to_ptype_v(__m128i descs[4], struct rte_mbuf **rx_pkts, rx_pkts[3]->packet_type = type_table[_mm_extract_epi16(ptype_all, 7)]; } -/* Notice: +/** + * vPMD raw receive routine, only accept(nb_pkts >= IAVF_VPMD_DESCS_PER_LOOP) + * + * Notice: * - nb_pkts < IAVF_VPMD_DESCS_PER_LOOP, just return no packet - * - nb_pkts > IAVF_VPMD_RX_MAX_BURST, only scan IAVF_VPMD_RX_MAX_BURST - * numbers of DD bits + * - floor align nb_pkts to a IAVF_VPMD_DESCS_PER_LOOP power-of-two */ static inline uint16_t _recv_raw_pkts_vec(struct iavf_rx_queue *rxq, struct rte_mbuf **rx_pkts, @@ -413,9 +415,6 @@ _recv_raw_pkts_vec(struct iavf_rx_queue *rxq, struct rte_mbuf **rx_pkts, offsetof(struct rte_mbuf, rx_descriptor_fields1) + 8); __m128i dd_check, eop_check; - /* nb_pkts shall be less equal than IAVF_VPMD_RX_MAX_BURST */ - nb_pkts = RTE_MIN(nb_pkts, IAVF_VPMD_RX_MAX_BURST); - /* nb_pkts has to be floor-aligned to IAVF_VPMD_DESCS_PER_LOOP */ nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, IAVF_VPMD_DESCS_PER_LOOP); @@ -627,11 +626,6 @@ _recv_raw_pkts_vec(struct iavf_rx_queue *rxq, struct rte_mbuf **rx_pkts, return nb_pkts_recd; } -/* Notice: - * - nb_pkts < IAVF_VPMD_DESCS_PER_LOOP, just return no packet - * - nb_pkts > IAVF_VPMD_RX_MAX_BURST, only scan IAVF_VPMD_RX_MAX_BURST - * numbers of DD bits - */ static inline uint16_t _recv_raw_pkts_vec_flex_rxd(struct iavf_rx_queue *rxq, struct rte_mbuf **rx_pkts, @@ -688,9 +682,6 @@ _recv_raw_pkts_vec_flex_rxd(struct iavf_rx_queue *rxq, const __m128i eop_check = _mm_set_epi64x(0x00020002LL, 0x00020002LL); - /* nb_pkts shall be less equal than IAVF_VPMD_RX_MAX_BURST */ - nb_pkts = RTE_MIN(nb
[dpdk-dev] [PATCH v2 1/5] net/ixgbe: maximize vector rx burst for ixgbe
The limitation of burst size in vector rx was removed, since it should
retrieve as much received packets as possible. And also the scattered
receive path should use a wrapper function to achieve the goal of
burst maximizing.
Signed-off-by: Jeff Guo
---
drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 72 +
drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 56 ++-
2 files changed, 68 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
index aa27ee177..580a5ed12 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
@@ -130,17 +130,6 @@ desc_to_olflags_v(uint8x16x2_t sterr_tmp1, uint8x16x2_t
sterr_tmp2,
rx_pkts[3]->ol_flags = vol.e[3];
}
-/*
- * vPMD raw receive routine, only accept(nb_pkts >= RTE_IXGBE_DESCS_PER_LOOP)
- *
- * Notice:
- * - nb_pkts < RTE_IXGBE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_IXGBE_MAX_RX_BURST, only scan RTE_IXGBE_MAX_RX_BURST
- * numbers of DD bit
- * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
- * - don't support ol_flags for rss and csum err
- */
-
#define IXGBE_VPMD_DESC_EOP_MASK 0x02020202
#define IXGBE_UINT8_BIT(CHAR_BIT * sizeof(uint8_t))
@@ -206,6 +195,13 @@ desc_to_ptype_v(uint64x2_t descs[4], uint16_t
pkt_type_mask,
vgetq_lane_u32(tunnel_check, 3));
}
+/**
+ * vPMD raw receive routine, only accept(nb_pkts >= RTE_IXGBE_DESCS_PER_LOOP)
+ *
+ * Notice:
+ * - nb_pkts < RTE_IXGBE_DESCS_PER_LOOP, just return no packet
+ * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
+ */
static inline uint16_t
_recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts, uint8_t *split_packet)
@@ -226,9 +222,6 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
uint16x8_t crc_adjust = {0, 0, rxq->crc_len, 0,
rxq->crc_len, 0, 0, 0};
- /* nb_pkts shall be less equal than RTE_IXGBE_MAX_RX_BURST */
- nb_pkts = RTE_MIN(nb_pkts, RTE_IXGBE_MAX_RX_BURST);
-
/* nb_pkts has to be floor-aligned to RTE_IXGBE_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_IXGBE_DESCS_PER_LOOP);
@@ -382,16 +375,6 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
return nb_pkts_recd;
}
-/*
- * vPMD receive routine, only accept(nb_pkts >= RTE_IXGBE_DESCS_PER_LOOP)
- *
- * Notice:
- * - nb_pkts < RTE_IXGBE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_IXGBE_MAX_RX_BURST, only scan RTE_IXGBE_MAX_RX_BURST
- * numbers of DD bit
- * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
- * - don't support ol_flags for rss and csum err
- */
uint16_t
ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
@@ -399,19 +382,12 @@ ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
return _recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);
}
-/*
+/**
* vPMD receive routine that reassembles scattered packets
- *
- * Notice:
- * - don't support ol_flags for rss and csum err
- * - nb_pkts < RTE_IXGBE_DESCS_PER_LOOP, just return no packet
- * - nb_pkts > RTE_IXGBE_MAX_RX_BURST, only scan RTE_IXGBE_MAX_RX_BURST
- * numbers of DD bit
- * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
*/
-uint16_t
-ixgbe_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
- uint16_t nb_pkts)
+static uint16_t
+ixgbe_recv_scattered_burst_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
{
struct ixgbe_rx_queue *rxq = rx_queue;
uint8_t split_flags[RTE_IXGBE_MAX_RX_BURST] = {0};
@@ -443,6 +419,32 @@ ixgbe_recv_scattered_pkts_vec(void *rx_queue, struct
rte_mbuf **rx_pkts,
&split_flags[i]);
}
+/**
+ * vPMD receive routine that reassembles scattered packets.
+ */
+uint16_t
+ixgbe_recv_scattered_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
+{
+ uint16_t retval = 0;
+
+ while (nb_pkts > RTE_IXGBE_MAX_RX_BURST) {
+ uint16_t burst;
+
+ burst = ixgbe_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ RTE_IXGBE_MAX_RX_BURST);
+ retval += burst;
+ nb_pkts -= burst;
+ if (burst < RTE_IXGBE_MAX_RX_BURST)
+ return retval;
+ }
+
+ return retval + ixgbe_recv_scattered_burst_vec(rx_queue,
+ rx_pkts + retval,
+ nb_pkts);
+}
+
static inline void
vtx1(volatile union ixgbe_adv_tx_desc *txdp,
Re: [dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements fornb_pkts
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson > Sent: Thursday, August 27, 2020 11:44 AM > > On Thu, Aug 27, 2020 at 11:31:15AM +0200, Morten Brørup wrote: > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > > Sent: Thursday, August 27, 2020 11:10 AM > > > > > > On Thu, Aug 27, 2020 at 10:40:11AM +0200, Morten Brørup wrote: > > > > Jeff and Ethernet API maintainers Thomas, Ferruh and Andrew, > > > > > > > > I'm hijacking this patch thread to propose a small API > modification > > > that prevents unnecessarily performance degradations. > > > > > > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jeff Guo > > > > > Sent: Thursday, August 27, 2020 9:55 AM > > > > > > > > > > The limitation of burst size in vector rx was removed, since it > > > should > > > > > retrieve as much received packets as possible. And also the > > > scattered > > > > > receive path should use a wrapper function to achieve the goal > of > > > > > burst maximizing. > > > > > > > > > > This patch set aims to maximize vector rx burst for for > > > > > ixgbe/i40e/ice/iavf PMDs. > > > > > > > > > > > > > Now I'm going to be pedantic and say that it still doesn't > conform to > > > the rte_eth_rx_burst() API, because the API does not specify any > > > minimum requirement for nb_pkts. > > > > > > > > In theory, that could also be fixed in the driver by calling the > non- > > > vector function from the vector functions if nb_pkts is too small > for > > > the vector implementation. > > > > > > > > However, I think that calling rte_eth_rx_burst() with a small > nb_pkts > > > is silly and not in the spirit of DPDK, and introducing an > additional > > > comparison for a small nb_pkts in the driver vector functions would > > > degrade their performance (only slightly, but anyway). > > > > > > > > > > Actually, I'd like to see a confirmed measurement showing a > slowdown > > > before > > > we discard such an option. :-) > > > > Good point! > > > > > While I agree that using small bursts is > > > not > > > keeping with the design approach of DPDK of using large bursts to > > > amortize > > > costs and allow prefetching, there are cases where a user/app may > want > > > a > > > small burst size, e.g. 4, for latency reasons, and we need a way to > > > support > > > that. > > > > > I assume that calling rte_eth_rx_burst() with nb_pkts=32 returns 4 > packets if only 4 packets are available, so you would need to be > extremely latency sensitive to call it with a smaller nb_pkts. I guess > that high frequency trading is the only real life scenario here. > > > Yes, it really boils down to whether you are prepared to accept lower > max throughput or dropped packets in order to gain lower latency. > > > > Since the path selection is dynamic, we need to either: > > > a) provide a way for the user to specify that they will use smaller > > > bursts > > > and so that vector functions should not be used > > > b) have the vector functions transparently fallback to the scalar > ones > > > if > > > used with smaller bursts > > > > > > Of these, option b) is simpler, and should be low cost since any > check > > > is > > > just once per burst, and - assuming an app is written using the > same > > > request-size each time - should be entirely predictable after the > first > > > call. > > > > > Why does everyone assume that DPDK applications are so simple that > the branch predictor will cover the entire data path? I hear this > argument over and over again, and by principle I disagree with it! > > > > Fair enough, that was an assumption on my part. Do you see in your apps > many cases where branches are getting mispredicted despite going the > same > way each time though the code? > We haven't looked deeply into this, but I don't think so. My objection is of a more general nature. As a library, DPDK cannot assume that applications using it are simple, and - based on that assumption - take away resources that could have been available for the application. The Intel general optimization guidelines specifies that code should be arranged to be consistent with the static branch prediction algorithm: make the fall-through code following a conditional branch be the likely target for a branch with a forward target, and make the fall-through code following a conditional branch be the unlikely target for a branch with a backward target. It also says: Conditional branches that are never taken do not consume BTB resources. Somehow this last detail is completely ignored by DPDK developers. We put a lot of effort into conserving resources in most areas in DPDK, but when it comes to the branch prediction target buffer (BTB), we gladly organize code with branches turning the wrong way, thus unnecessarily consuming BTB entries. And the argument goes: The branch predictor will catch it after the first time. > > How about c): add rte_eth_rx() and rte_eth_tx() functions for > receiving/transmitting a single packet.
Re: [dpdk-dev] 19.11.4 patches review and test
On Thu, 2020-08-27 at 10:47 +0100, Burakov, Anatoly wrote:
> On 26-Aug-20 10:50 AM, Luca Boccassi wrote:
> > On Wed, 2020-08-26 at 02:30 +, Chen, BoX C wrote:
> > > Hi Luca,
> > > Update LTS 19.11.4 test result for Intel part. No new issue is found
> > > except known issues.
> >
> > Thank you!
> >
> > > * Intel(R) Testing
> > >
> > > # Basic Intel(R) NIC testing
> > > * PF(i40e):Passed
> > > - Exception message when starting testpmd for testing external
> > > memory. It has been fixed on 20.05.patch link:
> > > http://patches.dpdk.org/patch/66041/
> >
> > Anatoly, is it safe to backport this patch to 19.11? It applies and
> > builds cleanly when cherry-picked:
> >
> > d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
>
> Hi Luca,
>
> Yes, it should be safe - at least i'm not aware of any breakages ever
> being reported so far. Thanks!
Could you please double-check that there's no other patch/change that
depends on it/that it depends on and is missing from 19.11.4-rc1? Given
we wouldn't redo the full regression run, we need to be careful
--
Kind regards,
Luca Boccassi
Re: [dpdk-dev] 19.11.4 patches review and test
On 27-Aug-20 11:37 AM, Luca Boccassi wrote:
On Thu, 2020-08-27 at 10:47 +0100, Burakov, Anatoly wrote:
On 26-Aug-20 10:50 AM, Luca Boccassi wrote:
On Wed, 2020-08-26 at 02:30 +, Chen, BoX C wrote:
Hi Luca,
Update LTS 19.11.4 test result for Intel part. No new issue is found except
known issues.
Thank you!
* Intel(R) Testing
# Basic Intel(R) NIC testing
* PF(i40e):Passed
- Exception message when starting testpmd for testing external memory. It
has been fixed on 20.05.patch link: http://patches.dpdk.org/patch/66041/
Anatoly, is it safe to backport this patch to 19.11? It applies and
builds cleanly when cherry-picked:
d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
Hi Luca,
Yes, it should be safe - at least i'm not aware of any breakages ever
being reported so far. Thanks!
Could you please double-check that there's no other patch/change that
depends on it/that it depends on and is missing from 19.11.4-rc1? Given
we wouldn't redo the full regression run, we need to be careful
I'm positive that it's self-contained. It's just a different way of
iterating through an array :)
--
Thanks,
Anatoly
[dpdk-dev] Remove from list
Hello, Have not been working with dpdk in a while. Could you please remove from the mailing list. Thanks JAck
[dpdk-dev] [PATCH] net/octeontx2: move ESP parsing to LE layer
From: Kiran Kumar K
Add support to parse NAT-T-ESP by moving the ESP parsing
to LE.
Signed-off-by: Kiran Kumar K
---
drivers/common/octeontx2/hw/otx2_npc.h | 2 +-
drivers/net/octeontx2/otx2_flow_parse.c | 10 +-
drivers/net/octeontx2/otx2_lookup.c | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/common/octeontx2/hw/otx2_npc.h
b/drivers/common/octeontx2/hw/otx2_npc.h
index efde1e214..45e60dfd5 100644
--- a/drivers/common/octeontx2/hw/otx2_npc.h
+++ b/drivers/common/octeontx2/hw/otx2_npc.h
@@ -225,7 +225,6 @@ enum npc_kpu_ld_ltype {
NPC_LT_LD_SCTP,
NPC_LT_LD_ICMP6,
NPC_LT_LD_IGMP = 8,
- NPC_LT_LD_ESP,
NPC_LT_LD_AH,
NPC_LT_LD_GRE,
NPC_LT_LD_NVGRE,
@@ -237,6 +236,7 @@ enum npc_kpu_ld_ltype {
enum npc_kpu_le_ltype {
NPC_LT_LE_VXLAN = 1,
NPC_LT_LE_GENEVE,
+ NPC_LT_LE_ESP,
NPC_LT_LE_GTPU = 4,
NPC_LT_LE_VXLANGPE,
NPC_LT_LE_GTPC,
diff --git a/drivers/net/octeontx2/otx2_flow_parse.c
b/drivers/net/octeontx2/otx2_flow_parse.c
index 2d9a5857c..e918574df 100644
--- a/drivers/net/octeontx2/otx2_flow_parse.c
+++ b/drivers/net/octeontx2/otx2_flow_parse.c
@@ -245,6 +245,11 @@ otx2_flow_parse_le(struct otx2_parse_state *pst)
info.len = sizeof(struct rte_flow_item_vxlan);
lt = NPC_LT_LE_VXLAN;
break;
+ case RTE_FLOW_ITEM_TYPE_ESP:
+ lt = NPC_LT_LE_ESP;
+ info.def_mask = &rte_flow_item_esp_mask;
+ info.len = sizeof(struct rte_flow_item_esp);
+ break;
case RTE_FLOW_ITEM_TYPE_GTPC:
lflags = NPC_F_UDP_GTP_GTPC;
info.def_mask = &rte_flow_item_gtp_mask;
@@ -441,11 +446,6 @@ otx2_flow_parse_ld(struct otx2_parse_state *pst)
info.def_mask = &rte_flow_item_sctp_mask;
info.len = sizeof(struct rte_flow_item_sctp);
break;
- case RTE_FLOW_ITEM_TYPE_ESP:
- lt = NPC_LT_LD_ESP;
- info.def_mask = &rte_flow_item_esp_mask;
- info.len = sizeof(struct rte_flow_item_esp);
- break;
case RTE_FLOW_ITEM_TYPE_GRE:
lt = NPC_LT_LD_GRE;
info.def_mask = &rte_flow_item_gre_mask;
diff --git a/drivers/net/octeontx2/otx2_lookup.c
b/drivers/net/octeontx2/otx2_lookup.c
index 10944bc17..14ea1cf79 100644
--- a/drivers/net/octeontx2/otx2_lookup.c
+++ b/drivers/net/octeontx2/otx2_lookup.c
@@ -169,15 +169,15 @@ nix_create_non_tunnel_ptype_array(uint16_t *ptype)
case NPC_LT_LD_NVGRE:
val |= RTE_PTYPE_TUNNEL_NVGRE;
break;
- case NPC_LT_LD_ESP:
- val |= RTE_PTYPE_TUNNEL_ESP;
- break;
}
switch (le) {
case NPC_LT_LE_VXLAN:
val |= RTE_PTYPE_TUNNEL_VXLAN;
break;
+ case NPC_LT_LE_ESP:
+ val |= RTE_PTYPE_TUNNEL_ESP;
+ break;
case NPC_LT_LE_VXLANGPE:
val |= RTE_PTYPE_TUNNEL_VXLAN_GPE;
break;
--
2.25.1
Re: [dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements fornb_pkts
On Thu, Aug 27, 2020 at 12:13:51PM +0200, Morten Brørup wrote: > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson > > Sent: Thursday, August 27, 2020 11:44 AM > > > > On Thu, Aug 27, 2020 at 11:31:15AM +0200, Morten Brørup wrote: > > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > > > Sent: Thursday, August 27, 2020 11:10 AM > > > > > > > > On Thu, Aug 27, 2020 at 10:40:11AM +0200, Morten Brørup wrote: > > > > > Jeff and Ethernet API maintainers Thomas, Ferruh and Andrew, > > > > > > > > > > I'm hijacking this patch thread to propose a small API > > modification > > > > that prevents unnecessarily performance degradations. > > > > > > > > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jeff Guo > > > > > > Sent: Thursday, August 27, 2020 9:55 AM > > > > > > > > > > > > The limitation of burst size in vector rx was removed, since it > > > > should > > > > > > retrieve as much received packets as possible. And also the > > > > scattered > > > > > > receive path should use a wrapper function to achieve the goal > > of > > > > > > burst maximizing. > > > > > > > > > > > > This patch set aims to maximize vector rx burst for for > > > > > > ixgbe/i40e/ice/iavf PMDs. > > > > > > > > > > > > > > > > Now I'm going to be pedantic and say that it still doesn't > > conform to > > > > the rte_eth_rx_burst() API, because the API does not specify any > > > > minimum requirement for nb_pkts. > > > > > > > > > > In theory, that could also be fixed in the driver by calling the > > non- > > > > vector function from the vector functions if nb_pkts is too small > > for > > > > the vector implementation. > > > > > > > > > > However, I think that calling rte_eth_rx_burst() with a small > > nb_pkts > > > > is silly and not in the spirit of DPDK, and introducing an > > additional > > > > comparison for a small nb_pkts in the driver vector functions would > > > > degrade their performance (only slightly, but anyway). > > > > > > > > > > > > > Actually, I'd like to see a confirmed measurement showing a > > slowdown > > > > before > > > > we discard such an option. :-) > > > > > > Good point! > > > > > > > While I agree that using small bursts is > > > > not > > > > keeping with the design approach of DPDK of using large bursts to > > > > amortize > > > > costs and allow prefetching, there are cases where a user/app may > > want > > > > a > > > > small burst size, e.g. 4, for latency reasons, and we need a way to > > > > support > > > > that. > > > > > > > I assume that calling rte_eth_rx_burst() with nb_pkts=32 returns 4 > > packets if only 4 packets are available, so you would need to be > > extremely latency sensitive to call it with a smaller nb_pkts. I guess > > that high frequency trading is the only real life scenario here. > > > > > Yes, it really boils down to whether you are prepared to accept lower > > max throughput or dropped packets in order to gain lower latency. > > > > > > Since the path selection is dynamic, we need to either: > > > > a) provide a way for the user to specify that they will use smaller > > > > bursts > > > > and so that vector functions should not be used > > > > b) have the vector functions transparently fallback to the scalar > > ones > > > > if > > > > used with smaller bursts > > > > > > > > Of these, option b) is simpler, and should be low cost since any > > check > > > > is > > > > just once per burst, and - assuming an app is written using the > > same > > > > request-size each time - should be entirely predictable after the > > first > > > > call. > > > > > > > Why does everyone assume that DPDK applications are so simple that > > the branch predictor will cover the entire data path? I hear this > > argument over and over again, and by principle I disagree with it! > > > > > > > Fair enough, that was an assumption on my part. Do you see in your apps > > many cases where branches are getting mispredicted despite going the > > same > > way each time though the code? > > > We haven't looked deeply into this, but I don't think so. > > My objection is of a more general nature. As a library, DPDK cannot assume > that applications using it are simple, and - based on that assumption - take > away resources that could have been available for the application. > > The Intel general optimization guidelines specifies that code should be > arranged to be consistent with the static branch prediction algorithm: make > the fall-through code following a conditional branch be the likely target for > a branch with a forward target, and make the fall-through code following a > conditional branch be the unlikely target for a branch with a backward target. > > It also says: Conditional branches that are never taken do not consume BTB > resources. > > Somehow this last detail is completely ignored by DPDK developers. > > We put a lot of effort into conserving resources in most areas in DPDK, but > when it comes to the branch prediction target buff
Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs
> From: Jeff Guo [mailto:jia@intel.com] > Sent: Thursday, August 27, 2020 12:10 PM > > The limitation of burst size in vector rx was removed, since it should > retrieve as much received packets as possible. And also the scattered > receive path should use a wrapper function to achieve the goal of > burst maximizing. > > This patch set aims to maximize vector rx burst for for > ixgbe/i40e/ice/iavf/fm10k PMDs. > > v2->v1: > 1:add fm10k driver case > 2:refine some doc > I now noticed that the vector functions also does: nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP); I am not sure about this, but if I read it correctly, calling rte_eth_rx_burst() with nb_pkts = 33 (not 32) would only return 32 packets, even if more packets are available. (I assume that RTE_I40E_DESCS_PER_LOOP is 32.) In this case, I guess that you need to read the remaining of the requested packets using the non-vector function in order to support any nb_pkts value. That is, unless the rte_eth_rx_burst() API is extended with requirements to nb_pkts, as discussed in the other thread: http://inbox.dpdk.org/dev/20200827114117.gd...@bricha3-mobl.ger.corp.intel.com/T/#mc8051e9022d6aeb20c51c5a226b2274d3d6d4266 Med venlig hilsen / kind regards - Morten Brørup
[dpdk-dev] DPDK Experimental Functions
Hi All, During recent work on the DPDK ABI, where we are looking to develop a nightly ABI regression test. We found a large number of experimental functions currently in DPDK API. Currently, there are 537 experimental APIs out of a total of roughly ~1800 API, 30%-ish. While there is no correct number, as a percentage of the total, this appears to be very high. I would question if all these API are really "new" and warrant the status? There are currently 38 libraries and drivers with experimental functions. And to be fair there are number of recently added libraries in list, shown below. However there are also a number of libraries that have been around a very long time. The following libraries and drivers have 10 or more experimental functions: 1. rte_eal: 119 2. rte_ethdev: 43 3. rte_vhost: 42 4. rte_graph: 35 (EXPERIMENTAL) 5. rte_compressdev: 34 6. rte_rib: 28 (EXPERIMENTAL) 7. rte_pipeline: 24 8. rte_regexdev: 22 (EXPERIMENTAL) 9. rte_cryptodev: 18 10. rte_fib: 16 (EXPERIMENTAL) 11. rte_ipsec: 15 (EXPERIMENTAL) 12. rte_telemetry: 12 (EXPERIMENTAL) 13. rte_mbuf: 11 14. rte_rcu: 11 (EXPERIMENTAL) 15. rte_bus_fslmc: 11 16. rte_bpf: 10 (EXPERIMENTAL) Do the maintainers of these libraries and drivers, A. Feel that experimental status continues to be warranted against these API? B. Have plans in place to move all/some of these functions to stable in the 20.11 timeframe? Kudos to Conor Walsh for pulling this data together. Thanks, Ray K
Re: [dpdk-dev] 19.11.4 patches review and test
On Thu, 2020-08-27 at 11:57 +0100, Burakov, Anatoly wrote:
> On 27-Aug-20 11:37 AM, Luca Boccassi wrote:
> > On Thu, 2020-08-27 at 10:47 +0100, Burakov, Anatoly wrote:
> > > On 26-Aug-20 10:50 AM, Luca Boccassi wrote:
> > > > On Wed, 2020-08-26 at 02:30 +, Chen, BoX C wrote:
> > > > > Hi Luca,
> > > > > Update LTS 19.11.4 test result for Intel part. No new issue is found
> > > > > except known issues.
> > > >
> > > > Thank you!
> > > >
> > > > > * Intel(R) Testing
> > > > >
> > > > > # Basic Intel(R) NIC testing
> > > > >* PF(i40e):Passed
> > > > > - Exception message when starting testpmd for testing external
> > > > > memory. It has been fixed on 20.05.patch link:
> > > > > http://patches.dpdk.org/patch/66041/
> > > >
> > > > Anatoly, is it safe to backport this patch to 19.11? It applies and
> > > > builds cleanly when cherry-picked:
> > > >
> > > > d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
> > >
> > > Hi Luca,
> > >
> > > Yes, it should be safe - at least i'm not aware of any breakages ever
> > > being reported so far. Thanks!
> >
> > Could you please double-check that there's no other patch/change that
> > depends on it/that it depends on and is missing from 19.11.4-rc1? Given
> > we wouldn't redo the full regression run, we need to be careful
> >
>
> I'm positive that it's self-contained. It's just a different way of
> iterating through an array :)
Thanks, applied and pushed.
--
Kind regards,
Luca Boccassi
Re: [dpdk-dev] [PATCH] crypto/scheduler: rename slave to worker
> -Original Message- > From: Dybkowski, AdamX > Sent: Wednesday, August 26, 2020 4:34 PM > To: dev@dpdk.org; Trahe, Fiona ; > akhil.go...@nxp.com; Zhang, Roy Fan > Cc: Dybkowski, AdamX > Subject: [PATCH] crypto/scheduler: rename slave to worker > > This patch replaces the usage of the word 'slave' with more > appropriate word 'worker' in QAT PMD and Scheduler PMD > as well as in their docs. Also the test app was modified > to use the new wording. > > The Scheduler PMD's public API was modified according to the > previous deprecation notice: > rte_cryptodev_scheduler_slave_attach is now called > rte_cryptodev_scheduler_worker_attach, > rte_cryptodev_scheduler_slave_detach is > rte_cryptodev_scheduler_worker_detach, > rte_cryptodev_scheduler_slaves_get is > rte_cryptodev_scheduler_workers_get. > > Also, the configuration value > RTE_CRYPTODEV_SCHEDULER_MAX_NB_SLAVES > was renamed to RTE_CRYPTODEV_SCHEDULER_MAX_NB_WORKERS. > > Signed-off-by: Adam Dybkowski > --- Acked-by: Fan Zhang
[dpdk-dev] [PATCH v5 3/7] common/mlx5: query sampler object capability via DevX
Update function mlx5_devx_cmd_query_hca_attr() to add the NIC Flow
Table attributes query, then get the log_max_flow_sampler_num from
flow table properties.
Add the related structs definition in mlx5_prm.h.
Signed-off-by: Jiawei Wang
Acked-by: Ori Kam
---
drivers/common/mlx5/mlx5_devx_cmds.c | 27 +++
drivers/common/mlx5/mlx5_devx_cmds.h | 1 +
drivers/common/mlx5/mlx5_prm.h | 51
3 files changed, 79 insertions(+)
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c
b/drivers/common/mlx5/mlx5_devx_cmds.c
index 7c81ae1..fd4e3f2 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -751,6 +751,33 @@ struct mlx5_devx_obj *
if (!attr->eth_net_offloads)
return 0;
+ /* Query Flow Sampler Capability From FLow Table Properties Layout. */
+ memset(in, 0, sizeof(in));
+ memset(out, 0, sizeof(out));
+ MLX5_SET(query_hca_cap_in, in, opcode, MLX5_CMD_OP_QUERY_HCA_CAP);
+ MLX5_SET(query_hca_cap_in, in, op_mod,
+MLX5_GET_HCA_CAP_OP_MOD_NIC_FLOW_TABLE |
+MLX5_HCA_CAP_OPMOD_GET_CUR);
+
+ rc = mlx5_glue->devx_general_cmd(ctx,
+in, sizeof(in),
+out, sizeof(out));
+ if (rc)
+ goto error;
+ status = MLX5_GET(query_hca_cap_out, out, status);
+ syndrome = MLX5_GET(query_hca_cap_out, out, syndrome);
+ if (status) {
+ DRV_LOG(DEBUG, "Failed to query devx HCA capabilities, "
+ "status %x, syndrome = %x",
+ status, syndrome);
+ attr->log_max_ft_sampler_num = 0;
+ return -1;
+ }
+ hcattr = MLX5_ADDR_OF(query_hca_cap_out, out, capability);
+ attr->log_max_ft_sampler_num =
+ MLX5_GET(flow_table_nic_cap,
+ hcattr, flow_table_properties.log_max_ft_sampler_num);
+
/* Query HCA offloads for Ethernet protocol. */
memset(in, 0, sizeof(in));
memset(out, 0, sizeof(out));
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h
b/drivers/common/mlx5/mlx5_devx_cmds.h
index 1c84cea..cfa7a7b 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -102,6 +102,7 @@ struct mlx5_hca_attr {
uint32_t scatter_fcs_w_decap_disable:1;
uint32_t regex:1;
uint32_t regexp_num_of_engines;
+ uint32_t log_max_ft_sampler_num:8;
struct mlx5_hca_qos_attr qos;
struct mlx5_hca_vdpa_attr vdpa;
};
diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index e0ebe12..4a624e1 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -1036,6 +1036,7 @@ enum {
MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE = 0x0 << 1,
MLX5_GET_HCA_CAP_OP_MOD_ETHERNET_OFFLOAD_CAPS = 0x1 << 1,
MLX5_GET_HCA_CAP_OP_MOD_QOS_CAP = 0xc << 1,
+ MLX5_GET_HCA_CAP_OP_MOD_NIC_FLOW_TABLE = 0x7 << 1,
MLX5_GET_HCA_CAP_OP_MOD_VDPA_EMULATION = 0x13 << 1,
};
@@ -1470,12 +1471,62 @@ struct mlx5_ifc_virtio_emulation_cap_bits {
u8 reserved_at_1c0[0x620];
};
+struct mlx5_ifc_flow_table_prop_layout_bits {
+ u8 ft_support[0x1];
+ u8 flow_tag[0x1];
+ u8 flow_counter[0x1];
+ u8 flow_modify_en[0x1];
+ u8 modify_root[0x1];
+ u8 identified_miss_table[0x1];
+ u8 flow_table_modify[0x1];
+ u8 reformat[0x1];
+ u8 decap[0x1];
+ u8 reset_root_to_default[0x1];
+ u8 pop_vlan[0x1];
+ u8 push_vlan[0x1];
+ u8 fpga_vendor_acceleration[0x1];
+ u8 pop_vlan_2[0x1];
+ u8 push_vlan_2[0x1];
+ u8 reformat_and_vlan_action[0x1];
+ u8 modify_and_vlan_action[0x1];
+ u8 sw_owner[0x1];
+ u8 reformat_l3_tunnel_to_l2[0x1];
+ u8 reformat_l2_to_l3_tunnel[0x1];
+ u8 reformat_and_modify_action[0x1];
+ u8 reserved_at_15[0x9];
+ u8 sw_owner_v2[0x1];
+ u8 reserved_at_1f[0x1];
+ u8 reserved_at_20[0x2];
+ u8 log_max_ft_size[0x6];
+ u8 log_max_modify_header_context[0x8];
+ u8 max_modify_header_actions[0x8];
+ u8 max_ft_level[0x8];
+ u8 reserved_at_40[0x8];
+ u8 log_max_ft_sampler_num[8];
+ u8 metadata_reg_b_width[0x8];
+ u8 metadata_reg_a_width[0x8];
+ u8 reserved_at_60[0x18];
+ u8 log_max_ft_num[0x8];
+ u8 reserved_at_80[0x10];
+ u8 log_max_flow_counter[0x8];
+ u8 log_max_destination[0x8];
+ u8 reserved_at_a0[0x18];
+ u8 log_max_flow[0x8];
+ u8 reserved_at_c0[0x140];
+};
+
+struct mlx5_ifc_flow_table_nic_cap_bits {
+ u8 reserved_at_0[0x200];
+ struct mlx5_ifc_flow_table_prop_layout_bits flow_table_properties;
+};
+
union mlx5_ifc_hca_cap_union_bits {
struct mlx5_ifc_cmd_hca_cap_bits cmd_hca_cap;
struct mlx5_ifc_per_protocol_net
[dpdk-dev] [PATCH v5 5/7] net/mlx5: split sample flow into two sub flows
Add the sampler action resource structs definition.
The flow with sample action will be splited into two sub flows,
the prefix flow with sample action, the suffix flow with the left
actions.
For the prefix flow, add the extra the tag action with unique id
to metadata register, and suffix flow will add the extra tag item
to match that unique id.
Signed-off-by: Jiawei Wang
Acked-by: Ori Kam
---
drivers/net/mlx5/mlx5.c | 11 ++
drivers/net/mlx5/mlx5.h | 3 +
drivers/net/mlx5/mlx5_flow.c | 258 ++-
drivers/net/mlx5/mlx5_flow.h | 36 ++
4 files changed, 304 insertions(+), 4 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 1e4c695..7b33a3e 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -244,6 +244,17 @@ static LIST_HEAD(, mlx5_dev_ctx_shared) mlx5_dev_ctx_list =
.free = mlx5_free,
.type = "mlx5_jump_ipool",
},
+ {
+ .size = sizeof(struct mlx5_flow_dv_sample_resource),
+ .trunk_size = 64,
+ .grow_trunk = 3,
+ .grow_shift = 2,
+ .need_lock = 0,
+ .release_mem_en = 1,
+ .malloc = mlx5_malloc,
+ .free = mlx5_free,
+ .type = "mlx5_sample_ipool",
+ },
#endif
{
.size = sizeof(struct mlx5_flow_meter),
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index ae0c7cc..a76c161 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -41,6 +41,7 @@ enum mlx5_ipool_index {
MLX5_IPOOL_TAG, /* Pool for tag resource. */
MLX5_IPOOL_PORT_ID, /* Pool for port id resource. */
MLX5_IPOOL_JUMP, /* Pool for jump resource. */
+ MLX5_IPOOL_SAMPLE, /* Pool for sample resource. */
#endif
MLX5_IPOOL_MTR, /* Pool for meter resource. */
MLX5_IPOOL_MCP, /* Pool for metadata resource. */
@@ -514,6 +515,7 @@ struct mlx5_flow_tbl_resource {
/* Tables for metering splits should be added here. */
#define MLX5_MAX_TABLES_EXTERNAL (MLX5_MAX_TABLES - 3)
#define MLX5_MAX_TABLES_FDB UINT16_MAX
+#define MLX5_FLOW_TABLE_FACTOR 10
/* ID generation structure. */
struct mlx5_flow_id_pool {
@@ -642,6 +644,7 @@ struct mlx5_dev_ctx_shared {
struct mlx5_hlist *tag_table;
uint32_t port_id_action_list; /* List of port ID actions. */
uint32_t push_vlan_action_list; /* List of push VLAN actions. */
+ uint32_t sample_action_list; /* List of sample actions. */
struct mlx5_flow_counter_mng cmng; /* Counters management structure. */
struct mlx5_flow_default_miss_resource default_miss;
/* Default miss action resource structure. */
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 7150173..49f49e7 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -3908,6 +3908,139 @@ struct mlx5_flow_tunnel_info {
return 0;
}
+
+/**
+ * Check the match action from the action list.
+ *
+ * @param[in] actions
+ * Pointer to the list of actions.
+ * @param[in] action
+ * The action to be check if exist.
+ *
+ * @return
+ * > 0 the total number of actions.
+ * 0 if not found match action in action list.
+ */
+static int
+flow_check_match_action(const struct rte_flow_action actions[],
+ enum rte_flow_action_type action)
+{
+ int actions_n = 0;
+ int flag = 0;
+
+ for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
+ if (actions->type == action)
+ flag = 1;
+ actions_n++;
+ }
+ /* Count RTE_FLOW_ACTION_TYPE_END. */
+ return flag ? actions_n + 1 : 0;
+}
+
+/**
+ * Split the sample flow.
+ *
+ * As sample flow will split to two sub flow, sample flow with
+ * sample action, the other actions will move to new suffix flow.
+ *
+ * Also add unique tag id with tag action in the sample flow,
+ * the same tag id will be as match in the suffix flow.
+ *
+ * @param dev
+ * Pointer to Ethernet device.
+ * @param[in] attr
+ * Flow rule attributes.
+ * @param[out] sfx_items
+ * Suffix flow match items (list terminated by the END pattern item).
+ * @param[in] actions
+ * Associated actions (list terminated by the END action).
+ * @param[out] actions_sfx
+ * Suffix flow actions.
+ * @param[out] actions_pre
+ * Prefix flow actions.
+ *
+ * @return
+ * 0 on success, or unique flow_id.
+ */
+static int
+flow_sample_split_prep(struct rte_eth_dev *dev,
+const struct rte_flow_attr *attr,
+struct rte_flow_item sfx_items[],
+const struct rte_flow_action actions[],
+struct rte_flow_action actions_sfx[],
+struct rte_flow_action actions_pre[])
+{
+ struct mlx5_rte_flow_action_set_tag *set_tag;
+ struct mlx5_rte_flow_item_tag *tag_spec;
+ struct mlx5_rte
[dpdk-dev] [PATCH v5 0/7] support the flow-based traffic sampling
This patch set implement the flow sampling for mlx5 driver. The solution is introduced a new rte_flow action that will sample the incoming traffic and send a duplicated traffic with the specified ratio to the application, while the original packet will continue to the target destination. If the sample ratio value be set to 1, means that the packets would be completely mirrored. The sample packet can be assigned with different set of actions from the original packet. MLX5 PMD driver will be responsible for validate and translate the sample action while creating a flow. v5: * Add the release note. * Remove Make changes since it's deprecated. v4: * Rebase. * Fix the coding style issue. v3: * Remove 'const' of ratio field. * Update description and commit messages. v2: * Rebase patches based on the latest code. * Update rte_flow and release documents. * Fix the compile error. * Removed unnecessary change in [PATCH 7/8] net/mlx5: update the metadata register c0 support since FDB will use 5-tuple to do match. * Update changes based on the comments. Jiawei Wang (7): ethdev: introduce sample action for rte flow common/mlx5: glue for sample action common/mlx5: query sampler object capability via DevX net/mlx5: add the validate sample action net/mlx5: split sample flow into two sub flows net/mlx5: update translate function for sample action app/testpmd: add testpmd command for sample action app/test-pmd/cmdline_flow.c| 285 ++- doc/guides/prog_guide/rte_flow.rst | 25 ++ doc/guides/rel_notes/release_20_11.rst | 6 + drivers/common/mlx5/linux/meson.build | 2 + drivers/common/mlx5/linux/mlx5_glue.c | 15 + drivers/common/mlx5/linux/mlx5_glue.h | 12 + drivers/common/mlx5/mlx5_devx_cmds.c | 27 ++ drivers/common/mlx5/mlx5_devx_cmds.h | 1 + drivers/common/mlx5/mlx5_prm.h | 51 +++ drivers/net/mlx5/linux/mlx5_os.c | 14 + drivers/net/mlx5/mlx5.c| 11 + drivers/net/mlx5/mlx5.h| 4 + drivers/net/mlx5/mlx5_flow.c | 274 +- drivers/net/mlx5/mlx5_flow.h | 51 ++- drivers/net/mlx5/mlx5_flow_dv.c| 627 - lib/librte_ethdev/rte_flow.c | 1 + lib/librte_ethdev/rte_flow.h | 30 ++ 17 files changed, 1401 insertions(+), 35 deletions(-) -- 1.8.3.1
[dpdk-dev] [PATCH v5 2/7] common/mlx5: glue for sample action
rdma-core introduce a new DR sample action.
Add the rdma-core commands in glue to create this action.
Sample action is used for creating the sample object to implement
the sampling/mirroring function.
Signed-off-by: Jiawei Wang
Acked-by: Ori Kam
---
drivers/common/mlx5/linux/meson.build | 2 ++
drivers/common/mlx5/linux/mlx5_glue.c | 15 +++
drivers/common/mlx5/linux/mlx5_glue.h | 12
3 files changed, 29 insertions(+)
diff --git a/drivers/common/mlx5/linux/meson.build
b/drivers/common/mlx5/linux/meson.build
index 48e8ad6..1aa137d 100644
--- a/drivers/common/mlx5/linux/meson.build
+++ b/drivers/common/mlx5/linux/meson.build
@@ -172,6 +172,8 @@ has_sym_args = [
'RDMA_NLDEV_ATTR_NDEV_INDEX' ],
[ 'HAVE_MLX5_DR_FLOW_DUMP', 'infiniband/mlx5dv.h',
'mlx5dv_dump_dr_domain'],
+ [ 'HAVE_MLX5_DR_CREATE_ACTION_FLOW_SAMPLE', 'infiniband/mlx5dv.h',
+ 'mlx5dv_dr_action_create_flow_sampler'],
[ 'HAVE_MLX5DV_DR_MEM_RECLAIM', 'infiniband/mlx5dv.h',
'mlx5dv_dr_domain_set_reclaim_device_memory'],
[ 'HAVE_DEVLINK', 'linux/devlink.h', 'DEVLINK_GENL_NAME' ],
diff --git a/drivers/common/mlx5/linux/mlx5_glue.c
b/drivers/common/mlx5/linux/mlx5_glue.c
index fcf03e8..771a47c 100644
--- a/drivers/common/mlx5/linux/mlx5_glue.c
+++ b/drivers/common/mlx5/linux/mlx5_glue.c
@@ -1063,6 +1063,19 @@
#endif
}
+static void *
+mlx5_glue_dr_create_flow_action_sampler(
+ struct mlx5dv_dr_flow_sampler_attr *attr)
+{
+#ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_SAMPLE
+ return mlx5dv_dr_action_create_flow_sampler(attr);
+#else
+ (void)attr;
+ errno = ENOTSUP;
+ return NULL;
+#endif
+}
+
static int
mlx5_glue_devx_query_eqn(struct ibv_context *ctx, uint32_t cpus,
uint32_t *eqn)
@@ -1339,6 +1352,8 @@
.devx_port_query = mlx5_glue_devx_port_query,
.dr_dump_domain = mlx5_glue_dr_dump_domain,
.dr_reclaim_domain_memory = mlx5_glue_dr_reclaim_domain_memory,
+ .dr_create_flow_action_sampler =
+ mlx5_glue_dr_create_flow_action_sampler,
.devx_query_eqn = mlx5_glue_devx_query_eqn,
.devx_create_event_channel = mlx5_glue_devx_create_event_channel,
.devx_destroy_event_channel = mlx5_glue_devx_destroy_event_channel,
diff --git a/drivers/common/mlx5/linux/mlx5_glue.h
b/drivers/common/mlx5/linux/mlx5_glue.h
index 734ace2..85b43b9 100644
--- a/drivers/common/mlx5/linux/mlx5_glue.h
+++ b/drivers/common/mlx5/linux/mlx5_glue.h
@@ -77,6 +77,7 @@
#ifndef HAVE_MLX5DV_DR
enum mlx5dv_dr_domain_type { unused, };
struct mlx5dv_dr_domain;
+struct mlx5dv_dr_action;
#endif
#ifndef HAVE_MLX5DV_DR_DEVX_PORT
@@ -87,6 +88,15 @@
struct mlx5dv_dr_flow_meter_attr;
#endif
+#ifndef HAVE_MLX5_DR_CREATE_ACTION_FLOW_SAMPLE
+struct mlx5dv_dr_flow_sampler_attr {
+ uint32_t sample_ratio;
+ void *default_next_table;
+ size_t num_sample_actions;
+ struct mlx5dv_dr_action **sample_actions;
+};
+#endif
+
#ifndef HAVE_IBV_DEVX_EVENT
struct mlx5dv_devx_event_channel { int fd; };
struct mlx5dv_devx_async_event_hdr;
@@ -309,6 +319,8 @@ struct mlx5_glue {
const void *pp_context,
uint32_t flags);
void (*dv_free_pp)(struct mlx5dv_pp *pp);
+ void *(*dr_create_flow_action_sampler)
+ (struct mlx5dv_dr_flow_sampler_attr *attr);
};
extern const struct mlx5_glue *mlx5_glue;
--
1.8.3.1
[dpdk-dev] [PATCH v5 6/7] net/mlx5: update translate function for sample action
Translate the attribute of sample action that include sample ratio
and sub actions list, then create the sample DR action.
Signed-off-by: Jiawei Wang
Acked-by: Ori Kam
---
drivers/net/mlx5/mlx5_flow.c| 16 +-
drivers/net/mlx5/mlx5_flow.h| 14 +-
drivers/net/mlx5/mlx5_flow_dv.c | 494 +++-
3 files changed, 502 insertions(+), 22 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 49f49e7..d2b79f0 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -4606,10 +4606,14 @@ struct mlx5_flow_tunnel_info {
int hairpin_flow;
uint32_t hairpin_id = 0;
struct rte_flow_attr attr_tx = { .priority = 0 };
+ struct rte_flow_attr attr_factor = {0};
int ret;
- hairpin_flow = flow_check_hairpin_split(dev, attr, actions);
- ret = flow_drv_validate(dev, attr, items, p_actions_rx,
+ memcpy((void *)&attr_factor, (const void *)attr, sizeof(*attr));
+ if (external)
+ attr_factor.group *= MLX5_FLOW_TABLE_FACTOR;
+ hairpin_flow = flow_check_hairpin_split(dev, &attr_factor, actions);
+ ret = flow_drv_validate(dev, &attr_factor, items, p_actions_rx,
external, hairpin_flow, error);
if (ret < 0)
return 0;
@@ -4628,7 +4632,7 @@ struct mlx5_flow_tunnel_info {
rte_errno = ENOMEM;
goto error_before_flow;
}
- flow->drv_type = flow_get_drv_type(dev, attr);
+ flow->drv_type = flow_get_drv_type(dev, &attr_factor);
if (hairpin_id != 0)
flow->hairpin_flow_id = hairpin_id;
MLX5_ASSERT(flow->drv_type > MLX5_FLOW_TYPE_MIN &&
@@ -4674,7 +4678,7 @@ struct mlx5_flow_tunnel_info {
* depending on configuration. In the simplest
* case it just creates unmodified original flow.
*/
- ret = flow_create_split_outer(dev, flow, attr,
+ ret = flow_create_split_outer(dev, flow, &attr_factor,
buf->entry[i].pattern,
p_actions_rx, external, idx,
error);
@@ -4711,8 +4715,8 @@ struct mlx5_flow_tunnel_info {
* the egress Flows belong to the different device and
* copy table should be updated in peer NIC Rx domain.
*/
- if (attr->ingress &&
- (external || attr->group != MLX5_FLOW_MREG_CP_TABLE_GROUP)) {
+ if (attr_factor.ingress &&
+ (external || attr_factor.group != MLX5_FLOW_MREG_CP_TABLE_GROUP)) {
ret = flow_mreg_update_copy_table(dev, flow, actions, error);
if (ret)
goto error;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 9d2493a..f3c0406 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -366,6 +366,13 @@ enum mlx5_flow_fate_type {
MLX5_FLOW_FATE_MAX,
};
+/*
+ * Max number of actions per DV flow.
+ * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
+ * in rdma-core file providers/mlx5/verbs.c.
+ */
+#define MLX5_DV_MAX_NUMBER_OF_ACTIONS 8
+
/* Matcher PRM representation */
struct mlx5_flow_dv_match_params {
size_t size;
@@ -613,13 +620,6 @@ struct mlx5_flow_handle {
#define MLX5_FLOW_HANDLE_VERBS_SIZE (sizeof(struct mlx5_flow_handle))
#endif
-/*
- * Max number of actions per DV flow.
- * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
- * in rdma-core file providers/mlx5/verbs.c.
- */
-#define MLX5_DV_MAX_NUMBER_OF_ACTIONS 8
-
/** Device flow structure only for DV flow creation. */
struct mlx5_flow_dv_workspace {
uint32_t group; /**< The group index. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index a8db8ab..3d85140 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -76,6 +76,10 @@
static int
flow_dv_default_miss_resource_release(struct rte_eth_dev *dev);
+static int
+flow_dv_encap_decap_resource_release(struct rte_eth_dev *dev,
+ uint32_t encap_decap_idx);
+
/**
* Initialize flow attributes structure according to flow items' types.
*
@@ -8233,6 +8237,373 @@ struct field_modify_info modify_tcp[] = {
}
/**
+ * Create an Rx Hash queue.
+ *
+ * @param dev
+ * Pointer to Ethernet device.
+ * @param[in] dev_flow
+ * Pointer to the mlx5_flow.
+ * @param[in] rss_desc
+ * Pointer to the mlx5_flow_rss_desc.
+ * @param[out] hrxq_idx
+ * Hash Rx queue index.
+ *
+ * @return
+ * The Verbs/DevX object initialised, NULL otherwise and rte_errno is set.
+ */
+static struct mlx5_hrxq *
+flow_dv_handle_rx_queue(struct rte_eth_dev *dev,
+ struct mlx5_flow *dev_flow,
+ struct mlx5_flow_rss_desc *rss_desc,
+ uint32_t *hrxq_idx)
+{
+
[dpdk-dev] [PATCH v5 4/7] net/mlx5: add the validate sample action
Add sample action validate function.
For Sample flow support NIC-RX and FDB domain, must include an
action of a dest TIR in NIC_RX.
Only NIC_RX support with addition optional actions. FDB doesn't
support any optional action, the sampled packets is always goes
to e-switch manager port.
Signed-off-by: Jiawei Wang
Acked-by: Ori Kam
---
drivers/net/mlx5/linux/mlx5_os.c | 14 +
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_flow.h | 1 +
drivers/net/mlx5/mlx5_flow_dv.c | 133 +++
4 files changed, 149 insertions(+)
diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index db955ae..5b663a1 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -1015,6 +1015,20 @@
}
}
#endif
+#if defined(HAVE_MLX5DV_DR) && defined(HAVE_MLX5_DR_CREATE_ACTION_FLOW_SAMPLE)
+ if (config->hca_attr.log_max_ft_sampler_num > 0 &&
+ config->dv_flow_en) {
+ priv->sampler_en = 1;
+ DRV_LOG(DEBUG, "The Sampler enabled!\n");
+ } else {
+ priv->sampler_en = 0;
+ if (!config->hca_attr.log_max_ft_sampler_num)
+ DRV_LOG(WARNING, "No available register for"
+ " Sampler.");
+ else
+ DRV_LOG(DEBUG, "DV flow is not supported!\n");
+ }
+#endif
}
if (config->tx_pp) {
DRV_LOG(DEBUG, "Timestamp counter frequency %u kHz",
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 1880a82..ae0c7cc 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -698,6 +698,7 @@ struct mlx5_priv {
unsigned int counter_fallback:1; /* Use counter fallback management. */
unsigned int mtr_en:1; /* Whether support meter. */
unsigned int mtr_reg_share:1; /* Whether support meter REG_C share. */
+ unsigned int sampler_en:1; /* Whether support sampler. */
uint16_t domain_id; /* Switch domain identifier. */
uint16_t vport_id; /* Associated VF vport index (if any). */
uint32_t vport_meta_tag; /* Used for vport index match ove VF LAG. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 92301e4..41404de 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -196,6 +196,7 @@ enum mlx5_feature_name {
#define MLX5_FLOW_ACTION_SET_IPV6_DSCP (1ull << 33)
#define MLX5_FLOW_ACTION_AGE (1ull << 34)
#define MLX5_FLOW_ACTION_DEFAULT_MISS (1ull << 35)
+#define MLX5_FLOW_ACTION_SAMPLE (1ull << 36)
#define MLX5_FLOW_FATE_ACTIONS \
(MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_QUEUE | \
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index dd35959..a8db8ab 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -3992,6 +3992,130 @@ struct field_modify_info modify_tcp[] = {
}
/**
+ * Validate the sample action.
+ *
+ * @param[in] action_flags
+ * Holds the actions detected until now.
+ * @param[in] action
+ * Pointer to the sample action.
+ * @param[in] dev
+ * Pointer to the Ethernet device structure.
+ * @param[in] attr
+ * Attributes of flow that includes this action.
+ * @param[out] error
+ * Pointer to error structure.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_sample(uint64_t action_flags,
+ const struct rte_flow_action *action,
+ struct rte_eth_dev *dev,
+ const struct rte_flow_attr *attr,
+ struct rte_flow_error *error)
+{
+ struct mlx5_priv *priv = dev->data->dev_private;
+ struct mlx5_dev_config *dev_conf = &priv->config;
+ const struct rte_flow_action_sample *sample = action->conf;
+ const struct rte_flow_action *act = sample->actions;
+ uint64_t sub_action_flags = 0;
+ int actions_n = 0;
+ int ret;
+
+ if (!attr->group)
+ return rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ATTR_GROUP,
+ NULL, "root table is not supported");
+ if (!priv->config.devx || !priv->sampler_en)
+ return rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL,
+ "sample action not supported");
+ if (!(action->conf))
+ return rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ACTION, action,
+ "configuration c
[dpdk-dev] [PATCH v5 1/7] ethdev: introduce sample action for rte flow
When using full offload, all traffic will be handled by the HW, and
directed to the requested VF or wire, the control application loses
visibility on the traffic.
So there's a need for an action that will enable the control application
some visibility.
The solution is introduced a new action that will sample the incoming
traffic and send a duplicated traffic with the specified ratio to the
application, while the original packet will continue to the target
destination.
The packets sampled equals is '1/ratio', if the ratio value be set to 1,
means that the packets would be completely mirrored. The sample packet
can be assigned with different set of actions from the original packet.
In order to support the sample packet in rte_flow, new rte_flow action
definition RTE_FLOW_ACTION_TYPE_SAMPLE and structure rte_flow_action_sample
will be introduced.
Signed-off-by: Jiawei Wang
Acked-by: Ori Kam
Acked-by: Jerin Jacob
Acked-by: Andrew Rybchenko
---
doc/guides/prog_guide/rte_flow.rst | 25 +
doc/guides/rel_notes/release_20_11.rst | 6 ++
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 30 ++
4 files changed, 62 insertions(+)
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index 3e5cd1e..f8f3f51 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2653,6 +2653,31 @@ timeout passed without any matching on the flow.
| ``context`` | user input flow context |
+--+-+
+Action: ``SAMPLE``
+^^
+
+Adds a sample action to a matched flow.
+
+The matching packets will be duplicated with the specified ``ratio`` and
+applied with own set of actions with a fate action, the packets sampled
+equals is '1/ratio'. All the packets continue to the target destination.
+
+When the ``ratio`` is set to 1 then the packets will be 100% mirrored.
+``actions`` represent the different set of actions for the sampled or mirrored
+packets, and must have a fate action.
+
+.. _table_rte_flow_action_sample:
+
+.. table:: SAMPLE
+
+ +--+-+
+ | Field| Value |
+ +==+=+
+ | ``ratio``| 32 bits sample ratio value |
+ +--+-+
+ | ``actions`` | sub-action list for sampling|
+ +--+-+
+
Negative types
~~
diff --git a/doc/guides/rel_notes/release_20_11.rst
b/doc/guides/rel_notes/release_20_11.rst
index df227a1..7f99563 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -55,6 +55,12 @@ New Features
Also, make sure to start the actual text at the margin.
===
+* **Added flow-based traffic sampling support.**
+
+ Added new action: ``RTE_FLOW_ACTION_TYPE_SAMPLE`` to duplicate the matching
+ packets with specified ratio, and apply with own set of actions with a fate
+ action. When the ratio is set to 1 then the packets will be 100% mirrored.
+
Removed Items
-
diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
index f8fdd68..035671d 100644
--- a/lib/librte_ethdev/rte_flow.c
+++ b/lib/librte_ethdev/rte_flow.c
@@ -174,6 +174,7 @@ struct rte_flow_desc_data {
MK_FLOW_ACTION(SET_IPV4_DSCP, sizeof(struct rte_flow_action_set_dscp)),
MK_FLOW_ACTION(SET_IPV6_DSCP, sizeof(struct rte_flow_action_set_dscp)),
MK_FLOW_ACTION(AGE, sizeof(struct rte_flow_action_age)),
+ MK_FLOW_ACTION(SAMPLE, sizeof(struct rte_flow_action_sample)),
};
int
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index da8bfa5..fa70d40 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -2132,6 +2132,14 @@ enum rte_flow_action_type {
* see enum RTE_ETH_EVENT_FLOW_AGED
*/
RTE_FLOW_ACTION_TYPE_AGE,
+
+ /**
+* The matching packets will be duplicated with specified ratio and
+* applied with own set of actions with a fate action.
+*
+* See struct rte_flow_action_sample.
+*/
+ RTE_FLOW_ACTION_TYPE_SAMPLE,
};
/**
@@ -2742,6 +2750,28 @@ struct rte_flow_action {
struct rte_flow;
/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_SAMPLE
+ *
+ * Adds a sample action to a matched flow.
+ *
+ * The matching packets will be duplicated with specified ratio and applied
+ * with own set of actions with a fate action, the sampled packet could be
+ * redirected to queue or port. All the packets continue processing on the
+ * default flow path.
+ *
+ * When the sample ratio is set to 1 then the packets will be 100% mirrored.
+ * Additio
[dpdk-dev] [PATCH v5 7/7] app/testpmd: add testpmd command for sample action
Add a new testpmd command 'set sample_actions' that supports the multiple
sample actions list configuration by using the index:
set sample_actions
The examples for the sample flow use case and result as below:
1. set sample_actions 0 mark id 0x8 / queue index 2 / end
.. pattern eth / end actions sample ratio 2 index 0 / jump group 2 ...
This flow will result in all the matched ingress packets will be
jumped to next flow table, and the each second packet will be
marked and sent to queue 2 of the control application.
2. ...pattern eth / end actions sample ratio 2 / port_id id 2 ...
The flow will result in all the matched ingress packets will be sent to
port 2, and the each second packet will also be sent to e-switch
manager vport.
Signed-off-by: Jiawei Wang
Acked-by: Ori Kam
---
app/test-pmd/cmdline_flow.c | 285 ++--
1 file changed, 276 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 6263d30..27fa294 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -56,6 +56,8 @@ enum index {
SET_RAW_ENCAP,
SET_RAW_DECAP,
SET_RAW_INDEX,
+ SET_SAMPLE_ACTIONS,
+ SET_SAMPLE_INDEX,
/* Top-level command. */
FLOW,
@@ -358,6 +360,10 @@ enum index {
ACTION_SET_IPV6_DSCP_VALUE,
ACTION_AGE,
ACTION_AGE_TIMEOUT,
+ ACTION_SAMPLE,
+ ACTION_SAMPLE_RATIO,
+ ACTION_SAMPLE_INDEX,
+ ACTION_SAMPLE_INDEX_VALUE,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -493,6 +499,22 @@ struct action_nvgre_encap_data {
struct mplsoudp_decap_conf mplsoudp_decap_conf;
+#define ACTION_SAMPLE_ACTIONS_NUM 10
+#define RAW_SAMPLE_CONFS_MAX_NUM 8
+/** Storage for struct rte_flow_action_sample including external data. */
+struct action_sample_data {
+ struct rte_flow_action_sample conf;
+ uint32_t idx;
+};
+/** Storage for struct rte_flow_action_sample. */
+struct raw_sample_conf {
+ struct rte_flow_action data[ACTION_SAMPLE_ACTIONS_NUM];
+};
+struct raw_sample_conf raw_sample_confs[RAW_SAMPLE_CONFS_MAX_NUM];
+struct rte_flow_action_mark sample_mark[RAW_SAMPLE_CONFS_MAX_NUM];
+struct rte_flow_action_queue sample_queue[RAW_SAMPLE_CONFS_MAX_NUM];
+struct rte_flow_action_count sample_count[RAW_SAMPLE_CONFS_MAX_NUM];
+
/** Maximum number of subsequent tokens and arguments on the stack. */
#define CTX_STACK_SIZE 16
@@ -1189,6 +1211,7 @@ struct parse_action_priv {
ACTION_SET_IPV4_DSCP,
ACTION_SET_IPV6_DSCP,
ACTION_AGE,
+ ACTION_SAMPLE,
ZERO,
};
@@ -1421,9 +1444,28 @@ struct parse_action_priv {
ZERO,
};
+static const enum index action_sample[] = {
+ ACTION_SAMPLE,
+ ACTION_SAMPLE_RATIO,
+ ACTION_SAMPLE_INDEX,
+ ACTION_NEXT,
+ ZERO,
+};
+
+static const enum index next_action_sample[] = {
+ ACTION_QUEUE,
+ ACTION_MARK,
+ ACTION_COUNT,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
+static int parse_set_sample_action(struct context *, const struct token *,
+ const char *, unsigned int,
+ void *, unsigned int);
static int parse_set_init(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -1491,7 +1533,15 @@ static int parse_vc_action_raw_decap_index(struct
context *,
static int parse_vc_action_set_meta(struct context *ctx,
const struct token *token, const char *str,
unsigned int len, void *buf,
+ unsigned int size);
+static int parse_vc_action_sample(struct context *ctx,
+ const struct token *token, const char *str,
+ unsigned int len, void *buf,
unsigned int size);
+static int
+parse_vc_action_sample_index(struct context *ctx, const struct token *token,
+ const char *str, unsigned int len, void *buf,
+ unsigned int size);
static int parse_destroy(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -1562,6 +1612,8 @@ static int comp_vc_action_rss_queue(struct context *,
const struct token *,
unsigned int, char *, unsigned int);
static int comp_set_raw_index(struct context *, const struct token *,
unsigned int, char *, unsigned int);
+static int comp_set_sample_index(struct context *, const struct token *,
+
[dpdk-dev] [PATCH 1/2] net/ark: remove compile time log macros in favor of run time log control
Use ARK_PMD_LOG in place of PMD_DRV_LOG, PMD_DEBUG_LOG, PMD_FUNC_LOG,
PMD_STATS_LOG, PMD_RX_LOG, and PMD_TX_LOG.
Review and adjust log levels and messages as needed.
Signed-off-by: Ed Czeck
---
doc/guides/nics/ark.rst | 13 --
drivers/net/ark/ark_ddm.c | 12 ++---
drivers/net/ark/ark_ethdev.c| 77 +++--
drivers/net/ark/ark_ethdev_rx.c | 46 ++--
drivers/net/ark/ark_ethdev_tx.c | 10 ++---
drivers/net/ark/ark_logs.h | 63 +++
drivers/net/ark/ark_mpu.c | 32 --
drivers/net/ark/ark_pktchkr.c | 36 +++
drivers/net/ark/ark_pktdir.c| 2 +-
drivers/net/ark/ark_pktgen.c| 22 +-
drivers/net/ark/ark_rqp.c | 4 +-
drivers/net/ark/ark_udm.c | 18
12 files changed, 125 insertions(+), 210 deletions(-)
diff --git a/doc/guides/nics/ark.rst b/doc/guides/nics/ark.rst
index 06e8c3374..c3ffcbbc2 100644
--- a/doc/guides/nics/ark.rst
+++ b/doc/guides/nics/ark.rst
@@ -132,19 +132,6 @@ Configuration Information
* **CONFIG_RTE_LIBRTE_ARK_PAD_TX** (default y): When enabled TX
packets are padded to 60 bytes to support downstream MACS.
- * **CONFIG_RTE_LIBRTE_ARK_DEBUG_RX** (default n): Enables or disables debug
- logging and internal checking of RX ingress logic within the ARK PMD
driver.
-
- * **CONFIG_RTE_LIBRTE_ARK_DEBUG_TX** (default n): Enables or disables debug
- logging and internal checking of TX egress logic within the ARK PMD
driver.
-
- * **CONFIG_RTE_LIBRTE_ARK_DEBUG_STATS** (default n): Enables or disables
debug
- logging of detailed packet and performance statistics gathered in
- the PMD and FPGA.
-
- * **CONFIG_RTE_LIBRTE_ARK_DEBUG_TRACE** (default n): Enables or disables
debug
- logging of detailed PMD events and status.
-
Building DPDK
-
diff --git a/drivers/net/ark/ark_ddm.c b/drivers/net/ark/ark_ddm.c
index 57026f8d1..91d1179d8 100644
--- a/drivers/net/ark/ark_ddm.c
+++ b/drivers/net/ark/ark_ddm.c
@@ -13,19 +13,19 @@ ark_ddm_verify(struct ark_ddm_t *ddm)
{
uint32_t hw_const;
if (sizeof(struct ark_ddm_t) != ARK_DDM_EXPECTED_SIZE) {
- PMD_DRV_LOG(ERR, "ARK: DDM structure looks incorrect %d vs
%zd\n",
+ ARK_PMD_LOG(ERR, "DDM structure looks incorrect %d vs %zd\n",
ARK_DDM_EXPECTED_SIZE, sizeof(struct ark_ddm_t));
return -1;
}
hw_const = ddm->cfg.const0;
if (hw_const == ARK_DDM_CONST1) {
- PMD_DRV_LOG(ERR,
+ ARK_PMD_LOG(ERR,
"ARK: DDM module is version 1, "
"PMD expects version 2\n");
return -1;
} else if (hw_const != ARK_DDM_CONST2) {
- PMD_DRV_LOG(ERR,
+ ARK_PMD_LOG(ERR,
"ARK: DDM module not found as expected 0x%08x\n",
ddm->cfg.const0);
return -1;
@@ -63,7 +63,7 @@ ark_ddm_reset(struct ark_ddm_t *ddm)
status = ark_ddm_stop(ddm, 1);
if (status != 0) {
- PMD_DEBUG_LOG(INFO, "%s stop failed doing forced reset\n",
+ ARK_PMD_LOG(NOTICE, "%s stop failed doing forced reset\n",
__func__);
ddm->cfg.command = 4;
usleep(10);
@@ -87,7 +87,7 @@ ark_ddm_stats_reset(struct ark_ddm_t *ddm)
void
ark_ddm_dump(struct ark_ddm_t *ddm, const char *msg)
{
- PMD_FUNC_LOG(DEBUG, "%s Stopped: %d\n", msg,
+ ARK_PMD_LOG(DEBUG, "%s Stopped: %d\n", msg,
ark_ddm_is_stopped(ddm)
);
}
@@ -97,7 +97,7 @@ ark_ddm_dump_stats(struct ark_ddm_t *ddm, const char *msg)
{
struct ark_ddm_stats_t *stats = &ddm->stats;
- PMD_STATS_LOG(INFO, "DDM Stats: %s"
+ ARK_PMD_LOG(INFO, "DDM Stats: %s"
ARK_SU64 ARK_SU64 ARK_SU64
"\n", msg,
"Bytes:", stats->tx_byte_count,
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index b32ccd867..646427d0c 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -164,26 +164,26 @@ check_for_ext(struct ark_adapter *ark)
const char *dllpath = getenv("ARK_EXT_PATH");
if (dllpath == NULL) {
- PMD_DEBUG_LOG(DEBUG, "ARK EXT NO dll path specified\n");
+ ARK_PMD_LOG(DEBUG, "EXT NO dll path specified\n");
return 0;
}
- PMD_DRV_LOG(INFO, "ARK EXT found dll path at %s\n", dllpath);
+ ARK_PMD_LOG(NOTICE, "EXT found dll path at %s\n", dllpath);
/* Open and load the .so */
ark->d_handle = dlopen(dllpath, RTLD_LOCAL | RTLD_LAZY);
if (ark->d_handle == NULL) {
- PMD_DRV_LOG(ERR, "Could not load user extension %s\n",
+ ARK_PMD_LOG(ERR, "Could not load user extension %s\n"
[dpdk-dev] [PATCH 2/2] net/ark: remove RTE_LIBRTE_ARK_PAD_TX configuration macro
Replace behavior with RTE_LIBRTE_ARK_MIN_TX_PKTLEN
with a default value of 0.
Update documentation as needed.
Signed-off-by: Ed Czeck
---
doc/guides/nics/ark.rst | 16
drivers/net/ark/ark_ethdev_tx.c | 43 ++---
drivers/net/ark/ark_logs.h | 8 --
3 files changed, 35 insertions(+), 32 deletions(-)
diff --git a/doc/guides/nics/ark.rst b/doc/guides/nics/ark.rst
index c3ffcbbc2..c7ed4095f 100644
--- a/doc/guides/nics/ark.rst
+++ b/doc/guides/nics/ark.rst
@@ -126,11 +126,10 @@ Configuration Information
The following configuration options are available for the ARK PMD:
- * **CONFIG_RTE_LIBRTE_ARK_PMD** (default y): Enables or disables inclusion
- of the ARK PMD driver in the DPDK compilation.
-
- * **CONFIG_RTE_LIBRTE_ARK_PAD_TX** (default y): When enabled TX
- packets are padded to 60 bytes to support downstream MACS.
+ * **RTE_LIBRTE_ARK_MIN_TX_PKTLEN** (default 0): Sets the minimum
+ packet length for tx packets to the FPGA. Packets less than this
+ length are padded to meet the requirement. This allows padding to
+ be offloaded or remain in host software.
Building DPDK
@@ -144,6 +143,13 @@ By default the ARK PMD library will be built into the DPDK
library.
For configuring and using UIO and VFIO frameworks, please also refer :ref:`the
documentation that comes with DPDK suite `.
+To build with a non-zero minimum tx packet length, set the above macro in your
+CFLAGS environment prior to the meson build step. I.e.,
+
+export CFLAGS="-DRTE_LIBRTE_ARK_MIN_TX_PKTLEN=60"
+meson build
+
+
Supported ARK RTL PCIe Instances
diff --git a/drivers/net/ark/ark_ethdev_tx.c b/drivers/net/ark/ark_ethdev_tx.c
index 72624deb3..52ce2ed41 100644
--- a/drivers/net/ark/ark_ethdev_tx.c
+++ b/drivers/net/ark/ark_ethdev_tx.c
@@ -14,6 +14,11 @@
#define ARK_TX_META_OFFSET (RTE_PKTMBUF_HEADROOM - ARK_TX_META_SIZE)
#define ARK_TX_MAX_NOCHAIN (RTE_MBUF_DEFAULT_DATAROOM)
+#ifndef RTE_LIBRTE_ARK_MIN_TX_PKTLEN
+#define ARK_MIN_TX_PKTLEN 0
+#else
+#define ARK_MIN_TX_PKTLEN RTE_LIBRTE_ARK_MIN_TX_PKTLEN
+#endif
/* * */
struct ark_tx_queue {
@@ -104,28 +109,28 @@ eth_ark_xmit_pkts(void *vtxq, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts)
++nb) {
mbuf = tx_pkts[nb];
- if (ARK_TX_PAD_TO_60) {
- if (unlikely(rte_pktmbuf_pkt_len(mbuf) < 60)) {
- /* this packet even if it is small can be split,
-* be sure to add to the end mbuf
+#if ARK_MIN_TX_PKTLEN != 0
+ if (unlikely(rte_pktmbuf_pkt_len(mbuf) < ARK_MIN_TX_PKTLEN)) {
+ /* this packet even if it is small can be split,
+* be sure to add to the end mbuf
+*/
+ uint16_t to_add = ARK_MIN_TX_PKTLEN -
+ rte_pktmbuf_pkt_len(mbuf);
+ char *appended =
+ rte_pktmbuf_append(mbuf, to_add);
+
+ if (appended == 0) {
+ /* This packet is in error,
+* we cannot send it so just
+* count it and delete it.
*/
- uint16_t to_add =
- 60 - rte_pktmbuf_pkt_len(mbuf);
- char *appended =
- rte_pktmbuf_append(mbuf, to_add);
-
- if (appended == 0) {
- /* This packet is in error,
-* we cannot send it so just
-* count it and delete it.
-*/
- queue->tx_errors += 1;
- rte_pktmbuf_free(mbuf);
- continue;
- }
- memset(appended, 0, to_add);
+ queue->tx_errors += 1;
+ rte_pktmbuf_free(mbuf);
+ continue;
}
+ memset(appended, 0, to_add);
}
+#endif
if (unlikely(mbuf->nb_segs != 1)) {
stat = eth_ark_tx_jumbo(queue, mbuf);
diff --git a/drivers/net/ark/ark_logs.h b/drivers/net/ark/ark_logs.h
index c3d7e7d39..ca46d86c9 100644
--- a/drivers/net/ark/ark_logs.h
+++ b/drivers/net/ark/ark_logs.h
@@ -8,14 +8,6 @@
#include
#include
-
-/* Configuration option to pad TX packets to 60 bytes */
-#ifdef RTE_LIBRTE_ARK_PAD_TX
-#define ARK_TX_PAD_TO_60 1
-#else
-#define ARK_TX_PAD_TO_60
[dpdk-dev] [PATCH v2 00/17] add max SIMD bitwidth to EAL
v2: - Added some documentation. - Modified default max bitwidth for Arm. - Moved mlx5 condition check into existing check vec support function. - Added max SIMD bitwidth checks to some libraries. A number of components in DPDK have optional AVX-512 or other vector code paths which can be selected at runtime. Rather than having each component provide its own mechanism to select a code path, this patchset adds support for a single setting to control what code paths are used. This can be used to enable some non-default code paths e.g. ones using AVX-512, but also to limit the code paths to certain vector widths, or to scalar code only, which is useful for testing. The max SIMD bitwidth setting can be set by the app itself through use of the available API, or can be overriden by a commandline argument passed by the user. Ciara Power (17): eal: add max SIMD bitwidth eal: add default SIMD bitwidth values doc: add detail on using max SIMD bitwidth net/i40e: add checks for max SIMD bitwidth net/axgbe: add checks for max SIMD bitwidth net/bnxt: add checks for max SIMD bitwidth net/enic: add checks for max SIMD bitwidth net/fm10k: add checks for max SIMD bitwidth net/iavf: add checks for max SIMD bitwidth net/ice: add checks for max SIMD bitwidth net/ixgbe: add checks for max SIMD bitwidth net/mlx5: add checks for max SIMD bitwidth net/virtio: add checks for max SIMD bitwidth distributor: add checks for max SIMD bitwidth member: add checks for max SIMD bitwidth efd: add checks for max SIMD bitwidth net: add checks for max SIMD bitwidth doc/guides/howto/avx512.rst | 36 +++ doc/guides/linux_gsg/eal_args.include.rst | 12 .../prog_guide/env_abstraction_layer.rst | 31 + drivers/net/axgbe/axgbe_rxtx.c| 3 +- drivers/net/bnxt/bnxt_ethdev.c| 6 +- drivers/net/enic/enic_rxtx_vec_avx2.c | 3 +- drivers/net/fm10k/fm10k_ethdev.c | 11 +++- drivers/net/i40e/i40e_rxtx.c | 19 -- drivers/net/iavf/iavf_rxtx.c | 16 +++-- drivers/net/ice/ice_rxtx.c| 20 -- drivers/net/ixgbe/ixgbe_rxtx.c| 7 ++- drivers/net/mlx5/mlx5_rxtx_vec.c | 2 + drivers/net/virtio/virtio_ethdev.c| 12 ++-- lib/librte_distributor/rte_distributor.c | 3 +- lib/librte_eal/arm/include/rte_vect.h | 2 + lib/librte_eal/common/eal_common_options.c| 63 +++ lib/librte_eal/common/eal_internal_cfg.h | 8 +++ lib/librte_eal/common/eal_options.h | 2 + lib/librte_eal/include/generic/rte_vect.h | 2 + lib/librte_eal/include/rte_eal.h | 32 ++ lib/librte_eal/ppc/include/rte_vect.h | 2 + lib/librte_eal/rte_eal_version.map| 4 ++ lib/librte_eal/x86/include/rte_vect.h | 2 + lib/librte_efd/rte_efd.c | 7 ++- lib/librte_member/rte_member_ht.c | 3 +- lib/librte_net/rte_net_crc.c | 8 +++ 26 files changed, 281 insertions(+), 35 deletions(-) create mode 100644 doc/guides/howto/avx512.rst -- 2.17.1
[dpdk-dev] [PATCH v2 01/17] eal: add max SIMD bitwidth
This patch adds a max SIMD bitwidth EAL configuration. The API allows
for an app to set this value. It can also be set using EAL argument
--force-max-simd-bitwidth, which will lock the value and override any
modifications made by the app.
Signed-off-by: Ciara Power
---
v2: Added to Doxygen comment for API.
---
lib/librte_eal/common/eal_common_options.c | 60 ++
lib/librte_eal/common/eal_internal_cfg.h | 8 +++
lib/librte_eal/common/eal_options.h| 2 +
lib/librte_eal/include/rte_eal.h | 32
lib/librte_eal/rte_eal_version.map | 4 ++
5 files changed, 106 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index a5426e1234..90f4e8f5c3 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -102,6 +102,7 @@ eal_long_options[] = {
{OPT_MATCH_ALLOCATIONS, 0, NULL, OPT_MATCH_ALLOCATIONS_NUM},
{OPT_TELEMETRY, 0, NULL, OPT_TELEMETRY_NUM},
{OPT_NO_TELEMETRY, 0, NULL, OPT_NO_TELEMETRY_NUM },
+ {OPT_FORCE_MAX_SIMD_BITWIDTH, 1, NULL, OPT_FORCE_MAX_SIMD_BITWIDTH_NUM},
{0, 0, NULL, 0}
};
@@ -1309,6 +1310,32 @@ eal_parse_iova_mode(const char *name)
return 0;
}
+static int
+eal_parse_simd_bitwidth(const char *arg, bool locked)
+{
+ char *end;
+ uint16_t bitwidth;
+ int ret;
+ struct internal_config *internal_conf =
+ eal_get_internal_configuration();
+
+ if (arg == NULL || arg[0] == '\0')
+ return -1;
+
+ errno = 0;
+ bitwidth = strtoul(arg, &end, 0);
+
+ /* check for errors */
+ if ((errno != 0) || end == NULL || (*end != '\0'))
+ return -1;
+
+ ret = rte_set_max_simd_bitwidth(bitwidth);
+ if (ret < 0)
+ return -1;
+ internal_conf->max_simd_bitwidth.locked = locked;
+ return 0;
+}
+
static int
eal_parse_base_virtaddr(const char *arg)
{
@@ -1707,6 +1734,13 @@ eal_parse_common_option(int opt, const char *optarg,
case OPT_NO_TELEMETRY_NUM:
conf->no_telemetry = 1;
break;
+ case OPT_FORCE_MAX_SIMD_BITWIDTH_NUM:
+ if (eal_parse_simd_bitwidth(optarg, 1) < 0) {
+ RTE_LOG(ERR, EAL, "invalid parameter for --"
+ OPT_FORCE_MAX_SIMD_BITWIDTH "\n");
+ return -1;
+ }
+ break;
/* don't know what to do, leave this to caller */
default:
@@ -1903,6 +1937,31 @@ eal_check_common_options(struct internal_config
*internal_cfg)
return 0;
}
+uint16_t
+rte_get_max_simd_bitwidth(void)
+{
+ const struct internal_config *internal_conf =
+ eal_get_internal_configuration();
+ return internal_conf->max_simd_bitwidth.bitwidth;
+}
+
+int
+rte_set_max_simd_bitwidth(uint16_t bitwidth)
+{
+ struct internal_config *internal_conf =
+ eal_get_internal_configuration();
+ if (internal_conf->max_simd_bitwidth.locked) {
+ RTE_LOG(NOTICE, EAL, "Cannot set max SIMD bitwidth - user
runtime override enabled");
+ return -EPERM;
+ }
+ if (bitwidth < RTE_NO_SIMD || !rte_is_power_of_2(bitwidth)) {
+ RTE_LOG(ERR, EAL, "Invalid bitwidth value!\n");
+ return -EINVAL;
+ }
+ internal_conf->max_simd_bitwidth.bitwidth = bitwidth;
+ return 0;
+}
+
void
eal_common_usage(void)
{
@@ -1981,6 +2040,7 @@ eal_common_usage(void)
" --"OPT_BASE_VIRTADDR" Base virtual address\n"
" --"OPT_TELEMETRY" Enable telemetry support (on by
default)\n"
" --"OPT_NO_TELEMETRY" Disable telemetry support\n"
+ " --"OPT_FORCE_MAX_SIMD_BITWIDTH" Force the max SIMD bitwidth\n"
"\nEAL options for DEBUG use only:\n"
" --"OPT_HUGE_UNLINK" Unlink hugepage files after init\n"
" --"OPT_NO_HUGE" Use malloc instead of hugetlbfs\n"
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index 13f93388a7..367e0cc19e 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -33,6 +33,12 @@ struct hugepage_info {
int lock_descriptor;/**< file descriptor for hugepage dir */
};
+struct simd_bitwidth {
+ /**< flag indicating if bitwidth is locked from further modification */
+ bool locked;
+ uint16_t bitwidth; /**< bitwidth value */
+};
+
/**
* internal configuration
*/
@@ -85,6 +91,8 @@ struct internal_config {
volatile unsigned int init_complete;
/**< indicates whether EAL has completed initialization */
unsigned int no_telemetry; /**< true to disable Telemetry */
+ /**
[dpdk-dev] [PATCH v2 03/17] doc: add detail on using max SIMD bitwidth
This patch adds documentation on the usage of the max SIMD bitwidth EAL
setting, and how to use it to enable AVX-512 at runtime.
Cc: Anatoly Burakov
Cc: John McNamara
Cc: Marko Kovacevic
Signed-off-by: Ciara Power
---
doc/guides/howto/avx512.rst | 36 +++
doc/guides/linux_gsg/eal_args.include.rst | 12 +++
.../prog_guide/env_abstraction_layer.rst | 31
3 files changed, 79 insertions(+)
create mode 100644 doc/guides/howto/avx512.rst
diff --git a/doc/guides/howto/avx512.rst b/doc/guides/howto/avx512.rst
new file mode 100644
index 00..ebae0f2b4f
--- /dev/null
+++ b/doc/guides/howto/avx512.rst
@@ -0,0 +1,36 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2020 Intel Corporation.
+
+
+Using AVX-512 with DPDK
+===
+
+AVX-512 is not used by default in DPDK, but it can be selected at runtime by
apps through the use of EAL API,
+and by the user with a commandline argument. DPDK has a setting for max SIMD
bitwidth,
+which can be modified and will then limit the vector path taken by the code.
+
+
+Using the API in apps
+-
+
+Apps can request DPDK uses AVX-512 at runtime, if it provides improved
application performance.
+This can be done by modifying the EAL setting for max SIMD bitwidth to 512, as
by default it is 256,
+which does not allow for AVX-512.
+
+.. code-block:: c
+
+ rte_set_max_simd_bitwidth(RTE_MAX_512_SIMD);
+
+This API should only be called once at initialization, before EAL init.
+For more information on the possible enum values to use as a parameter, go to
:ref:`max_simd_bitwidth`:
+
+
+Using the command-line argument
+-
+
+The user can select to use AVX-512 at runtime, using the following argument to
set the max bitwidth::
+
+ ./app/dpdk-testpmd --force-max-simd-bitwidth=512
+
+This will override any further changes to the max SIMD bitwidth in DPDK,
+which is useful for testing purposes.
diff --git a/doc/guides/linux_gsg/eal_args.include.rst
b/doc/guides/linux_gsg/eal_args.include.rst
index 0fe4457968..bab3e14e47 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -210,3 +210,15 @@ Other options
*``--no-telemetry``:
Disable telemetry.
+
+*``--force-max-simd-bitwidth=``:
+
+Specify the maximum SIMD bitwidth size to handle. This limits which vector
paths,
+if any, are taken, as any paths taken must use a bitwidth below the max
bitwidth limit.
+For example, to allow all SIMD bitwidths up to and including AVX-512::
+
+--force-max-simd-bitwidth=512
+
+The following example shows limiting the bitwidth to 64-bits to disable
all vector code::
+
+--force-max-simd-bitwidth=64
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst
b/doc/guides/prog_guide/env_abstraction_layer.rst
index f64ae953d1..74f26ed6c9 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -486,6 +486,37 @@ the desired addressing mode when virtual devices that are
not directly attached
To facilitate forcing the IOVA mode to a specific value the EAL command line
option ``--iova-mode`` can
be used to select either physical addressing('pa') or virtual addressing('va').
+.. _max_simd_bitwidth:
+
+
+Max SIMD bitwidth
+~
+
+The EAL provides a single setting to limit the max SIMD bitwidth used by DPDK,
+which is used in determining the vector path, if any, chosen by a component.
+The value can be set at runtime by an application using the
'rte_set_max_simd_bitwidth(uint16_t bitwidth)' function,
+which should only be called once at initialization, before EAL init.
+The value can be overridden by the user using the EAL command-line option
'--force-max-sim-bitwidth'.
+
+When choosing a vector path, along with checking the CPU feature support,
+the value of the max SIMD bitwidth must also be checked, and can be retrieved
using the 'rte_get_max_simd_bitwidth()' function.
+The value should be compared against the enum values for accepted max SIMD
bitwidths:
+
+.. code-block:: c
+
+ enum rte_max_simd_t {
+ RTE_NO_SIMD = 64,
+ RTE_MAX_128_SIMD = 128,
+ RTE_MAX_256_SIMD = 256,
+ RTE_MAX_512_SIMD = 512
+ };
+
+if (rte_get_max_simd_bitwidth() >= RTE_MAX_512_SIMD)
+/* Take AVX-512 vector path */
+else if (rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD)
+/* Take AVX2 vector path */
+
+
Memory Segments and Memory Zones (memzone)
--
--
2.17.1
[dpdk-dev] [PATCH v2 02/17] eal: add default SIMD bitwidth values
Each arch has a define for the default SIMD bitwidth value, this is used
on EAL init to set the config max SIMD bitwidth.
Cc: Ruifeng Wang
Cc: Jerin Jacob
Cc: Honnappa Nagarahalli
Cc: David Christensen
Signed-off-by: Ciara Power
---
v2: Changed default bitwidth for Arm to 128.
---
lib/librte_eal/arm/include/rte_vect.h | 2 ++
lib/librte_eal/common/eal_common_options.c | 3 +++
lib/librte_eal/include/generic/rte_vect.h | 2 ++
lib/librte_eal/ppc/include/rte_vect.h | 2 ++
lib/librte_eal/x86/include/rte_vect.h | 2 ++
5 files changed, 11 insertions(+)
diff --git a/lib/librte_eal/arm/include/rte_vect.h
b/lib/librte_eal/arm/include/rte_vect.h
index 01c51712a1..2cd61d6279 100644
--- a/lib/librte_eal/arm/include/rte_vect.h
+++ b/lib/librte_eal/arm/include/rte_vect.h
@@ -14,6 +14,8 @@
extern "C" {
#endif
+#define RTE_DEFAULT_SIMD_BITWIDTH 128
+
typedef int32x4_t xmm_t;
#defineXMM_SIZE(sizeof(xmm_t))
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 90f4e8f5c3..c2a9624f89 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -35,6 +35,7 @@
#ifndef RTE_EXEC_ENV_WINDOWS
#include
#endif
+#include
#include "eal_internal_cfg.h"
#include "eal_options.h"
@@ -344,6 +345,8 @@ eal_reset_internal_config(struct internal_config
*internal_cfg)
internal_cfg->user_mbuf_pool_ops_name = NULL;
CPU_ZERO(&internal_cfg->ctrl_cpuset);
internal_cfg->init_complete = 0;
+ internal_cfg->max_simd_bitwidth.bitwidth = RTE_DEFAULT_SIMD_BITWIDTH;
+ internal_cfg->max_simd_bitwidth.locked = 0;
}
static int
diff --git a/lib/librte_eal/include/generic/rte_vect.h
b/lib/librte_eal/include/generic/rte_vect.h
index 3fc47979f8..e98f184a97 100644
--- a/lib/librte_eal/include/generic/rte_vect.h
+++ b/lib/librte_eal/include/generic/rte_vect.h
@@ -14,6 +14,8 @@
#include
+#define RTE_DEFAULT_SIMD_BITWIDTH 256
+
/* Unsigned vector types */
/**
diff --git a/lib/librte_eal/ppc/include/rte_vect.h
b/lib/librte_eal/ppc/include/rte_vect.h
index b0545c878c..70fbd0c423 100644
--- a/lib/librte_eal/ppc/include/rte_vect.h
+++ b/lib/librte_eal/ppc/include/rte_vect.h
@@ -15,6 +15,8 @@
extern "C" {
#endif
+#define RTE_DEFAULT_SIMD_BITWIDTH 256
+
typedef vector signed int xmm_t;
#defineXMM_SIZE(sizeof(xmm_t))
diff --git a/lib/librte_eal/x86/include/rte_vect.h
b/lib/librte_eal/x86/include/rte_vect.h
index df5a607623..b1df75aca7 100644
--- a/lib/librte_eal/x86/include/rte_vect.h
+++ b/lib/librte_eal/x86/include/rte_vect.h
@@ -35,6 +35,8 @@
extern "C" {
#endif
+#define RTE_DEFAULT_SIMD_BITWIDTH 256
+
typedef __m128i xmm_t;
#defineXMM_SIZE(sizeof(xmm_t))
--
2.17.1
[dpdk-dev] [PATCH v2 04/17] net/i40e: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path.
Cc: Beilei Xing
Cc: Jeff Guo
Signed-off-by: Ciara Power
---
drivers/net/i40e/i40e_rxtx.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index fe7f9200c1..90f4e26fb8 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -3098,7 +3098,8 @@ static eth_rx_burst_t
i40e_get_latest_rx_vec(bool scatter)
{
#if defined(RTE_ARCH_X86) && defined(CC_AVX2_SUPPORT)
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2))
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD)
return scatter ? i40e_recv_scattered_pkts_vec_avx2 :
i40e_recv_pkts_vec_avx2;
#endif
@@ -3115,7 +3116,8 @@ i40e_get_recommend_rx_vec(bool scatter)
* use of AVX2 version to later plaforms, not all those that could
* theoretically run it.
*/
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F))
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD)
return scatter ? i40e_recv_scattered_pkts_vec_avx2 :
i40e_recv_pkts_vec_avx2;
#endif
@@ -3154,7 +3156,8 @@ i40e_set_rx_function(struct rte_eth_dev *dev)
}
}
- if (ad->rx_vec_allowed) {
+ if (ad->rx_vec_allowed && rte_get_max_simd_bitwidth()
+ >= RTE_MAX_128_SIMD) {
/* Vec Rx path */
PMD_INIT_LOG(DEBUG, "Vector Rx path will be used on port=%d.",
dev->data->port_id);
@@ -3268,7 +3271,8 @@ static eth_tx_burst_t
i40e_get_latest_tx_vec(void)
{
#if defined(RTE_ARCH_X86) && defined(CC_AVX2_SUPPORT)
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2))
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD)
return i40e_xmit_pkts_vec_avx2;
#endif
return i40e_xmit_pkts_vec;
@@ -3283,7 +3287,8 @@ i40e_get_recommend_tx_vec(void)
* use of AVX2 version to later plaforms, not all those that could
* theoretically run it.
*/
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F))
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD)
return i40e_xmit_pkts_vec_avx2;
#endif
return i40e_xmit_pkts_vec;
@@ -3311,7 +3316,9 @@ i40e_set_tx_function(struct rte_eth_dev *dev)
}
if (ad->tx_simple_allowed) {
- if (ad->tx_vec_allowed) {
+ if (ad->tx_vec_allowed &&
+ rte_get_max_simd_bitwidth()
+ >= RTE_MAX_128_SIMD) {
PMD_INIT_LOG(DEBUG, "Vector tx finally be used.");
if (ad->use_latest_vec)
dev->tx_pkt_burst =
--
2.17.1
[dpdk-dev] [PATCH v2 05/17] net/axgbe: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be satisfied to ensure the max SIMD bitwidth allows for the CPU enabled path. Cc: Somalapuram Amaranath Signed-off-by: Ciara Power --- drivers/net/axgbe/axgbe_rxtx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/axgbe/axgbe_rxtx.c b/drivers/net/axgbe/axgbe_rxtx.c index 30c467db71..6200954caa 100644 --- a/drivers/net/axgbe/axgbe_rxtx.c +++ b/drivers/net/axgbe/axgbe_rxtx.c @@ -553,7 +553,8 @@ int axgbe_dev_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx, if (!pdata->tx_queues) pdata->tx_queues = dev->data->tx_queues; - if (txq->vector_disable) + if (txq->vector_disable || rte_get_max_simd_bitwidth() + < RTE_MAX_128_SIMD) dev->tx_pkt_burst = &axgbe_xmit_pkts; else #ifdef RTE_ARCH_X86 -- 2.17.1
[dpdk-dev] [PATCH v2 07/17] net/enic: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path.
Cc: John Daley
Cc: Hyong Youb Kim
Acked-by: Hyong Youb Kim
Signed-off-by: Ciara Power
---
drivers/net/enic/enic_rxtx_vec_avx2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/enic/enic_rxtx_vec_avx2.c
b/drivers/net/enic/enic_rxtx_vec_avx2.c
index 676b9f5fdb..5db43bdbb8 100644
--- a/drivers/net/enic/enic_rxtx_vec_avx2.c
+++ b/drivers/net/enic/enic_rxtx_vec_avx2.c
@@ -821,7 +821,8 @@ enic_use_vector_rx_handler(struct rte_eth_dev *eth_dev)
fconf = ð_dev->data->dev_conf.fdir_conf;
if (fconf->mode != RTE_FDIR_MODE_NONE)
return false;
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2)) {
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD) {
ENICPMD_LOG(DEBUG, " use the non-scatter avx2 Rx handler");
eth_dev->rx_pkt_burst = &enic_noscatter_vec_recv_pkts;
enic->use_noscatter_vec_rx_handler = 1;
--
2.17.1
[dpdk-dev] [PATCH v2 06/17] net/bnxt: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path.
Cc: Ajit Khaparde
Cc: Somnath Kotur
Signed-off-by: Ciara Power
---
drivers/net/bnxt/bnxt_ethdev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 510a0d9e0a..626aae8881 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1100,7 +1100,8 @@ bnxt_receive_function(struct rte_eth_dev *eth_dev)
DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM |
DEV_RX_OFFLOAD_RSS_HASH |
DEV_RX_OFFLOAD_VLAN_FILTER)) &&
- !BNXT_TRUFLOW_EN(bp)) {
+ !BNXT_TRUFLOW_EN(bp) && rte_get_max_simd_bitwidth()
+ >= RTE_MAX_128_SIMD) {
PMD_DRV_LOG(INFO, "Using vector mode receive for port %d\n",
eth_dev->data->port_id);
bp->flags |= BNXT_FLAG_RX_VECTOR_PKT_MODE;
@@ -1132,7 +1133,8 @@ bnxt_transmit_function(__rte_unused struct rte_eth_dev
*eth_dev)
*/
if (!eth_dev->data->scattered_rx &&
!eth_dev->data->dev_conf.txmode.offloads &&
- !BNXT_TRUFLOW_EN(bp)) {
+ !BNXT_TRUFLOW_EN(bp) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_128_SIMD) {
PMD_DRV_LOG(INFO, "Using vector mode transmit for port %d\n",
eth_dev->data->port_id);
return bnxt_xmit_pkts_vec;
--
2.17.1
[dpdk-dev] [PATCH v2 09/17] net/iavf: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path.
Cc: Jingjing Wu
Cc: Beilei Xing
Signed-off-by: Ciara Power
---
drivers/net/iavf/iavf_rxtx.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index 05a7dd898a..b798d082a2 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -2105,14 +2105,16 @@ iavf_set_rx_function(struct rte_eth_dev *dev)
int i;
bool use_avx2 = false;
- if (!iavf_rx_vec_dev_check(dev)) {
+ if (!iavf_rx_vec_dev_check(dev) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_128_SIMD) {
for (i = 0; i < dev->data->nb_rx_queues; i++) {
rxq = dev->data->rx_queues[i];
(void)iavf_rxq_vec_setup(rxq);
}
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) == 1 ||
- rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1)
+ if ((rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) == 1 ||
+ rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD)
use_avx2 = true;
if (dev->data->scattered_rx) {
@@ -2178,7 +2180,8 @@ iavf_set_tx_function(struct rte_eth_dev *dev)
int i;
bool use_avx2 = false;
- if (!iavf_tx_vec_dev_check(dev)) {
+ if (!iavf_tx_vec_dev_check(dev) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_128_SIMD) {
for (i = 0; i < dev->data->nb_tx_queues; i++) {
txq = dev->data->tx_queues[i];
if (!txq)
@@ -2186,8 +2189,9 @@ iavf_set_tx_function(struct rte_eth_dev *dev)
iavf_txq_vec_setup(txq);
}
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) == 1 ||
- rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1)
+ if ((rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) == 1 ||
+ rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1) &&
+ rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD)
use_avx2 = true;
PMD_DRV_LOG(DEBUG, "Using %sVector Tx (port %d).",
--
2.17.1
[dpdk-dev] [PATCH v2 08/17] net/fm10k: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path.
Cc: Qi Zhang
Cc: Xiao Wang
Signed-off-by: Ciara Power
---
drivers/net/fm10k/fm10k_ethdev.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index b574693bca..f7c41d4377 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2937,7 +2937,9 @@ fm10k_set_tx_function(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
/* primary process has set the ftag flag and offloads */
txq = dev->data->tx_queues[0];
- if (fm10k_tx_vec_condition_check(txq)) {
+ if (fm10k_tx_vec_condition_check(txq) ||
+ rte_get_max_simd_bitwidth()
+ < RTE_MAX_128_SIMD) {
dev->tx_pkt_burst = fm10k_xmit_pkts;
dev->tx_pkt_prepare = fm10k_prep_pkts;
PMD_INIT_LOG(DEBUG, "Use regular Tx func");
@@ -2956,7 +2958,8 @@ fm10k_set_tx_function(struct rte_eth_dev *dev)
txq = dev->data->tx_queues[i];
txq->tx_ftag_en = tx_ftag_en;
/* Check if Vector Tx is satisfied */
- if (fm10k_tx_vec_condition_check(txq))
+ if (fm10k_tx_vec_condition_check(txq) ||
+ rte_get_max_simd_bitwidth() < RTE_MAX_128_SIMD)
use_sse = 0;
}
@@ -2990,7 +2993,9 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
* conditions to be met.
*/
if (!fm10k_rx_vec_condition_check(dev) &&
- dev_info->rx_vec_allowed && !rx_ftag_en) {
+ dev_info->rx_vec_allowed && !rx_ftag_en &&
+ rte_get_max_simd_bitwidth()
+ >= RTE_MAX_128_SIMD) {
if (dev->data->scattered_rx)
dev->rx_pkt_burst = fm10k_recv_scattered_pkts_vec;
else
--
2.17.1
[dpdk-dev] [PATCH v2 10/17] net/ice: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path.
Cc: Qiming Yang
Cc: Qi Zhang
Signed-off-by: Ciara Power
---
drivers/net/ice/ice_rxtx.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 2e1f06d2c0..eda2d9a8c7 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -2889,7 +2889,9 @@ ice_set_rx_function(struct rte_eth_dev *dev)
bool use_avx2 = false;
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
- if (!ice_rx_vec_dev_check(dev) && ad->rx_bulk_alloc_allowed) {
+ if (!ice_rx_vec_dev_check(dev) && ad->rx_bulk_alloc_allowed &&
+ rte_get_max_simd_bitwidth()
+ >= RTE_MAX_128_SIMD) {
ad->rx_vec_allowed = true;
for (i = 0; i < dev->data->nb_rx_queues; i++) {
rxq = dev->data->rx_queues[i];
@@ -2899,8 +2901,10 @@ ice_set_rx_function(struct rte_eth_dev *dev)
}
}
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) == 1 ||
- rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1)
+ if ((rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) == 1 ||
+ rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1) &&
+ rte_get_max_simd_bitwidth()
+ >= RTE_MAX_256_SIMD)
use_avx2 = true;
} else {
@@ -3067,7 +3071,9 @@ ice_set_tx_function(struct rte_eth_dev *dev)
bool use_avx2 = false;
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
- if (!ice_tx_vec_dev_check(dev)) {
+ if (!ice_tx_vec_dev_check(dev) &&
+ rte_get_max_simd_bitwidth()
+ >= RTE_MAX_128_SIMD) {
ad->tx_vec_allowed = true;
for (i = 0; i < dev->data->nb_tx_queues; i++) {
txq = dev->data->tx_queues[i];
@@ -3077,8 +3083,10 @@ ice_set_tx_function(struct rte_eth_dev *dev)
}
}
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) == 1 ||
- rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1)
+ if ((rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) == 1 ||
+ rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1) &&
+ rte_get_max_simd_bitwidth()
+ >= RTE_MAX_256_SIMD)
use_avx2 = true;
} else {
--
2.17.1
[dpdk-dev] [PATCH v2 11/17] net/ixgbe: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path.
Cc: Wei Zhao
Cc: Jeff Guo
Signed-off-by: Ciara Power
---
drivers/net/ixgbe/ixgbe_rxtx.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 977ecf5137..eadc7183f2 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -2503,7 +2503,9 @@ ixgbe_set_tx_function(struct rte_eth_dev *dev, struct
ixgbe_tx_queue *txq)
dev->tx_pkt_prepare = NULL;
if (txq->tx_rs_thresh <= RTE_IXGBE_TX_MAX_FREE_BUF_SZ &&
(rte_eal_process_type() != RTE_PROC_PRIMARY ||
- ixgbe_txq_vec_setup(txq) == 0)) {
+ ixgbe_txq_vec_setup(txq) == 0) &&
+ rte_get_max_simd_bitwidth()
+ >= RTE_MAX_128_SIMD) {
PMD_INIT_LOG(DEBUG, "Vector tx enabled.");
dev->tx_pkt_burst = ixgbe_xmit_pkts_vec;
} else
@@ -4743,7 +4745,8 @@ ixgbe_set_rx_function(struct rte_eth_dev *dev)
* conditions to be met and Rx Bulk Allocation should be allowed.
*/
if (ixgbe_rx_vec_dev_conf_condition_check(dev) ||
- !adapter->rx_bulk_alloc_allowed) {
+ !adapter->rx_bulk_alloc_allowed ||
+ rte_get_max_simd_bitwidth() < RTE_MAX_128_SIMD) {
PMD_INIT_LOG(DEBUG, "Port[%d] doesn't meet Vector Rx "
"preconditions",
dev->data->port_id);
--
2.17.1
[dpdk-dev] [PATCH v2 12/17] net/mlx5: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be satisfied to ensure the max SIMD bitwidth allows for the CPU enabled path. Cc: Matan Azrad Cc: Shahaf Shuler Cc: Viacheslav Ovsiienko Signed-off-by: Ciara Power --- v2: Moved check for max bitwidth into existing check vec support function. --- drivers/net/mlx5/mlx5_rxtx_vec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/mlx5/mlx5_rxtx_vec.c b/drivers/net/mlx5/mlx5_rxtx_vec.c index 711dcd35fa..c384c737dc 100644 --- a/drivers/net/mlx5/mlx5_rxtx_vec.c +++ b/drivers/net/mlx5/mlx5_rxtx_vec.c @@ -148,6 +148,8 @@ mlx5_check_vec_rx_support(struct rte_eth_dev *dev) struct mlx5_priv *priv = dev->data->dev_private; uint32_t i; + if (rte_get_max_simd_bitwidth() < RTE_MAX_128_SIMD) + return -ENOTSUP; if (!priv->config.rx_vec_en) return -ENOTSUP; if (mlx5_mprq_enabled(dev)) -- 2.17.1
[dpdk-dev] [PATCH v2 15/17] member: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be satisfied to ensure the max SIMD bitwidth allows for the CPU enabled path. Cc: Yipeng Wang Cc: Sameh Gobriel Signed-off-by: Ciara Power --- lib/librte_member/rte_member_ht.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/librte_member/rte_member_ht.c b/lib/librte_member/rte_member_ht.c index cbcd0d4407..71e3cf7b52 100644 --- a/lib/librte_member/rte_member_ht.c +++ b/lib/librte_member/rte_member_ht.c @@ -113,7 +113,8 @@ rte_member_create_ht(struct rte_member_setsum *ss, } #if defined(RTE_ARCH_X86) if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) && - RTE_MEMBER_BUCKET_ENTRIES == 16) + RTE_MEMBER_BUCKET_ENTRIES == 16 && + rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD) ss->sig_cmp_fn = RTE_MEMBER_COMPARE_AVX2; else #endif -- 2.17.1
[dpdk-dev] [PATCH v2 13/17] net/virtio: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path.
Cc: Maxime Coquelin
Cc: Chenbo Xia
Cc: Zhihong Wang
Signed-off-by: Ciara Power
---
drivers/net/virtio/virtio_ethdev.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index dc0093bdf0..f779ce8396 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1517,9 +1517,11 @@ set_rxtx_funcs(struct rte_eth_dev *eth_dev)
if (vtpci_packed_queue(hw)) {
PMD_INIT_LOG(INFO,
"virtio: using packed ring %s Tx path on port %u",
- hw->use_vec_tx ? "vectorized" : "standard",
+ (hw->use_vec_tx && rte_get_max_simd_bitwidth()
+ > RTE_MAX_256_SIMD) ? "vectorized" : "standard",
eth_dev->data->port_id);
- if (hw->use_vec_tx)
+ if (hw->use_vec_tx && rte_get_max_simd_bitwidth()
+ > RTE_MAX_256_SIMD)
eth_dev->tx_pkt_burst = virtio_xmit_pkts_packed_vec;
else
eth_dev->tx_pkt_burst = virtio_xmit_pkts_packed;
@@ -1536,7 +1538,8 @@ set_rxtx_funcs(struct rte_eth_dev *eth_dev)
}
if (vtpci_packed_queue(hw)) {
- if (hw->use_vec_rx) {
+ if (hw->use_vec_rx && rte_get_max_simd_bitwidth()
+ > RTE_MAX_256_SIMD) {
PMD_INIT_LOG(INFO,
"virtio: using packed ring vectorized Rx path
on port %u",
eth_dev->data->port_id);
@@ -1555,7 +1558,8 @@ set_rxtx_funcs(struct rte_eth_dev *eth_dev)
eth_dev->rx_pkt_burst = &virtio_recv_pkts_packed;
}
} else {
- if (hw->use_vec_rx) {
+ if (hw->use_vec_rx && rte_get_max_simd_bitwidth()
+ >= RTE_MAX_128_SIMD) {
PMD_INIT_LOG(INFO, "virtio: using vectorized Rx path on
port %u",
eth_dev->data->port_id);
eth_dev->rx_pkt_burst = virtio_recv_pkts_vec;
--
2.17.1
[dpdk-dev] [PATCH v2 14/17] distributor: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be satisfied to ensure the max SIMD bitwidth allows for the CPU enabled path. Cc: David Hunt Signed-off-by: Ciara Power --- lib/librte_distributor/rte_distributor.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c index 1c047f065a..9f0a9b1d48 100644 --- a/lib/librte_distributor/rte_distributor.c +++ b/lib/librte_distributor/rte_distributor.c @@ -636,7 +636,8 @@ rte_distributor_create(const char *name, d->dist_match_fn = RTE_DIST_MATCH_SCALAR; #if defined(RTE_ARCH_X86) - d->dist_match_fn = RTE_DIST_MATCH_VECTOR; + if (rte_get_max_simd_bitwidth() >= RTE_MAX_128_SIMD) + d->dist_match_fn = RTE_DIST_MATCH_VECTOR; #endif /* -- 2.17.1
[dpdk-dev] [PATCH v2 17/17] net: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be
satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
path. This check is done just before the handler is called, it cannot
be done when setting the handlers initially as the EAL max simd bitwidth
value has not yet been set.
Cc: Jasvinder Singh
Signed-off-by: Ciara Power
---
lib/librte_net/rte_net_crc.c | 8
1 file changed, 8 insertions(+)
diff --git a/lib/librte_net/rte_net_crc.c b/lib/librte_net/rte_net_crc.c
index 9fd4794a9d..d3d3206919 100644
--- a/lib/librte_net/rte_net_crc.c
+++ b/lib/librte_net/rte_net_crc.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#if defined(RTE_ARCH_X86_64) && defined(RTE_MACHINE_CPUFLAG_PCLMULQDQ)
#define X86_64_SSE42_PCLMULQDQ 1
@@ -60,6 +61,8 @@ static rte_net_crc_handler handlers_neon[] = {
};
#endif
+static uint16_t max_simd_bitwidth;
+
/**
* Reflect the bits about the middle
*
@@ -175,6 +178,11 @@ rte_net_crc_calc(const void *data,
uint32_t ret;
rte_net_crc_handler f_handle;
+ if (max_simd_bitwidth == 0)
+ max_simd_bitwidth = rte_get_max_simd_bitwidth();
+ if (max_simd_bitwidth < RTE_MAX_128_SIMD &&
+ handlers != handlers_scalar)
+ rte_net_crc_set_alg(RTE_NET_CRC_SCALAR);
f_handle = handlers[type];
ret = f_handle(data, data_len);
--
2.17.1
[dpdk-dev] [PATCH v2 16/17] efd: add checks for max SIMD bitwidth
When choosing a vector path to take, an extra condition must be satisfied to ensure the max SIMD bitwidth allows for the CPU enabled path. Cc: Byron Marohn Cc: Yipeng Wang Signed-off-by: Ciara Power --- lib/librte_efd/rte_efd.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c index 6a799556d4..509ecc8256 100644 --- a/lib/librte_efd/rte_efd.c +++ b/lib/librte_efd/rte_efd.c @@ -645,7 +645,9 @@ rte_efd_create(const char *name, uint32_t max_num_rules, uint32_t key_len, * For less than 4 bits, scalar function performs better * than vectorised version */ - if (RTE_EFD_VALUE_NUM_BITS > 3 && rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2)) + if (RTE_EFD_VALUE_NUM_BITS > 3 + && rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2) + && rte_get_max_simd_bitwidth() >= RTE_MAX_256_SIMD) table->lookup_fn = EFD_LOOKUP_AVX2; else #endif @@ -655,7 +657,8 @@ rte_efd_create(const char *name, uint32_t max_num_rules, uint32_t key_len, * than vectorised version */ if (RTE_EFD_VALUE_NUM_BITS > 16 && - rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON)) + rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON) && + rte_get_max_simd_bitwidth() >= RTE_MAX_128_SIMD) table->lookup_fn = EFD_LOOKUP_NEON; else #endif -- 2.17.1
[dpdk-dev] [PATCH] rte_log: make rte_logs private
As announced in earlier releases, rte_logs can now be made
internal to eal_common_log.
Signed-off-by: Stephen Hemminger
---
doc/guides/rel_notes/deprecation.rst | 4
doc/guides/rel_notes/release_20_11.rst | 2 ++
lib/librte_eal/common/eal_common_log.c | 11 ---
lib/librte_eal/include/rte_log.h | 16 ++--
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index 345c38d5b630..5445a4f0a061 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -77,10 +77,6 @@ Deprecation Notices
* eal: The function ``rte_eal_remote_launch`` will return new error codes
after read or write error on the pipe, instead of calling ``rte_panic``.
-* eal: The ``rte_logs`` struct and global symbol will be made private to
- remove it from the externally visible ABI and allow it to be updated in the
- future.
-
* eal: The ``rte_dev_event`` structure will be made private to the EAL as no
public API makes use of it.
diff --git a/doc/guides/rel_notes/release_20_11.rst
b/doc/guides/rel_notes/release_20_11.rst
index df227a1773b8..e422ac790912 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -84,6 +84,8 @@ API Changes
Also, make sure to start the actual text at the margin.
===
+* eal: The ``rte_logs`` struct and global symbol was made private
+ and is no longer part of the API.
ABI Changes
---
diff --git a/lib/librte_eal/common/eal_common_log.c
b/lib/librte_eal/common/eal_common_log.c
index 8835c8fff897..a25766de181a 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -17,11 +17,16 @@
#include "eal_private.h"
-/* global log structure */
-struct rte_logs rte_logs = {
+/** The rte_log structure. */
+static struct rte_logs {
+ uint32_t type; /**< Bitfield with enabled logs. */
+ uint32_t level; /**< Log level. */
+ FILE *file; /**< Output file set by rte_openlog_stream, or NULL. */
+ size_t dynamic_types_len;
+ struct rte_log_dynamic_type *dynamic_types;
+} rte_logs = {
.type = ~0,
.level = RTE_LOG_DEBUG,
- .file = NULL,
};
struct rte_eal_opt_loglevel {
diff --git a/lib/librte_eal/include/rte_log.h b/lib/librte_eal/include/rte_log.h
index eaf66e4f61de..655c3b39c29e 100644
--- a/lib/librte_eal/include/rte_log.h
+++ b/lib/librte_eal/include/rte_log.h
@@ -29,18 +29,6 @@ extern "C" {
struct rte_log_dynamic_type;
-/** The rte_log structure. */
-struct rte_logs {
- uint32_t type; /**< Bitfield with enabled logs. */
- uint32_t level; /**< Log level. */
- FILE *file; /**< Output file set by rte_openlog_stream, or NULL. */
- size_t dynamic_types_len;
- struct rte_log_dynamic_type *dynamic_types;
-};
-
-/** Global log information */
-extern struct rte_logs rte_logs;
-
/* SDK log type */
#define RTE_LOGTYPE_EAL0 /**< Log related to eal. */
#define RTE_LOGTYPE_MALLOC 1 /**< Log related to malloc. */
@@ -274,7 +262,7 @@ void rte_log_dump(FILE *f);
* to rte_openlog_stream().
*
* The level argument determines if the log should be displayed or
- * not, depending on the global rte_logs variable.
+ * not, depending on the loglevel settings.
*
* The preferred alternative is the RTE_LOG() because it adds the
* level and type in the logged string.
@@ -305,7 +293,7 @@ int rte_log(uint32_t level, uint32_t logtype, const char
*format, ...)
* to rte_openlog_stream().
*
* The level argument determines if the log should be displayed or
- * not, depending on the global rte_logs variable. A trailing
+ * not, depending on the loglevel settings. A trailing
* newline may be added if needed.
*
* The preferred alternative is the RTE_LOG() because it adds the
diff --git a/lib/librte_eal/rte_eal_version.map
b/lib/librte_eal/rte_eal_version.map
index 0b18e2ef85f9..6b0dfdd9667c 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -114,7 +114,6 @@ DPDK_21 {
rte_log_set_level;
rte_log_set_level_pattern;
rte_log_set_level_regexp;
- rte_logs;
rte_malloc;
rte_malloc_dump_stats;
rte_malloc_get_socket_stats;
--
2.27.0
[dpdk-dev] [PATCH v3] net/ice: fix FDIR GTPU rule create fail
For GTPU rule without extend header the trainning packet
for FDIR is different. This patch enable these case.
Fixes: 934fd00c9389 ("net/ice/base: fix GTPU IP hash")
Signed-off-by: Wei Zhao
---
v3: fix typo
---
drivers/net/ice/base/ice_fdir.c | 63 +++-
drivers/net/ice/base/ice_type.h | 2 +
drivers/net/ice/ice_fdir_filter.c | 80 +--
3 files changed, 97 insertions(+), 48 deletions(-)
diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
index 2c47fb57b..a904ff513 100644
--- a/drivers/net/ice/base/ice_fdir.c
+++ b/drivers/net/ice/base/ice_fdir.c
@@ -89,6 +89,37 @@ static const u8 ice_fdir_icmp4_gtpu4_pkt[] = {
};
static const u8 ice_fdir_ipv4_gtpu4_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x45, 0x00,
+ 0x00, 0x44, 0x00, 0x00, 0x40, 0x00, 0x40, 0x11,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x08, 0x68, 0x08, 0x68, 0x00, 0x00,
+ 0x00, 0x00, 0x33, 0xff, 0x00, 0x20, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x85, 0x45, 0x00,
+ 0x00, 0x14, 0x00, 0x00, 0x40, 0x00, 0x40, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00,
+};
+
+static const u8 ice_fdir_ipv6_gtpu6_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x86, 0xdd, 0x60, 0x00,
+ 0x00, 0x00, 0x00, 0x44, 0x11, 0x40, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x08, 0x68,
+ 0x08, 0x68, 0x00, 0x44, 0x7f, 0xed, 0x33, 0xff,
+ 0x00, 0x34, 0x12, 0x34, 0x56, 0x78, 0x00, 0x00,
+ 0x00, 0x85, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x3b, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00,
+};
+
+static const u8 ice_fdir_ipv4_gtpu4_eh_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x45, 0x00,
0x00, 0x44, 0x00, 0x00, 0x40, 0x00, 0x40, 0x11,
@@ -102,7 +133,7 @@ static const u8 ice_fdir_ipv4_gtpu4_pkt[] = {
0x00, 0x00,
};
-static const u8 ice_fdir_ipv6_gtpu6_pkt[] = {
+static const u8 ice_fdir_ipv6_gtpu6_eh_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x86, 0xdd, 0x60, 0x00,
0x00, 0x00, 0x00, 0x44, 0x11, 0x40, 0x00, 0x00,
@@ -492,6 +523,20 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
sizeof(ice_fdir_ipv6_gtpu6_pkt),
ice_fdir_ipv6_gtpu6_pkt,
},
+ {
+ ICE_FLTR_PTYPE_NONF_IPV4_GTPU_EH_IPV4_OTHER,
+ sizeof(ice_fdir_ipv4_gtpu4_eh_pkt),
+ ice_fdir_ipv4_gtpu4_eh_pkt,
+ sizeof(ice_fdir_ipv4_gtpu4_eh_pkt),
+ ice_fdir_ipv4_gtpu4_eh_pkt,
+ },
+ {
+ ICE_FLTR_PTYPE_NONF_IPV6_GTPU_EH_IPV6_OTHER,
+ sizeof(ice_fdir_ipv6_gtpu6_eh_pkt),
+ ice_fdir_ipv6_gtpu6_eh_pkt,
+ sizeof(ice_fdir_ipv6_gtpu6_eh_pkt),
+ ice_fdir_ipv6_gtpu6_eh_pkt,
+ },
{
ICE_FLTR_PTYPE_NONF_IPV4_L2TPV3,
sizeof(ice_fdir_ipv4_l2tpv3_pkt), ice_fdir_ipv4_l2tpv3_pkt,
@@ -1053,6 +1098,14 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
case ICE_FLTR_PTYPE_NONF_IPV4_GTPU_IPV4_TCP:
case ICE_FLTR_PTYPE_NONF_IPV4_GTPU_IPV4_ICMP:
case ICE_FLTR_PTYPE_NONF_IPV4_GTPU_IPV4_OTHER:
+ ice_pkt_insert_u32(loc, ICE_IPV4_DST_ADDR_OFFSET,
+ input->ip.v4.src_ip);
+ ice_pkt_insert_u32(loc, ICE_IPV4_SRC_ADDR_OFFSET,
+ input->ip.v4.dst_ip);
+ ice_pkt_insert_u32(loc, ICE_IPV4_GTPU_TEID_OFFSET,
+ input->gtpu_data.teid);
+ break;
+ case ICE_FLTR_PTYPE_NONF_IPV4_GTPU_EH_IPV4_OTHER:
ice_pkt_insert_u32(loc, ICE_IPV4_DST_ADDR_OFFSET,
input->ip.v4.src_ip);
ice_pkt_insert_u32(loc, ICE_IPV4_SRC_ADDR_OFFSET,
@@ -1063,6 +1116,14 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
input->gtpu_data.qfi);
break;
case ICE_FLTR_PTYPE_NONF_IPV6_GTPU_IPV6_OTHER:
+ ice_pkt_insert_ipv6_addr(loc, ICE_IPV6_DST_ADDR_OFFSET,
+input->ip.v6.src_ip);
+ ice_pkt_insert_ipv6_addr(loc, ICE_IPV6_SRC_ADDR_OFFSET,
+input->ip.v6.dst_ip);
+
Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs
> -Original Message- > From: dev On Behalf Of Morten Brørup > Sent: Thursday, August 27, 2020 20:38 > To: Guo, Jia ; Yang, Qiming ; Xing, > Beilei > ; Zhao1, Wei ; Zhang, Qi Z > ; Wu, > Jingjing > Cc: Richardson, Bruce ; dev@dpdk.org; Zhang, > Helin ; > Yigit, Ferruh ; barbe...@kth.se > Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs > > > From: Jeff Guo [mailto:jia@intel.com] > > Sent: Thursday, August 27, 2020 12:10 PM > > > > The limitation of burst size in vector rx was removed, since it should > > retrieve as much received packets as possible. And also the scattered > > receive path should use a wrapper function to achieve the goal of > > burst maximizing. > > > > This patch set aims to maximize vector rx burst for for > > ixgbe/i40e/ice/iavf/fm10k PMDs. > > > > v2->v1: > > 1:add fm10k driver case > > 2:refine some doc > > > > I now noticed that the vector functions also does: > nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP); > > I am not sure about this, but if I read it correctly, calling > rte_eth_rx_burst() with nb_pkts = 33 > (not 32) would only return 32 packets, even if more packets are available. (I > assume that > RTE_I40E_DESCS_PER_LOOP is 32.) In this case, I guess that you need to read > the remaining of the > requested packets using the non-vector function in order to support any > nb_pkts value. > This is vector instruction handling design requirement, like for avx2: #define ICE_DESCS_PER_LOOP_AVX 8, if deep into the real loop handling, you will get the point why doing RTE_ALIGN_FLOOR. ;-) _ice_recv_raw_pkts_vec_avx2: for (i = 0, received = 0; i < nb_pkts; i += ICE_DESCS_PER_LOOP_AVX, rxdp += ICE_DESCS_PER_LOOP_AVX) Maybe it is worth to tell PMD to stop using vector by calling rte_eth_rx_queue_setup with the application burst size it wants. > That is, unless the rte_eth_rx_burst() API is extended with requirements to > nb_pkts, as discussed in > the other thread: > http://inbox.dpdk.org/dev/20200827114117.GD569@bricha3- > MOBL.ger.corp.intel.com/T/#mc8051e9022d6aeb20c51c5a226b2274d3d6d4266 > > > Med venlig hilsen / kind regards > - Morten Brørup > >
[dpdk-dev] [PATCH] net/ice: fix flow validation for unsupported patterns
When loading the OS default package and the pipeline mode is enabled
by the "pipeline-mode-support=1" operation. In this case, the wrong
parser is selected for processing and it will cause the unsupported
patterns(pppoes/pfcp/l2tpv3/esp/ah) to be validated successfully.
This patch corrects the parser selection issue.
Fixes: 47d460d63233 ("net/ice: rework switch filter")
Cc: sta...@dpdk.org
Signed-off-by: Guinan Sun
---
drivers/net/ice/ice_switch_filter.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ice/ice_switch_filter.c
b/drivers/net/ice/ice_switch_filter.c
index c4b00b6a2..884fbaae2 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -1806,7 +1806,8 @@ ice_switch_init(struct ice_adapter *ad)
else
return -EINVAL;
- if (ad->devargs.pipe_mode_support)
+ if (ad->devargs.pipe_mode_support &&
+ ad->active_pkg_type != ICE_PKG_TYPE_OS_DEFAULT)
ret = ice_register_parser(perm_parser, ad);
else
ret = ice_register_parser(dist_parser, ad);
@@ -1824,7 +1825,8 @@ ice_switch_uninit(struct ice_adapter *ad)
else
dist_parser = &ice_switch_dist_parser_os;
- if (ad->devargs.pipe_mode_support)
+ if (ad->devargs.pipe_mode_support &&
+ ad->active_pkg_type != ICE_PKG_TYPE_OS_DEFAULT)
ice_unregister_parser(perm_parser, ad);
else
ice_unregister_parser(dist_parser, ad);
--
2.17.1
Re: [dpdk-dev] 19.11.4 patches review and test
Hi, Luca and Bo
> > - The MD5 is not same between kernel ethtool and dpdk ethtool when
> > testing userspace_ethtool/retrieve_eeprom. It has been fixed on
> > 20.08.patch link: http://patches.dpdk.org/patch/72354/
>
> Shougang and Qi, this patch applies when backported but build fails, as some
> internal structures are different. Do you consider this issue a blocking one
> for
> the release and want to do the work to backport the fixes to 19.11?
>
This patch can't be applied because the solution depends on updating ice shared
code.
I'm not sure the workload and impact of updating shared code. It is a small bug
and it is
not a DPDK main feature. So I think it is not a block issue for release and I
don't suggest
to fix it in 19.11. How do you think of it?
> 01186263c2c7 ("net/ice: fix EEPROM data")
>
> ../drivers/net/ice/ice_ethdev.c: In function ‘ice_get_eeprom_length’:
> ../drivers/net/ice/ice_ethdev.c:3979:16: error: ‘struct ice_nvm_info’
> has no member named ‘flash_size’
> return hw->nvm.flash_size;
Thanks.
Shougang
> -Original Message-
> From: Luca Boccassi
> Sent: Wednesday, August 26, 2020 5:50 PM
> To: Wang, ShougangX ; Burakov, Anatoly
> ; Zhang, Qi Z
> Cc: dev@dpdk.org; sta...@dpdk.org; Chen, BoX C
> Subject: Re: [dpdk-dev] 19.11.4 patches review and test
>
> On Wed, 2020-08-26 at 02:30 +, Chen, BoX C wrote:
> > Hi Luca,
> > Update LTS 19.11.4 test result for Intel part. No new issue is found except
> known issues.
>
> Thank you!
>
> > * Intel(R) Testing
> >
> > # Basic Intel(R) NIC testing
> > * PF(i40e):Passed
> > - Exception message when starting testpmd for testing external
> > memory. It has been fixed on 20.05.patch link:
> > http://patches.dpdk.org/patch/66041/
>
> Anatoly, is it safe to backport this patch to 19.11? It applies and builds
> cleanly
> when cherry-picked:
>
> d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
>
> > * PF(ixgbe):Passed
> > * PF(ice):Passed
> > - The MD5 is not same between kernel ethtool and dpdk ethtool when
> > testing userspace_ethtool/retrieve_eeprom. It has been fixed on
> > 20.08.patch link: http://patches.dpdk.org/patch/72354/
>
> Shougang and Qi, this patch applies when backported but build fails, as some
> internal structures are different. Do you consider this issue a blocking one
> for
> the release and want to do the work to backport the fixes to 19.11?
>
> 01186263c2c7 ("net/ice: fix EEPROM data")
>
> ../drivers/net/ice/ice_ethdev.c: In function ‘ice_get_eeprom_length’:
> ../drivers/net/ice/ice_ethdev.c:3979:16: error: ‘struct ice_nvm_info’
> has no member named ‘flash_size’
> return hw->nvm.flash_size;
>
> > - With latest ice driver and firmware package exception found when port
> reset vf of testpmd. It is also found on latest dpdk version, dev is
> debugging.
> > * VF(i40e):Passed
> > * VF(ixgbe):Passed
> > * VF(ice):Passed
> > * Build or compile: Passed
> > * Intel NIC single core/NIC performance: Passed
> >
> > #Basic cryptodev and virtio testing
> > * vhost/virtio basic loopback, PVP and performance test: Passed.
> > - udp-fragmentation-offload can't be setup on vm Ubuntu1910.it is
> kernel issue, tracked on: https://bugzilla.kernel.org/show_bug.cgi?id=207075
> > - l3fwd-power can wake up lcore but can not sleep again. It is also
> > found
> on 20.08, dev is debugging.
> > * cryptodev Function: Passed.
> > - fips_cryptodev test failed for TDES. It is also found on 20.08,
> > dev is debugging. https://bugs.dpdk.org/show_bug.cgi?id=512
> > * cryptodev Performance: Passed.
> > - known unstable issue of test case 1c1t 3CPM. not effect LTS release.
> >
> > Thanks.
> > Regards,
> > Chen Bo
> >
> > > -Original Message-
> > > From: dev On Behalf Of Luca Boccassi
> > > Sent: August 19, 2020 2:12
> > > To: sta...@dpdk.org
> > > Cc: dev@dpdk.org; Abhishek Marathe
> ;
> > > Akhil Goyal ; Ali Alnubani
> > > ; Walker, Benjamin
> > > ; David Christensen
> > > ; Hemant Agrawal
> ;
> > > Stokes, Ian ; Jerin Jacob
> > > ; Mcnamara, John ;
> > > Ju-Hyoung Lee ; Kevin Traynor
> > > ; Pei Zhang ; Yu, PingX
> > > ; Xu, Qian Q ; Raslan
> > > Darawsheh ; Thomas Monjalon
> > > ; Peng, Yuan ; Chen,
> > > Zhaoyan
> > > Subject: [dpdk-dev] 19.11.4 patches review and test
> > >
> > > Hi all,
> > >
> > > Here is a list of patches targeted for stable release 19.11.4.
> > >
> > > The planned date for the final release is August 31st.
> > >
> > > Please help with testing and validation of your use cases and report
> > > any issues/results with reply-all to this mail. For the final
> > > release the fixes and reported validations will be added to the release
> notes.
> > >
> > > A release candidate tarball can be found at:
> > >
> > > https://dpdk.org/browse/dpdk-stable/tag/?id=v19.11.4-rc1
> > >
> > > These patches are located at branch 19.11 of dpdk-stable repo:
> > > https://dpdk.org/browse/dpdk-stable/
> > >
> > > Thanks.
> > >
> > > Luca Boccassi
> > >
> > > --
[dpdk-dev] [PATCH 1/6] net/bnxt: fix endianness while setting L4 destination port
From: Kalesh AP
Use "req.tunnel_dst_port_val" in bnxt_hwrm_tunnel_dst_port_alloc()
as big endian since hwrm spec mandates this field in network byte order.
Also, fixed the endianness while parsing the command output.
Fixes: 10d074b2022d ("net/bnxt: support tunneling")
Cc: sta...@dpdk.org
Signed-off-by: Kalesh AP
Reviewed-by: Ajit Kumar Khaparde
Reviewed-by: Somnath Kotur
---
drivers/net/bnxt/bnxt_hwrm.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 8296d1d..49d81dd 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -3598,17 +3598,19 @@ int bnxt_hwrm_tunnel_dst_port_alloc(struct bnxt *bp,
uint16_t port,
HWRM_PREP(&req, HWRM_TUNNEL_DST_PORT_ALLOC, BNXT_USE_CHIMP_MB);
req.tunnel_type = tunnel_type;
- req.tunnel_dst_port_val = port;
+ req.tunnel_dst_port_val = rte_cpu_to_be_16(port);
rc = bnxt_hwrm_send_message(bp, &req, sizeof(req), BNXT_USE_CHIMP_MB);
HWRM_CHECK_RESULT();
switch (tunnel_type) {
case HWRM_TUNNEL_DST_PORT_ALLOC_INPUT_TUNNEL_TYPE_VXLAN:
- bp->vxlan_fw_dst_port_id = resp->tunnel_dst_port_id;
+ bp->vxlan_fw_dst_port_id =
+ rte_le_to_cpu_16(resp->tunnel_dst_port_id);
bp->vxlan_port = port;
break;
case HWRM_TUNNEL_DST_PORT_ALLOC_INPUT_TUNNEL_TYPE_GENEVE:
- bp->geneve_fw_dst_port_id = resp->tunnel_dst_port_id;
+ bp->geneve_fw_dst_port_id =
+ rte_le_to_cpu_16(resp->tunnel_dst_port_id);
bp->geneve_port = port;
break;
default:
--
2.10.1
[dpdk-dev] [PATCH 0/6] bnxt bug fixes
From: Kalesh AP This patchset contains bnxt bug fixes. Kalesh AP (5): net/bnxt: fix endianness while setting L4 destination port net/bnxt: fix to initialize structure variable net/bnxt: fix a possible segfault in vector mode Tx path net/bnxt: fix L2 filter alloc net/bnxt: fix speed setting on BCM957508-N2100 adapters Venkat Duvvuru (1): net/bnxt: fix LRO configuration drivers/net/bnxt/bnxt.h | 4 drivers/net/bnxt/bnxt_ethdev.c| 44 +++ drivers/net/bnxt/bnxt_hwrm.c | 15 drivers/net/bnxt/bnxt_ring.c | 1 + drivers/net/bnxt/bnxt_rxr.c | 3 +++ drivers/net/bnxt/bnxt_rxtx_vec_neon.c | 2 ++ drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 2 ++ drivers/net/bnxt/bnxt_txr.c | 2 ++ 8 files changed, 53 insertions(+), 20 deletions(-) -- 2.10.1
[dpdk-dev] [PATCH 5/6] net/bnxt: fix L2 filter alloc
From: Kalesh AP
DPDK does not support RoCE and XDP. The driver should set the
bit 5:4 of the flag to 1 and set bit 6 of the flag in the
HWRM_CFA_L2_FILTER_ALLOC command to disable RoCE and XDP features.
This change will greatly reduce the CFA resource consumption.
Fixes: f92735db1e4c ("net/bnxt: add L2 filter alloc/init/free")
Cc: sta...@dpdk.org
Signed-off-by: Kalesh AP
Reviewed-by: Venkat Duvvuru
Reviewed-by: Somnath Kotur
Reviewed-by: Ajit Kumar Khaparde
---
drivers/net/bnxt/bnxt_hwrm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 4f70d93..32fe24c 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -530,6 +530,9 @@ int bnxt_hwrm_set_l2_filter(struct bnxt *bp,
HWRM_PREP(&req, HWRM_CFA_L2_FILTER_ALLOC, BNXT_USE_CHIMP_MB);
+ /* PMD does not support XDP and RoCE */
+ filter->flags |= HWRM_CFA_L2_FILTER_ALLOC_INPUT_FLAGS_XDP_DISABLE |
+ HWRM_CFA_L2_FILTER_ALLOC_INPUT_FLAGS_TRAFFIC_L2;
req.flags = rte_cpu_to_le_32(filter->flags);
enables = filter->enables |
--
2.10.1
[dpdk-dev] [PATCH 2/6] net/bnxt: fix LRO configuration
From: Venkat Duvvuru
The maximum number of TCP segments that can be aggregated & the
maximum number of aggregations the VNIC supports are configured
incorrectly during LRO configuration.
This patch fixes these values.
Fixes: b150a7e7ee66 ("net/bnxt: support LRO on Thor adapters")
Cc: sta...@dpdk.org
Signed-off-by: Venkat Duvvuru
Reviewed-by: Kalesh Anakkur Purayil
Reviewed-by: Somnath Kotur
---
drivers/net/bnxt/bnxt_hwrm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 49d81dd..4f70d93 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -2242,8 +2242,8 @@ int bnxt_hwrm_vnic_tpa_cfg(struct bnxt *bp,
HWRM_VNIC_TPA_CFG_INPUT_FLAGS_GRO |
HWRM_VNIC_TPA_CFG_INPUT_FLAGS_AGG_WITH_ECN |
HWRM_VNIC_TPA_CFG_INPUT_FLAGS_AGG_WITH_SAME_GRE_SEQ);
- req.max_agg_segs = rte_cpu_to_le_16(BNXT_TPA_MAX_AGGS(bp));
- req.max_aggs = rte_cpu_to_le_16(BNXT_TPA_MAX_SEGS(bp));
+ req.max_aggs = rte_cpu_to_le_16(BNXT_TPA_MAX_AGGS(bp));
+ req.max_agg_segs = rte_cpu_to_le_16(BNXT_TPA_MAX_SEGS(bp));
req.min_agg_len = rte_cpu_to_le_32(512);
}
req.vnic_id = rte_cpu_to_le_16(vnic->fw_vnic_id);
--
2.10.1
[dpdk-dev] [PATCH 6/6] net/bnxt: fix speed setting on BCM957508-N2100 adapters
From: Kalesh AP
On BCM957508-N2100 adapters, FW will not allow any user other
than BMC to shutdown the port. As a result, bnxt_get_hwrm_link_config()
always returns link up.
Because of this, driver will not update the new port configurations
such as speed, autoneg during a port start.
Fixed the condition to invoke bnxt_set_hwrm_link_config() in
bnxt_init_chip().
Fixes: 7bc8e9a227cc ("net/bnxt: support async link notification")
Cc: sta...@dpdk.org
Signed-off-by: Kalesh AP
Reviewed-by: Ajit Kumar Khaparde
---
drivers/net/bnxt/bnxt.h| 4
drivers/net/bnxt/bnxt_ethdev.c | 44 --
2 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index f4b2a3f..a38fe8c 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -81,6 +81,10 @@
#define BROADCOM_DEV_ID_58808 0x16f0
#define BROADCOM_DEV_ID_58802_VF 0xd800
+#define BROADCOM_DEV_957508_N2100 0x5208
+#define IS_BNXT_DEV_957508_N2100(bp) \
+ ((bp)->pdev->id.subsystem_device_id == BROADCOM_DEV_957508_N2100)
+
#define BNXT_MAX_MTU 9574
#define VLAN_TAG_SIZE 4
#define BNXT_NUM_VLANS 2
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 510a0d9..0a038d4 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -605,9 +605,35 @@ static int bnxt_init_ctx_mem(struct bnxt *bp)
return rc;
}
-static int bnxt_init_chip(struct bnxt *bp)
+static int bnxt_update_phy_setting(struct bnxt *bp)
{
struct rte_eth_link new;
+ int rc;
+
+ rc = bnxt_get_hwrm_link_config(bp, &new);
+ if (rc) {
+ PMD_DRV_LOG(ERR, "Failed to get link settings\n");
+ return rc;
+ }
+
+ /*
+* On BCM957508-N2100 adapters, FW will not allow any user other
+* than BMC to shutdown the port. bnxt_get_hwrm_link_config() call
+* always returns link up. Force phy update always in that case.
+*/
+ if (!new.link_status || IS_BNXT_DEV_957508_N2100(bp)) {
+ rc = bnxt_set_hwrm_link_config(bp, true);
+ if (rc) {
+ PMD_DRV_LOG(ERR, "Failed to update PHY settings\n");
+ return rc;
+ }
+ }
+
+ return rc;
+}
+
+static int bnxt_init_chip(struct bnxt *bp)
+{
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(bp->eth_dev);
struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
uint32_t intr_vector = 0;
@@ -737,21 +763,9 @@ static int bnxt_init_chip(struct bnxt *bp)
goto err_free;
#endif
- rc = bnxt_get_hwrm_link_config(bp, &new);
- if (rc) {
- PMD_DRV_LOG(ERR, "HWRM Get link config failure rc: %x\n", rc);
+ rc = bnxt_update_phy_setting(bp);
+ if (rc)
goto err_free;
- }
-
- if (!bp->link_info->link_up) {
- rc = bnxt_set_hwrm_link_config(bp, true);
- if (rc) {
- PMD_DRV_LOG(ERR,
- "HWRM link config failure rc: %x\n", rc);
- goto err_free;
- }
- }
- bnxt_print_link_info(bp->eth_dev);
bp->mark_table = rte_zmalloc("bnxt_mark_table", BNXT_MARK_TABLE_SZ, 0);
if (!bp->mark_table)
--
2.10.1
[dpdk-dev] [PATCH 3/6] net/bnxt: fix to initialize structure variable
From: Kalesh AP
During port start if bnxt_alloc_all_hwrm_stat_ctxs() fails,
in the cleanup path we do see errors like below:
bnxt_hwrm_ring_free(): hwrm_ring_free cp failed. rc:2
bnxt_hwrm_ring_free(): hwrm_ring_free rx failed. rc:2
The reason for this is in bnxt_free_all_hwrm_rings(), the check
is made against "ring->fw_ring_id != INVALID_HW_RING_ID" which
always return true as ring->fw_ring_id is not set to INVALID_HW_RING_ID
while initialising the ring structs.
Fixes: 6eb3cc2294fd ("net/bnxt: add initial Tx code")
Fixes: 2eb53b134aae ("net/bnxt: add initial Rx code")
Cc: sta...@dpdk.org
Signed-off-by: Kalesh AP
Reviewed-by: Lance Richardson
Reviewed-by: Ajit Kumar Khaparde
---
drivers/net/bnxt/bnxt_ring.c | 1 +
drivers/net/bnxt/bnxt_rxr.c | 3 +++
drivers/net/bnxt/bnxt_txr.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/drivers/net/bnxt/bnxt_ring.c b/drivers/net/bnxt/bnxt_ring.c
index 54f6547..8f2296b 100644
--- a/drivers/net/bnxt/bnxt_ring.c
+++ b/drivers/net/bnxt/bnxt_ring.c
@@ -451,6 +451,7 @@ int bnxt_alloc_rxtx_nq_ring(struct bnxt *bp)
ring->ring_mask = ring->ring_size - 1;
ring->vmem_size = 0;
ring->vmem = NULL;
+ ring->fw_ring_id = INVALID_HW_RING_ID;
nqr->cp_ring_struct = ring;
rc = bnxt_alloc_rings(bp, 0, NULL, NULL, nqr, NULL, "l2_nqr");
diff --git a/drivers/net/bnxt/bnxt_rxr.c b/drivers/net/bnxt/bnxt_rxr.c
index 43b1256..b086898 100644
--- a/drivers/net/bnxt/bnxt_rxr.c
+++ b/drivers/net/bnxt/bnxt_rxr.c
@@ -962,6 +962,7 @@ int bnxt_init_rx_ring_struct(struct bnxt_rx_queue *rxq,
unsigned int socket_id)
ring->bd_dma = rxr->rx_desc_mapping;
ring->vmem_size = ring->ring_size * sizeof(struct bnxt_sw_rx_bd);
ring->vmem = (void **)&rxr->rx_buf_ring;
+ ring->fw_ring_id = INVALID_HW_RING_ID;
cpr = rte_zmalloc_socket("bnxt_rx_ring",
sizeof(struct bnxt_cp_ring_info),
@@ -983,6 +984,7 @@ int bnxt_init_rx_ring_struct(struct bnxt_rx_queue *rxq,
unsigned int socket_id)
ring->bd_dma = cpr->cp_desc_mapping;
ring->vmem_size = 0;
ring->vmem = NULL;
+ ring->fw_ring_id = INVALID_HW_RING_ID;
/* Allocate Aggregator rings */
ring = rte_zmalloc_socket("bnxt_rx_ring_struct",
@@ -998,6 +1000,7 @@ int bnxt_init_rx_ring_struct(struct bnxt_rx_queue *rxq,
unsigned int socket_id)
ring->bd_dma = rxr->ag_desc_mapping;
ring->vmem_size = ring->ring_size * sizeof(struct bnxt_sw_rx_bd);
ring->vmem = (void **)&rxr->ag_buf_ring;
+ ring->fw_ring_id = INVALID_HW_RING_ID;
return 0;
}
diff --git a/drivers/net/bnxt/bnxt_txr.c b/drivers/net/bnxt/bnxt_txr.c
index c7a2de6..2068331 100644
--- a/drivers/net/bnxt/bnxt_txr.c
+++ b/drivers/net/bnxt/bnxt_txr.c
@@ -78,6 +78,7 @@ int bnxt_init_tx_ring_struct(struct bnxt_tx_queue *txq,
unsigned int socket_id)
ring->bd_dma = txr->tx_desc_mapping;
ring->vmem_size = ring->ring_size * sizeof(struct bnxt_sw_tx_bd);
ring->vmem = (void **)&txr->tx_buf_ring;
+ ring->fw_ring_id = INVALID_HW_RING_ID;
cpr = rte_zmalloc_socket("bnxt_tx_ring",
sizeof(struct bnxt_cp_ring_info),
@@ -98,6 +99,7 @@ int bnxt_init_tx_ring_struct(struct bnxt_tx_queue *txq,
unsigned int socket_id)
ring->bd_dma = cpr->cp_desc_mapping;
ring->vmem_size = 0;
ring->vmem = NULL;
+ ring->fw_ring_id = INVALID_HW_RING_ID;
return 0;
}
--
2.10.1
[dpdk-dev] [PATCH 4/6] net/bnxt: fix a possible segfault in vector mode Tx path
From: Kalesh AP
rte_pktmbuf_prefree_seg() can return NULL if the mbuf still
has remaining references on it.
Adding a NULL check to prevent segfault.
Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")
Cc: sta...@dpdk.org
Signed-off-by: Kalesh AP
Reviewed-by: Lance Richardson
Reviewed-by: Ajit Kumar Khaparde
Reviewed-by: Somnath Kotur
---
drivers/net/bnxt/bnxt_rxtx_vec_neon.c | 2 ++
drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
b/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
index 488a0b4..bf76c2a 100644
--- a/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
+++ b/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
@@ -329,6 +329,8 @@ bnxt_tx_cmp_vec(struct bnxt_tx_queue *txq, int nr_pkts)
tx_buf = &txr->tx_buf_ring[cons];
cons = RING_NEXT(txr->tx_ring_struct, cons);
mbuf = rte_pktmbuf_prefree_seg(tx_buf->mbuf);
+ if (unlikely(mbuf == NULL))
+ continue;
tx_buf->mbuf = NULL;
if (blk && mbuf->pool != free[0]->pool) {
diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
index c4ca5cf..98220bc 100644
--- a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
+++ b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
@@ -334,6 +334,8 @@ bnxt_tx_cmp_vec(struct bnxt_tx_queue *txq, int nr_pkts)
tx_buf = &txr->tx_buf_ring[cons];
cons = RING_NEXT(txr->tx_ring_struct, cons);
mbuf = rte_pktmbuf_prefree_seg(tx_buf->mbuf);
+ if (unlikely(mbuf == NULL))
+ continue;
tx_buf->mbuf = NULL;
if (blk && mbuf->pool != free[0]->pool) {
--
2.10.1
Re: [dpdk-dev] [PATCH] i40e: fix segfault when using custom RSS key
> -Original Message-
> From: dev On Behalf Of Elena Carasec
> Sent: Wednesday, August 26, 2020 7:28 PM
> To: dev@dpdk.org
> Cc: Elena Carasec ; sta...@dpdk.org; Xing, Beilei
> ; Zhang, Qi Z ; Adrien
> Mazarguil ; Andrew Rybchenko
> ; Luca Boccassi ; Jan
> Viktorin
> Subject: [dpdk-dev] [PATCH] i40e: fix segfault when using custom RSS key
>
> &out->conf and in can point to the same memory area. Reinitialization of
> out->conf leads to setting in->key to NULL, but leaves key_len 40. This
> leads to segfault on destruction of the RSS flow action. The segfault happens
> inside i40e_action_rss_same(), when comparing comp->key and
> with->key, because both comp->key_len and with->key_len are 40 (should
> be 0).
>
> Reproduction steps (testpmd):
>
> port stop 0
> flow create 0 ingress pattern end actions rss func default level 0\
> key
> 6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5a6d5
> a6d5a6d5a6d5a6d5a\
> key_len 40 queues 0 end / end
> port start 0
> set link-up port 0
> start
> stop
> set link-down port 0
> port stop 0
> flow destroy 0 rule 0
> (Segmentation fault)
Hi,
Thanks for the fix.
But according to Chenxu and Shougang's test, this issue doesn't exist after
DPDK 20.05,
where RSS configuration has been refactored.
Could you please retry with the latest DPDK?
BR,
Beilei
>
> Fixes: ac8d22de2394 ("ethdev: flatten RSS configuration in flow API")
>
> Signed-off-by: Elena Carasec
> Signed-off-by: Jan Viktorin
> ---
> drivers/net/i40e/i40e_ethdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 11c02b1..a5fe130 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -13211,6 +13211,8 @@ struct i40e_customized_pctype*
> return -EINVAL;
> if (!in->key && in->key_len)
> return -EINVAL;
> + if (&out->conf == in)
> + return 0;
> out->conf = (struct rte_flow_action_rss){
> .func = in->func,
> .level = in->level,
> --
> 1.8.3.1
Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs
On 8/28/2020 10:06 AM, Wang, Haiyue wrote: -Original Message- From: dev On Behalf Of Morten Brørup Sent: Thursday, August 27, 2020 20:38 To: Guo, Jia ; Yang, Qiming ; Xing, Beilei ; Zhao1, Wei ; Zhang, Qi Z ; Wu, Jingjing Cc: Richardson, Bruce ; dev@dpdk.org; Zhang, Helin ; Yigit, Ferruh ; barbe...@kth.se Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs From: Jeff Guo [mailto:jia@intel.com] Sent: Thursday, August 27, 2020 12:10 PM The limitation of burst size in vector rx was removed, since it should retrieve as much received packets as possible. And also the scattered receive path should use a wrapper function to achieve the goal of burst maximizing. This patch set aims to maximize vector rx burst for for ixgbe/i40e/ice/iavf/fm10k PMDs. v2->v1: 1:add fm10k driver case 2:refine some doc I now noticed that the vector functions also does: nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP); I am not sure about this, but if I read it correctly, calling rte_eth_rx_burst() with nb_pkts = 33 (not 32) would only return 32 packets, even if more packets are available. (I assume that RTE_I40E_DESCS_PER_LOOP is 32.) In this case, I guess that you need to read the remaining of the requested packets using the non-vector function in order to support any nb_pkts value. This is vector instruction handling design requirement, like for avx2: #define ICE_DESCS_PER_LOOP_AVX 8, if deep into the real loop handling, you will get the point why doing RTE_ALIGN_FLOOR. ;-) _ice_recv_raw_pkts_vec_avx2: for (i = 0, received = 0; i < nb_pkts; i += ICE_DESCS_PER_LOOP_AVX, rxdp += ICE_DESCS_PER_LOOP_AVX) Maybe it is worth to tell PMD to stop using vector by calling rte_eth_rx_queue_setup with the application burst size it wants. That is, unless the rte_eth_rx_burst() API is extended with requirements to nb_pkts, as discussed in the other thread: http://inbox.dpdk.org/dev/20200827114117.GD569@bricha3- MOBL.ger.corp.intel.com/T/#mc8051e9022d6aeb20c51c5a226b2274d3d6d4266 Agree with above haiyue said, and go through the discuss on the thread, i think vector path was born definitely for the spirit of dpdk, each driver could keep the performance base on the instinct requirement and define what is the specific "max", the path option could give to app, it could static choose one when set up queue or dynamic but not the driver scope, document could be add to AVI if need for benefit user. Med venlig hilsen / kind regards - Morten Brørup
