Re: [dpdk-dev] [PATCH 00/17] net/fm10k: update base code.
On 3/3/2017 3:17 AM, Qi Zhang wrote: > The patch set update to latest fm10k base code, there is no > significent features be added, but include couple enhancement > like clean up the logic for tlv attr parse, improve VF multi-bit > VLAN handle etc, also with some code/comment clean as well. > > Qi Zhang (17): > net/fm10k/base: add a flag to indicate VF trust mode > net/fm10k/base: reset multicaset mode when deleting lport > net/fm10k/base: expose macros needed by DPDK > net/fm10k/base: add error code > net/fm10k/base: clean up the logic > net/fm10k/base: add new item to lport msg attr > net/fm10k/base: use 8 bit notation instead of 10bit notation > net/fm10k/base: use different name for override bit > net/fm10k/base: update comment regarding reserved bits check > net/fm10k/base: improve VF's multi-bit VLAN update requests > net/fm10k/base: enable lport map request > net/fm10k/base: add macros for global interrupt > net/fm10k/base: don't stop reset > net/fm10k/base: add marcro for geneve tunnel > net/fm10k/base: improve re-map queues handle > net/fm10k/base: replace marcos > net/fm10k/base: equest reset when mbx->state changes Hi Qi, Is there a base code version to record for fm10k, as done in some other drivers? Thanks, ferruh
Re: [dpdk-dev] [PATCH 03/17] net/fm10k/base: expose macros needed by DPDK
On 3/3/2017 3:17 AM, Qi Zhang wrote: > Some defines were previously wrapped to strip them from opensource driver > builds, but these are required by DPDK. Change the wrapping of these so > that the DPDK gets them as long as DPDK_SUPPORT is correctly added as a > strip flag, while we can remove the reduandant ones in fm10k_osdep.h. s/reduandant/redundant > > Signed-off-by: Qi Zhang <...> > diff --git a/drivers/net/fm10k/base/fm10k_type.h > b/drivers/net/fm10k/base/fm10k_type.h > index fe3e498..8ddfd49 100644 > --- a/drivers/net/fm10k/base/fm10k_type.h > +++ b/drivers/net/fm10k/base/fm10k_type.h > @@ -40,6 +40,9 @@ struct fm10k_hw; > #include "fm10k_osdep.h" > #include "fm10k_mbx.h" > > +#if !defined(EXTERNAL_RELEASE) || defined(DPDK_SUPPORT) >From commit log what I understand is, released code is coming from a shared code by some #ifdefs stripped based on a strip flag configuration. If that is the case, these #ifdefs should not be released code, they should be stripped but only #defines should remain, is this correct? > +#define FM10K_INTEL_VENDOR_ID0x8086 > +#endif > #define FM10K_DEV_ID_PF 0x15A4 > #define FM10K_DEV_ID_VF 0x15A5 > #ifdef BOULDER_RAPIDS_HW <...>
Re: [dpdk-dev] [PATCH 02/17] net/fm10k/base: reset multicaset mode when deleting lport
On 3/3/2017 3:17 AM, Qi Zhang wrote: patch title: s/multicaset/multicast > Deleting lport when multicast mod is configured to > FM10K_XCAST_MODE_ALLMULTI or FM10K_XCAST_MODE_PROMISC will > result in generating orphaned multicast-group entries in the > switch manager. > Before deleting the lport, reset multicast mode to > FM10K_XCAST_MODE_NONE to flush out these multicast-group > entries. > > Signed-off-by: Qi Zhang <...>
Re: [dpdk-dev] [PATCH 07/17] net/fm10k/base: use 8 bit notation instead of 10bit notation
On 3/3/2017 3:17 AM, Qi Zhang wrote: > The diagram represents bit layout of the multi-bit VLAN update > message format. Re-draw the numbers using base 8, and mark the > bit values every 8 bits at the top. This should make it more > easy to grasp the table quickly. Can you please somehow mention in the patch title that this is a comment update. > > Signed-off-by: Qi Zhang <...>
Re: [dpdk-dev] [PATCH 10/17] net/fm10k/base: improve VF's multi-bit VLAN update requests
On 3/3/2017 3:17 AM, Qi Zhang wrote: > The VF uses a multi-bit update request to clear unused VLANs whenever it > resets. However, an accident in a previous refector broke multi-bit s/refector/refactor > updates for VFs, due to misreading a comment in fm10k_vf.c and > attempting to reduce code duplication. The problem occurs because > a multi-bit request has a non-zero length, and the PF would simply drop > any request with the upper 16 bits set. In addition, a multi-bit vlan > update does not have a concept for "VLAN 0" as the single bit update > does. > > A previous revision of this patch resolved the issue by simply removing > the upper 16 bit check and the iov_select_vid checks. However, this would > remove the checks for default VID and for ensuring no other VLANs can be > enabled except pf_vid when it has been set. To resolve that issue, this > revision uses the iov_select_vid when we have a single-bit update, and > denies any multi-bit update when the VLAN was administratively set by > the PF. This should be ok since the PF properly updates VLAN_TABLE when > it assigns the PF vid. This ensures that requests to add or "remove" the > PF vid work as expected, but a rogue VF could not use the multi-bit > update as a loophole to attempt receiving traffic on other VLANs. > > Signed-off-by: Qi Zhang <...>
Re: [dpdk-dev] [PATCH 17/17] net/fm10k/base: equest reset when mbx->state changes
On 3/3/2017 3:17 AM, Qi Zhang wrote: patch title: s/equest/request > Multiple IES API resets can cause a race condition where the mailbox > interrupt request bits can be cleared before being handled. This can > leave certain mailbox messages from the PF to be untreated and the PF > will enter in some inactive state. If this situation occurs, the IES API > will initiate a mailbox version reset which, then, trigger a mailbox > state change. Once this mailbox transition occurs (from OPEN to CONNECT > state), a request for reset will be returned. > > Signed-off-by: Qi Zhang <...>
[dpdk-dev] [PATCH] net/mlx5: fix extended statistics counters identification
Checking whether the counter is IB counter was performed with the
wrong index.
Fixes: a4e3056b7018 ("net/mlx5: add out of buffer counter to extended
statistic")
Cc: sta...@dpdk.org
Signed-off-by: Shahaf Shuler
---
drivers/net/mlx5/mlx5_stats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_stats.c b/drivers/net/mlx5/mlx5_stats.c
index 1953293..703f48c 100644
--- a/drivers/net/mlx5/mlx5_stats.c
+++ b/drivers/net/mlx5/mlx5_stats.c
@@ -253,7 +253,7 @@ struct mlx5_counter_ctrl {
}
}
for (j = 0; j != xstats_n; ++j) {
- if (priv_is_ib_cntr(mlx5_counters_init[i].ctr_name))
+ if (priv_is_ib_cntr(mlx5_counters_init[j].ctr_name))
continue;
if (xstats_ctrl->dev_table_idx[j] >= dev_stats_n) {
WARN("counter \"%s\" is not recognized",
--
1.8.3.1
Re: [dpdk-dev] [PATCH v2 0/5] consistent PMD batching behaviour
> The rte_eth_tx_burst() function in the file Rte_ethdev.h is invoked to > transmit output packets on the output queue for DPDK applications as > follows. > > static inline uint16_t > rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id, > struct rte_mbuf **tx_pkts, uint16_t nb_pkts); > > Note: The fourth parameter nb_pkts: The number of packets to transmit. > > The rte_eth_tx_burst() function returns the number of packets it actually > sent. Most of PMD drivers can support the policy "send as many packets to > transmit as possible" at the PMD level. but the few of PMDs have some sort > of artificial limits for the pkts sent successfully. For example, VHOST tx > burst size is limited to 32 packets. Some rx_burst functions have the > similar problem. The main benefit is consistent batching behavior for user > to simplify their logic and avoid misusage at the application level, there > is unified rte_eth_tx/rx_burst interface already, there is no reason for > inconsistent behaviors. > This patchset fixes it via adding wrapper function at the PMD level. > > Changes in V2: > 1. rename ixgbe, i40e and fm10k vec function XXX_xmit_pkts_vec to new name > XXX_xmit_fixed_burst_vec, new wrapper functions use original name > XXX_xmit_pkts_vec according to Bruce's suggestion. > > 2. simplify the code to avoid the if or if/else. > > Zhiyong Yang (5): > net/fm10k: remove limit of fm10k_xmit_pkts_vec burst size > net/i40e: remove limit of i40e_xmit_pkts_vec burst size > net/ixgbe: remove limit of ixgbe_xmit_pkts_vec burst size > net/vhost: remove limit of vhost TX burst size > net/vhost: remove limit of vhost RX burst size > > drivers/net/fm10k/fm10k.h | 4 ++-- > drivers/net/fm10k/fm10k_ethdev.c| 28 --- > drivers/net/fm10k/fm10k_rxtx_vec.c | 4 ++-- > drivers/net/i40e/i40e_rxtx.c| 28 --- > drivers/net/i40e/i40e_rxtx.h| 4 ++-- > drivers/net/i40e/i40e_rxtx_vec_neon.c | 4 ++-- > drivers/net/i40e/i40e_rxtx_vec_sse.c| 4 ++-- > drivers/net/ixgbe/ixgbe_rxtx.c | 29 > drivers/net/ixgbe/ixgbe_rxtx.h | 4 ++-- > drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 4 ++-- > drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 4 ++-- > drivers/net/vhost/rte_eth_vhost.c | 34 > + > 12 files changed, 125 insertions(+), 26 deletions(-) > Acked-by: Konstantin Ananyev > -- > 2.7.4
Re: [dpdk-dev] [RFC 17.05 v1 0/3] Merge l3fwd-acl and l3fwd
Hi Ravi,
>
> Hi Konstantin,
>
> Sorry for this one, I had to resend patch series as 'v3' as additional
> checkpatch warnings were seen after the submission which didn't show
> up in my run.
>
> 'v3' patch should have all fixed except the ones I mentioned in my earlier
> email on which I need inputs from you.
>
> Thanks.
>
> On Sat, Mar 4, 2017 at 11:49 AM, Ravi Kerur wrote:
> Hi Konstantin,
>
> I have sent 'v2' patchset. I need clarifications on following things, if they
> should be fixed I will send out 'v3' so please let me know.
>
> Following code changes were done by me manually, not merged.
> +++ b/examples/l3fwd/main.c
> @@ -161,7 +163,9 @@ static struct rte_eth_conf port_conf = {
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = NULL,
> - .rss_hf = ETH_RSS_IP,
> + .rss_hf = ETH_RSS_IP | ETH_RSS_UDP |
> + ETH_RSS_TCP | ETH_RSS_SCTP,
> +
> },
>
> The reason I did it is because
>
> LPM/EM has .rss_hf = ETH_RSS_IP
> ACL has .rss_hf = ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP | ETH_RSS_SCTP,
>
> ACL looks like a superset of LPM/EM and functional testing didn't reveal any
> issues hence I kept ACL version.
But at least for LPM, we probably don't want L4 ports affect packet
distribution?
Probably the safest way would be to have a separate port_conf for each case
(LPM/EM/ACL).
That way will preserve the original behavior.
>
> 2. Checkpatch errors are all fixed. Some warnings are not fixed and they are
>
> 2.a, string length greater than 80 characters
> 2.b GET_CB_FIELD macro. I could have changed GET_CB_FIELD to inline function,
> however, function names cannot be in capital letters. I
> could have changed it to 'get_cb_field' inline function, but didn't do it as
> I thought it may not be worth the change.
It is ok by me to leave as it is by now.
Thanks
Konstantin
Re: [dpdk-dev] [PATCH] net/i40e: fix incorrect packet index reference
On 4 March 2017 at 13:00, Jerin Jacob wrote:
> Fixes: ae0eb310f253 ("net/i40e: implement vector PMD for ARM")
>
> CC: sta...@dpdk.org
> Signed-off-by: Jerin Jacob
> Signed-off-by: Sunil Kulkarni
> ---
> drivers/net/i40e/i40e_rxtx_vec_neon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx_vec_neon.c
> b/drivers/net/i40e/i40e_rxtx_vec_neon.c
> index 011c54e..d235daa 100644
> --- a/drivers/net/i40e/i40e_rxtx_vec_neon.c
> +++ b/drivers/net/i40e/i40e_rxtx_vec_neon.c
> @@ -205,7 +205,7 @@ desc_to_ptype_v(uint64x2_t descs[4], struct rte_mbuf
> **rx_pkts)
> for (i = 0; i < 4; i++) {
> tmp = vreinterpretq_u8_u64(vshrq_n_u64(descs[i], 30));
> ptype = vgetq_lane_u8(tmp, 8);
> - rx_pkts[0]->packet_type = i40e_rxd_pkt_type_mapping(ptype);
> + rx_pkts[i]->packet_type = i40e_rxd_pkt_type_mapping(ptype);
> }
>
> }
Acked-by: Jianbo Liu
[dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd
This patchset merges l3fwd-acl and l3fwd code into common directory. Adds file read options to build LPM and EM tables. Ravi Kerur (3): Merge l3fwd-acl and l3fwd code. LPM config file read option. EM config file read option. examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 92 ++ examples/l3fwd/l3fwd_acl.c| 1033 ++ examples/l3fwd/l3fwd_acl.h| 234 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 390 +-- examples/l3fwd/l3fwd_lpm.c| 323 -- examples/l3fwd/main.c | 232 +++-- 10 files changed, 2283 insertions(+), 2340 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h -- 2.7.4
[dpdk-dev] [v4 2/3] LPM config file read option.
v4:
> No changes.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings related to code
> MACRO GET_CB_FIELD checkpatch warning not fixed
v1:
> Remove static array configuration of Destination IP, MASK
and IF_OUT for LPM and LPM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#LPM route entries Dest-IP/Mask IF_OUT
L1.1.1.0/24 0
L2.1.1.0/24 1
L3.1.1.0/24 2
...
#LPM6 route entries Dest-IP/Mask IF_OUT
L:::::::/48 0
L2111:::::::/48 1
L3111:::::::/48 2
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd.h | 43 +++
examples/l3fwd/l3fwd_acl.c | 39 +-
examples/l3fwd/l3fwd_acl.h | 29 -
examples/l3fwd/l3fwd_lpm.c | 308 +
examples/l3fwd/main.c | 29 -
5 files changed, 329 insertions(+), 119 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 93e08f6..4b1cdc8 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -94,6 +94,47 @@
#define ACL_LEAD_CHAR ('@')
#define ROUTE_LEAD_CHAR('R')
#define COMMENT_LEAD_CHAR ('#')
+#define LPM_LEAD_CHAR ('L')
+#define EM_LEAD_CHAR ('E')
+
+#defineIPV6_ADDR_LEN 16
+#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
+#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
+
+#define GET_CB_FIELD(in, fd, base, lim, dlm) do {\
+ unsigned long val; \
+ char *end; \
+ errno = 0; \
+ val = strtoul((in), &end, (base)); \
+ if (errno != 0 || end[0] != (dlm) || val > (lim)) \
+ return -EINVAL; \
+ (fd) = (typeof(fd))val; \
+ (in) = end + 1; \
+} while (0)
+
+/* Bypass comment and empty lines */
+static inline int
+is_bypass_line(char *buff)
+{
+ int i = 0;
+
+ /* comment line */
+ if (buff[0] == COMMENT_LEAD_CHAR)
+ return 1;
+ /* empty line */
+ while (buff[i] != '\0') {
+ if (!isspace(buff[i]))
+ return 0;
+ i++;
+ }
+ return 1;
+}
+
+struct parm_cfg {
+ const char *rule_ipv4_name;
+ const char *rule_ipv6_name;
+ int scalar;
+};
struct mbuf_table {
uint16_t len;
@@ -134,6 +175,8 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct parm_cfg parm_config;
+
extern int numa_on; /**< NUMA is enabled by default. */
/* Send burst of packets on an output interface */
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 388b978..66ed23d 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -147,10 +147,6 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
},
};
-#defineIPV6_ADDR_LEN 16
-#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
-#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
-
enum {
PROTO_FIELD_IPV6,
SRC1_FIELD_IPV6,
@@ -297,12 +293,6 @@ static struct {
const char cb_port_delim[] = ":";
-static struct {
- const char *rule_ipv4_name;
- const char *rule_ipv6_name;
- int scalar;
-} parm_config;
-
/*
* Print and dump ACL/Route rules functions are defined in
* following header file.
@@ -316,27 +306,6 @@ static struct {
#include "l3fwd_acl_scalar.h"
/*
- * API's called during initialization to setup ACL rules.
- */
-void
-l3fwd_acl_set_rule_ipv4_name(const char *optarg)
-{
- parm_config.rule_ipv4_name = optarg;
-}
-
-void
-l3fwd_acl_set_rule_ipv6_name(const char *optarg)
-{
- parm_config.rule_ipv6_name = optarg;
-}
-
-void
-l3fwd_acl_set_scalar(void)
-{
- parm_config.scalar = 1;
-}
-
-/*
* Parses IPV6 address, exepcts the following format:
* ::::::: (where X - is a hexedecimal digit).
*/
@@ -566,7 +535,7 @@ parse_cb_ipv4vlan_rule(char *str, struct rte_acl_rule *v,
int has_userdata)
}
static int
-add_rules(const char *rule_path,
+acl_add_rules(const char *rule_path,
struct rte_acl_rule **proute_base,
unsigned int *proute_num,
struct rte_acl_rule **pacl_base,
@@ -764,8 +733,8 @@ setup_acl(const int socket_id __attribute__((unused)))
dump_acl_config();
- /* Load rules from the input file */
- if (a
[dpdk-dev] [v4 3/3] EM config file read option.
v4:
> No changes.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings.
v1:
> Remove static array configuration of Dest IP,Src IP, Dest
port, Src port, Proto and IF_OUT for EM and EM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#EM route entries,
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
E101.0.0.0 100.10.0.0 101 11 0x06 0
E201.0.0.0 200.20.0.0 102 12 0x06 1
E111.0.0.0 211.30.0.0 101 11 0x06 2
...
#EM6 route entries
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
Efe80::::021e:67ff:fe00:
fe80::::021b:21ff:fe91:3805 101 11 0x06 0
Efe90::::021e:67ff:fe00:
fe90::::021b:21ff:fe91:3805 102 12 0x06 1
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd_em.c | 376 +-
1 file changed, 303 insertions(+), 73 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 6fdabf7..cd6b443 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -95,8 +95,14 @@ union ipv4_5tuple_host {
#define XMM_NUM_IN_IPV6_5TUPLE 3
struct ipv6_5tuple {
- uint8_t ip_dst[IPV6_ADDR_LEN];
- uint8_t ip_src[IPV6_ADDR_LEN];
+ union {
+ uint8_t ip_dst[IPV6_ADDR_LEN];
+ uint32_t ip32_dst[4];
+ };
+ union {
+ uint8_t ip_src[IPV6_ADDR_LEN];
+ uint32_t ip32_src[4];
+ };
uint16_t port_dst;
uint16_t port_src;
uint8_t proto;
@@ -116,47 +122,24 @@ union ipv6_5tuple_host {
xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
};
-
-
-struct ipv4_l3fwd_em_route {
- struct ipv4_5tuple key;
- uint8_t if_out;
+enum {
+ CB_FLD_DST_ADDR,
+ CB_FLD_SRC_ADDR,
+ CB_FLD_DST_PORT,
+ CB_FLD_SRC_PORT,
+ CB_FLD_PROTO,
+ CB_FLD_IF_OUT,
+ CB_FLD_MAX
};
-struct ipv6_l3fwd_em_route {
- struct ipv6_5tuple key;
+struct em_rule {
+ union {
+ struct ipv4_5tuple v4_key;
+ struct ipv6_5tuple v6_key;
+ };
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{IPv4(101, 0, 0, 0), IPv4(100, 10, 0, 1), 101, 11, IPPROTO_TCP}, 0},
- {{IPv4(201, 0, 0, 0), IPv4(200, 20, 0, 1), 102, 12, IPPROTO_TCP}, 1},
- {{IPv4(111, 0, 0, 0), IPv4(100, 30, 0, 1), 101, 11, IPPROTO_TCP}, 2},
- {{IPv4(211, 0, 0, 0), IPv4(200, 40, 0, 1), 102, 12, IPPROTO_TCP}, 3},
-};
-
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
-};
-
struct rte_hash *ipv4_l3fwd_em_lookup_struct[NB_SOCKETS];
struct rte_hash *ipv6_l3fwd_em_lookup_struct[NB_SOCKETS];
@@ -233,12 +216,6 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t
data_len,
return init_val;
}
-#define IPV4_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv4_l3fwd_em_route_array) /
sizeof(ipv4_l3fwd_em_route_array[0]))
-
-#define IPV6_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv6_l3fwd_em_route_array) /
sizeof(ipv6_l3fwd_em_route_array[0]))
-
static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
@@ -338,6 +315,224 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid,
void *lookup_struct)
#include "l3fwd_em.h"
#endif
+static int
+em_parse_v6_addr(const char *in, const char **end, uint32_t v[IPV6_ADDR_U32],
+ char dlm)
+{
+ uint32_t addr[IPV6_ADDR_U16];
+
+ GET_CB_FIELD(in, addr[0], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[1], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[2], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[3], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[4], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[5], 16, UIN
[dpdk-dev] [v4 1/3] Merge l3fwd-acl and l3fwd code.
v4: > Initialize rss_hf to IP for LPM, EM and ACL. > Update rss_hf with l4 in parse_args for ACL. > Fix pending checkpatch code indentation warning. v3: > Fix additional checkpatch coding style issues. v2: > Fix checkpatch errors and warnings related to non strings greater than 80 characters. > MACRO GET_CB_FIELD and strings greater than 80 characters warnings are not fixed. v1: l3fwd-acl changes: > Merge common init code in l3fwd-acl and l3fwd into main.c. > Move non-critical inline functions to l3fwd_acl.h. > Move critial packet processing inline functions to l3fwd_acl_scalar.h > Move l3fwd-acl init code to l3fwd_acl.c. > Delete l3fwd-acl directory. l3fwd changes: > Add '-A' as an option for ACL processing. > Merge parsing options from l3fwd-acl and l3fwd. Retain l3fwd-acl definitions. > Move specific setup functions (setup_acl, setup_lpm and setup_hash). Testing: > Compiled successfully for x86_64-native-linuxapp-gcc > Tested LPM, EM and ACL basic functionality. Signed-off-by: Ravi Kerur --- examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 49 + examples/l3fwd/l3fwd_acl.c| 1064 +++ examples/l3fwd/l3fwd_acl.h| 263 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 14 +- examples/l3fwd/l3fwd_lpm.c| 23 +- examples/l3fwd/main.c | 209 ++-- 10 files changed, 1722 insertions(+), 2219 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile deleted file mode 100644 index a3473a8..000 --- a/examples/l3fwd-acl/Makefile +++ /dev/null @@ -1,56 +0,0 @@ -# BSD LICENSE -# -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of Intel Corporation nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -ifeq ($(RTE_SDK),) -$(error "Please define RTE_SDK environment variable") -endif - -# Default target, can be overriden by command line or environment -RTE_TARGET ?= x86_64-native-linuxapp-gcc - -include $(RTE_SDK)/mk/rte.vars.mk - -# binary name -APP = l3fwd-acl - -# all source are stored in SRCS-y -SRCS-y := main.c - -CFLAGS += -O3 -CFLAGS += $(WERROR_FLAGS) - -# workaround for a gcc bug with noreturn attribute -# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 -ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) -CFLAGS_main.o += -Wno-return-type -endif - -include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c deleted file mode 100644 index 3cfbb40..000 --- a/examples/l3fwd-acl/main.c +++ /dev/null @@ -1,2079 +0,0 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2010-2016 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source an
Re: [dpdk-dev] [RFC 17.05 v1 0/3] Merge l3fwd-acl and l3fwd
Hi Konstantin,
Thanks for the inputs.
Initialization starts with ETH_RSS_IP and gets updated with L4 if ACL is
selected in parse_args function. This change is to fix rss_hf.
I have submitted 'v4' patch, please let me know if additional changes are
needed.
Thanks.
On Sun, Mar 5, 2017 at 5:15 AM, Ananyev, Konstantin <
konstantin.anan...@intel.com> wrote:
>
> Hi Ravi,
>
> >
> > Hi Konstantin,
> >
> > Sorry for this one, I had to resend patch series as 'v3' as additional
> checkpatch warnings were seen after the submission which didn't show
> > up in my run.
> >
> > 'v3' patch should have all fixed except the ones I mentioned in my
> earlier email on which I need inputs from you.
> >
> > Thanks.
> >
> > On Sat, Mar 4, 2017 at 11:49 AM, Ravi Kerur wrote:
> > Hi Konstantin,
> >
> > I have sent 'v2' patchset. I need clarifications on following things, if
> they should be fixed I will send out 'v3' so please let me know.
> >
> > Following code changes were done by me manually, not merged.
> > +++ b/examples/l3fwd/main.c
> > @@ -161,7 +163,9 @@ static struct rte_eth_conf port_conf = {
> > .rx_adv_conf = {
> > .rss_conf = {
> > .rss_key = NULL,
> > - .rss_hf = ETH_RSS_IP,
> > + .rss_hf = ETH_RSS_IP | ETH_RSS_UDP |
> > + ETH_RSS_TCP | ETH_RSS_SCTP,
> > +
> > },
> >
> > The reason I did it is because
> >
> > LPM/EM has .rss_hf = ETH_RSS_IP
> > ACL has .rss_hf = ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP | ETH_RSS_SCTP,
> >
> > ACL looks like a superset of LPM/EM and functional testing didn't reveal
> any issues hence I kept ACL version.
>
> But at least for LPM, we probably don't want L4 ports affect packet
> distribution?
> Probably the safest way would be to have a separate port_conf for each
> case (LPM/EM/ACL).
> That way will preserve the original behavior.
>
> >
> > 2. Checkpatch errors are all fixed. Some warnings are not fixed and they
> are
> >
> > 2.a, string length greater than 80 characters
> > 2.b GET_CB_FIELD macro. I could have changed GET_CB_FIELD to inline
> function, however, function names cannot be in capital letters. I
> > could have changed it to 'get_cb_field' inline function, but didn't do
> it as I thought it may not be worth the change.
>
> It is ok by me to leave as it is by now.
> Thanks
> Konstantin
>
>
>
>
Re: [dpdk-dev] [PATCH] net/tap: fix dev name look-up
On 3/3/2017 8:54 AM, Pascal Mazon wrote:
> The call to rte_eth_dev_allocate(tap_name) sets dev->data->name to
> tap_name (e.g. "dtap0").
>
> A look-up using tap_name is expected to return this device, not a
> look-up using name (e.g. "net_tap0").
This will break rte_pmd_tap_remove(), because it gets device name
(net_tap0) as parameter.
And logically this is wrong too, current eth_dev->data->name is to keep
device name, all other PMDs use this way, not for Linux interface name.
Current tap PMD, first gives "dtap0" to rte_eth_dev_allocate() as
argument, which sets device name to this value. Later with snprintf()
overwrites the device name with correct value, I think better thing to
do is give correct argument to rte_eth_dev_allocate() and remove snprintf()
>
> Signed-off-by: Pascal Mazon
> ---
> drivers/net/tap/rte_eth_tap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 47a706070652..14c345f07afa 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -691,7 +691,7 @@ eth_dev_tap_create(const char *name, char *tap_name)
> dev->driver = NULL;
> dev->rx_pkt_burst = pmd_rx_burst;
> dev->tx_pkt_burst = pmd_tx_burst;
> - snprintf(dev->data->name, sizeof(dev->data->name), "%s", name);
> + snprintf(dev->data->name, sizeof(dev->data->name), "%s", tap_name);
>
> /* Presetup the fds to -1 as being not valid */
> for (i = 0; i < RTE_PMD_TAP_MAX_QUEUES; i++) {
>
Re: [dpdk-dev] [PATCH v2] net/i40e: no more initial VF MAC address
On 2/21/2017 10:45 PM, Qi Zhang wrote: > During PF initialization, PF will generate an initial mac address > for VFs, the purpose is to help VF keep a constant mac address between > its startup/shutdown cycles. Now this is not necessary, since we already > provide an API to set VF's MAC address from PF side > (rte_pmd_i40e_set_vf_mac_addr). > Application can use this API to lock down VF's mac address.(of course this > should happen before VF init) > While without this patch, we still can use rte_pmd_i40e_set_vf_mac_addr > to overwrite the random one, but this patch align DPDK's default behavior > with Kernel PF driver's, and this help to give an identical experience > when work with kernel VF driver. > > Signed-off-by: Qi Zhang Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/ixgbe: fix RX queue blocking issue
On 2/22/2017 2:59 AM, Wenzhuo Lu wrote:
> In the IOV scenario, multi RX queues can be assigned
> to one VF. If the dropping is not enabled, when no
> descriptors are available for one queue, this queue
> can block others.
>
> Fixes: 00e30184daa0 ("ixgbe: add PF support")
> CC: sta...@dpdk.org
>
> Suggested-by: Liang-min Wang
> Signed-off-by: Wenzhuo Lu
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/ixgbe: remove invalid declaration
On 2/28/2017 1:22 PM, Olivier Matz wrote:
> The function is not defined anywhere, remove it.
>
> Fixes: 0eb609239efd ("ixgbe: enable Rx queue interrupts for PF and VF")
>
> Signed-off-by: Olivier Matz
Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] net/ixgbe: remove invalid declaration
On 3/5/2017 10:31 PM, Ferruh Yigit wrote:
> On 2/28/2017 1:22 PM, Olivier Matz wrote:
>> The function is not defined anywhere, remove it.
>>
>> Fixes: 0eb609239efd ("ixgbe: enable Rx queue interrupts for PF and VF")
>>
>> Signed-off-by: Olivier Matz
>
> Acked-by: Ferruh Yigit
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH 2/4] net/e1000: add grouping of xstats for e1000 driver
Hi, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Kuba Kozak > Sent: Friday, March 3, 2017 8:55 PM > To: dev@dpdk.org > Cc: Piasecki, JacekX; Kozak, KubaX > Subject: [dpdk-dev] [PATCH 2/4] net/e1000: add grouping of xstats for e1000 > driver > > From: Jacek Piasecki > > This patch extends the 'rte_igb_xstats_name_off' structure with additional > field > 'group_mask'. For each xstats there is now specified group (e.g. TX_GROUP), > one xstatistic can be in several groups. > To implement new functionality of retriving xstats by group on driver level, > there > are two functions added: > eth_igb_xstats_get_by_group() and eth_igb_xstats_get_names_by_group() > > Signed-off-by: Jacek Piasecki > Signed-off-by: Kuba Kozak Acked-by: Wenzhuo Lu Just a reminder, the tittle need to add v2 when sending a new version, like ' [dpdk-dev] [v2 PATCH 2/4]'
Re: [dpdk-dev] [PATCH v2 0/5] consistent PMD batching behaviour
Thanks, Konstantin. --Zhiyong > -Original Message- > From: Ananyev, Konstantin > Sent: Sunday, March 5, 2017 9:03 PM > To: Yang, Zhiyong ; dev@dpdk.org > Cc: Richardson, Bruce > Subject: RE: [dpdk-dev] [PATCH v2 0/5] consistent PMD batching behaviour > > > > The rte_eth_tx_burst() function in the file Rte_ethdev.h is invoked to > > transmit output packets on the output queue for DPDK applications as > > follows. > > > > static inline uint16_t > > rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id, > > struct rte_mbuf **tx_pkts, uint16_t nb_pkts); > > > > Note: The fourth parameter nb_pkts: The number of packets to transmit. > > > > The rte_eth_tx_burst() function returns the number of packets it > > actually sent. Most of PMD drivers can support the policy "send as > > many packets to transmit as possible" at the PMD level. but the few of > > PMDs have some sort of artificial limits for the pkts sent > > successfully. For example, VHOST tx burst size is limited to 32 > > packets. Some rx_burst functions have the similar problem. The main > > benefit is consistent batching behavior for user to simplify their > > logic and avoid misusage at the application level, there is unified > > rte_eth_tx/rx_burst interface already, there is no reason for inconsistent > behaviors. > > This patchset fixes it via adding wrapper function at the PMD level. > > > > Changes in V2: > > 1. rename ixgbe, i40e and fm10k vec function XXX_xmit_pkts_vec to new > > name XXX_xmit_fixed_burst_vec, new wrapper functions use original > name > > XXX_xmit_pkts_vec according to Bruce's suggestion. > > > > 2. simplify the code to avoid the if or if/else. > > > > Zhiyong Yang (5): > > net/fm10k: remove limit of fm10k_xmit_pkts_vec burst size > > net/i40e: remove limit of i40e_xmit_pkts_vec burst size > > net/ixgbe: remove limit of ixgbe_xmit_pkts_vec burst size > > net/vhost: remove limit of vhost TX burst size > > net/vhost: remove limit of vhost RX burst size > > > > drivers/net/fm10k/fm10k.h | 4 ++-- > > drivers/net/fm10k/fm10k_ethdev.c| 28 > --- > > drivers/net/fm10k/fm10k_rxtx_vec.c | 4 ++-- > > drivers/net/i40e/i40e_rxtx.c| 28 --- > > drivers/net/i40e/i40e_rxtx.h| 4 ++-- > > drivers/net/i40e/i40e_rxtx_vec_neon.c | 4 ++-- > > drivers/net/i40e/i40e_rxtx_vec_sse.c| 4 ++-- > > drivers/net/ixgbe/ixgbe_rxtx.c | 29 > > > drivers/net/ixgbe/ixgbe_rxtx.h | 4 ++-- > > drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 4 ++-- > > drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 4 ++-- > > drivers/net/vhost/rte_eth_vhost.c | 34 > + > > 12 files changed, 125 insertions(+), 26 deletions(-) > > > > Acked-by: Konstantin Ananyev > > > -- > > 2.7.4
Re: [dpdk-dev] [PATCH 1/3] app/testpmd: support MPLS for generic filter
Hi Adrien,
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Friday, March 3, 2017 7:09 PM
> To: Xing, Beilei
> Cc: Wu, Jingjing ; Zhang, Helin
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/3] app/testpmd: support MPLS for generic
> filter
>
> Hi Beilei,
>
> I think the commit title should reflect that this commit adds support for GRE
> and MPLS items to rte_flow, testpmd changes are only a consequence.
Thanks for the comments. I will change the title in the next version.
>
> On Fri, Mar 03, 2017 at 05:43:54PM +0800, Beilei Xing wrote:
> > This patch adds MPLS support for generic filter API.
> >
> > Signed-off-by: Beilei Xing
> > ---
> > app/test-pmd/cmdline_flow.c | 55
> +
> > app/test-pmd/config.c | 2 ++
> > lib/librte_ether/rte_flow.h | 40
> +
> > 3 files changed, 97 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index ff98690..241bda1 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -159,6 +159,11 @@ enum index {
> > ITEM_SCTP_CKSUM,
> > ITEM_VXLAN,
> > ITEM_VXLAN_VNI,
> > + ITEM_MPLS,
> > + ITEM_MPLS_LABEL,
> > + ITEM_GRE,
> > + ITEM_GRE_FLAGS,
> > + ITEM_GRE_PROTO,
> >
> > /* Validate/create actions. */
> > ACTIONS,
> > @@ -432,6 +437,8 @@ static const enum index next_item[] = {
> > ITEM_TCP,
> > ITEM_SCTP,
> > ITEM_VXLAN,
> > + ITEM_MPLS,
> > + ITEM_GRE,
> > ZERO,
> > };
> >
> > @@ -538,6 +545,19 @@ static const enum index item_vxlan[] = {
> > ZERO,
> > };
> >
> > +static const enum index item_mpls[] = {
> > + ITEM_MPLS_LABEL,
> > + ITEM_NEXT,
> > + ZERO,
> > +};
> > +
> > +static const enum index item_gre[] = {
> > + ITEM_GRE_FLAGS,
> > + ITEM_GRE_PROTO,
> > + ITEM_NEXT,
> > + ZERO,
> > +};
> > +
> > static const enum index next_action[] = {
> > ACTION_END,
> > ACTION_VOID,
> > @@ -1279,6 +1299,41 @@ static const struct token token_list[] = {
> > .next = NEXT(item_vxlan, NEXT_ENTRY(UNSIGNED),
> item_param),
> > .args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_vxlan, vni)),
> > },
> > + [ITEM_MPLS] = {
> > + .name = "mpls",
> > + .help = "match MPLS header",
> > + .priv = PRIV_ITEM(MPLS, sizeof(struct rte_flow_item_mpls)),
> > + .next = NEXT(item_mpls),
> > + .call = parse_vc,
> > + },
> > + [ITEM_MPLS_LABEL] = {
> > + .name = "label",
> > + .help = "MPLS label",
> > + .next = NEXT(item_mpls, NEXT_ENTRY(UNSIGNED),
> item_param),
> > + .args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_mpls,
> > +label_tc_s_ttl)),
> > + },
> > + [ITEM_GRE] = {
> > + .name = "gre",
> > + .help = "match GRE header",
> > + .priv = PRIV_ITEM(GRE, sizeof(struct rte_flow_item_gre)),
> > + .next = NEXT(item_gre),
> > + .call = parse_vc,
> > + },
> > + [ITEM_GRE_FLAGS] = {
> > + .name = "c_rsvd0_ver",
> > + .help = "GRE c_rsvd0_ver",
> > + .next = NEXT(item_gre, NEXT_ENTRY(UNSIGNED),
> item_param),
> > + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gre,
> > +c_rsvd0_ver)),
> > + },
> > + [ITEM_GRE_PROTO] = {
> > + .name = "protocol",
> > + .help = "GRE protocol type",
> > + .next = NEXT(item_gre, NEXT_ENTRY(UNSIGNED),
> item_param),
> > + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gre,
> > +protocol)),
> > + },
>
> Testpmd documentation must be updated accordingly, see:
>
> doc/guides/testpmd_app_ug/testpmd_funcs.rst
>
> > /* Validate/create actions. */
> > [ACTIONS] = {
> > .name = "actions",
> > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> > 80491fc..c042765 100644
> > --- a/app/test-pmd/config.c
> > +++ b/app/test-pmd/config.c
> > @@ -963,6 +963,8 @@ static const struct {
> > MK_FLOW_ITEM(TCP, sizeof(struct rte_flow_item_tcp)),
> > MK_FLOW_ITEM(SCTP, sizeof(struct rte_flow_item_sctp)),
> > MK_FLOW_ITEM(VXLAN, sizeof(struct rte_flow_item_vxlan)),
> > + MK_FLOW_ITEM(MPLS, sizeof(struct rte_flow_item_mpls)),
> > + MK_FLOW_ITEM(GRE, sizeof(struct rte_flow_item_gre)),
> > };
> >
> > /** Compute storage space needed by item specification. */ diff --git
> > a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h index
> > 171a569..c845953 100644
> > --- a/lib/librte_ether/rte_flow.h
> > +++ b/lib/librte_ether/rte_flow.h
> > @@ -282,6 +282,20 @@ enum rte_flow_item_type {
> > * See struct rte_flow_item_nvgre.
> > */
> > RTE_FLOW_ITEM_TYPE_NVGRE,
> > +
> > + /**
> > +* Matches a MPLS header.
> > +*
> > +* See struct rte_flow_ite
Re: [dpdk-dev] [dpdk-announce] DPDK 16.11.1 (LTS) released
Hello, Is there a git branch for DPDK LTS versions ? Regards, Gregory On Thu, Mar 2, 2017 at 4:13 PM, Yuanhan Liu wrote: > Hi all, > > I'm pleased to announce our first LTS release, v16.11.1: > http://fast.dpdk.org/rel/dpdk-16.11.1.tar.xz > > Thanks everyone for making it happen! > > Note that LTS has about 2 years maintenance period. The next release > (v16.11.2) is planned to be released in 3 months, shortly (around 3 > weeks) after v17.05. > > Please also note that, besides the LTS, we also maintain a stable > release for each upstream release. And generally, they have much > shorter maintenance period (typically, we only maintain one release > for each stable release). You could check following link for more > information about stable and LTS release. > http://dpdk.org/doc/guides/contributing/stable.html > > Currently, I'm the only maintainer for both, and I'm looking for > volunteers to take one or few stable releases. If anyone are > interested, please let me know. FYI, I have already made most of > the work automatic; it won't be a task will take you much time. > > Thanks. > > --yliu > > --- > app/test-pmd/Makefile | 2 + > app/test-pmd/cmdline.c | 24 ++ > app/test/test_cryptodev_perf.c | 6 + > buildtools/pmdinfogen/pmdinfogen.c | 15 +- > buildtools/pmdinfogen/pmdinfogen.h | 10 +- > doc/guides/cryptodevs/openssl.rst | 18 +- > doc/guides/nics/features/virtio.ini| 1 + > doc/guides/rel_notes/release_16_11.rst | 110 +++ > drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 4 +- > drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 4 +- > drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 + > drivers/crypto/kasumi/rte_kasumi_pmd.c | 4 +- > drivers/crypto/openssl/rte_openssl_pmd.c | 2 + > drivers/crypto/qat/qat_crypto.c| 70 ++--- > drivers/crypto/qat/qat_crypto.h| 1 + > drivers/crypto/snow3g/rte_snow3g_pmd.c | 4 +- > drivers/crypto/zuc/rte_zuc_pmd.c | 6 +- > drivers/net/af_packet/rte_eth_af_packet.c | 13 +- > drivers/net/bnx2x/bnx2x.c | 1 + > drivers/net/bnx2x/bnx2x.h | 11 +- > drivers/net/bnx2x/bnx2x_ethdev.c | 9 + > drivers/net/bnx2x/bnx2x_vfpf.c | 1 + > drivers/net/cxgbe/base/t4_hw.c | 2 +- > drivers/net/cxgbe/cxgbe_main.c | 2 +- > drivers/net/ena/base/ena_com.c | 16 +- > drivers/net/ena/ena_ethdev.c | 21 +- > drivers/net/enic/enic.h| 6 +- > drivers/net/enic/enic_clsf.c | 14 +- > drivers/net/enic/enic_main.c | 5 +- > drivers/net/enic/enic_res.c| 5 +- > drivers/net/enic/enic_res.h| 5 +- > drivers/net/enic/enic_rxtx.c | 13 +- > drivers/net/fm10k/fm10k_ethdev.c | 3 + > drivers/net/i40e/i40e_ethdev.c | 62 +++- > drivers/net/i40e/i40e_ethdev.h | 4 +- > drivers/net/i40e/i40e_ethdev_vf.c | 44 +-- > drivers/net/i40e/i40e_pf.c | 6 +- > drivers/net/i40e/i40e_pf.h | 5 - > drivers/net/i40e/i40e_rxtx.c | 8 +- > drivers/net/i40e/i40e_rxtx_vec_common.h| 1 + > drivers/net/i40e/i40e_rxtx_vec_sse.c | 37 ++- > drivers/net/ixgbe/ixgbe_ethdev.c | 23 +- > drivers/net/ixgbe/ixgbe_ethdev.h | 2 + > drivers/net/ixgbe/ixgbe_rxtx.c | 16 +- > drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c| 29 +- > drivers/net/mlx4/mlx4.c| 18 +- > drivers/net/mlx5/mlx5.c| 4 +- > drivers/net/mlx5/mlx5_ethdev.c | 110 --- > drivers/net/mlx5/mlx5_prm.h| 47 +-- > drivers/net/mlx5/mlx5_rxtx.c | 126 > drivers/net/mlx5/mlx5_rxtx.h | 2 - > drivers/net/mlx5/mlx5_txq.c| 2 - > drivers/net/nfp/nfp_net.c | 10 +- > drivers/net/pcap/rte_eth_pcap.c| 2 +- > drivers/net/qede/base/ecore_init_fw_funcs.c| 2 +- > drivers/net/qede/base/reg_addr.h | 6 +- > drivers/net/qede/qede_eth_if.c | 101 +- > drivers/net/qede/qede_eth_if.h | 38 +-- > drivers/net/qede/qede_ethdev.c | 341 > +++-- > drivers/net/qede/qede_ethdev.h | 15 + > drivers/net/qede/qede_main.c
Re: [dpdk-dev] [dpdk-announce] DPDK 16.11.1 (LTS) released
On Sun, Mar 05, 2017 at 08:57:31AM +0200, Gregory Etelson wrote: > Hello, > > Is there a git branch for DPDK LTS versions ? Yes, all stable and LTS releases are hosted at git tree: http://dpdk.org/browse/dpdk-stable/ --yliu > On Thu, Mar 2, 2017 at 4:13 PM, Yuanhan Liu > wrote: > > Hi all, > > I'm pleased to announce our first LTS release, v16.11.1: > http://fast.dpdk.org/rel/dpdk-16.11.1.tar.xz > > Thanks everyone for making it happen! > > Note that LTS has about 2 years maintenance period. The next release > (v16.11.2) is planned to be released in 3 months, shortly (around 3 > weeks) after v17.05. > > Please also note that, besides the LTS, we also maintain a stable > release for each upstream release. And generally, they have much > shorter maintenance period (typically, we only maintain one release > for each stable release). You could check following link for more > information about stable and LTS release. > http://dpdk.org/doc/guides/contributing/stable.html > > Currently, I'm the only maintainer for both, and I'm looking for > volunteers to take one or few stable releases. If anyone are > interested, please let me know. FYI, I have already made most of > the work automatic; it won't be a task will take you much time. > > Thanks. > > --yliu > > --- > app/test-pmd/Makefile | 2 + > app/test-pmd/cmdline.c | 24 ++ > app/test/test_cryptodev_perf.c | 6 + > buildtools/pmdinfogen/pmdinfogen.c | 15 +- > buildtools/pmdinfogen/pmdinfogen.h | 10 +- > doc/guides/cryptodevs/openssl.rst | 18 +- > doc/guides/nics/features/virtio.ini | 1 + > doc/guides/rel_notes/release_16_11.rst | 110 +++ > drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 4 +- > drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 4 +- > drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 + > drivers/crypto/kasumi/rte_kasumi_pmd.c | 4 +- > drivers/crypto/openssl/rte_openssl_pmd.c | 2 + > drivers/crypto/qat/qat_crypto.c | 70 ++--- > drivers/crypto/qat/qat_crypto.h | 1 + > drivers/crypto/snow3g/rte_snow3g_pmd.c | 4 +- > drivers/crypto/zuc/rte_zuc_pmd.c | 6 +- > drivers/net/af_packet/rte_eth_af_packet.c | 13 +- > drivers/net/bnx2x/bnx2x.c | 1 + > drivers/net/bnx2x/bnx2x.h | 11 +- > drivers/net/bnx2x/bnx2x_ethdev.c | 9 + > drivers/net/bnx2x/bnx2x_vfpf.c | 1 + > drivers/net/cxgbe/base/t4_hw.c | 2 +- > drivers/net/cxgbe/cxgbe_main.c | 2 +- > drivers/net/ena/base/ena_com.c | 16 +- > drivers/net/ena/ena_ethdev.c | 21 +- > drivers/net/enic/enic.h | 6 +- > drivers/net/enic/enic_clsf.c | 14 +- > drivers/net/enic/enic_main.c | 5 +- > drivers/net/enic/enic_res.c | 5 +- > drivers/net/enic/enic_res.h | 5 +- > drivers/net/enic/enic_rxtx.c | 13 +- > drivers/net/fm10k/fm10k_ethdev.c | 3 + > drivers/net/i40e/i40e_ethdev.c | 62 +++- > drivers/net/i40e/i40e_ethdev.h | 4 +- > drivers/net/i40e/i40e_ethdev_vf.c | 44 +-- > drivers/net/i40e/i40e_pf.c | 6 +- > drivers/net/i40e/i40e_pf.h | 5 - > drivers/net/i40e/i40e_rxtx.c | 8 +- > drivers/net/i40e/i40e_rxtx_vec_common.h | 1 + > drivers/net/i40e/i40e_rxtx_vec_sse.c | 37 ++- > drivers/net/ixgbe/ixgbe_ethdev.c | 23 +- > drivers/net/ixgbe/ixgbe_ethdev.h | 2 + > drivers/net/ixgbe/ixgbe_rxtx.c | 16 +- > drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 29 +- > drivers/net/mlx4/mlx4.c | 18 +- > drivers/net/mlx5/mlx5.c | 4 +- > drivers/net/mlx5/mlx5_ethdev.c | 110 --- > drivers/net/mlx5/mlx5_prm.h | 47 +-- > drivers/net/mlx5/mlx5_rxtx.c | 126 > drivers/net/mlx5/mlx5_rxtx.h | 2 - > drivers/net/mlx5/mlx5_txq.c | 2 - > drivers/net/nfp/nfp_net.c | 10 +- > drivers/net/pcap/rte_eth_
Re: [dpdk-dev] [PATCH] net/thunderx: check data offset alignment requirement
On 3/4/2017 6:16 PM, Jerin Jacob wrote:
nicvf HW expects the DMA address of the packet data to be
aligned with cache line size.
Packet data offset is a function of struct mbuf size,
mbuf private size and headroom. mbuf private size can
be changed from the application in pool creation, this
check detects HW alignment requirement constraint in pmd
start function.
Signed-off-by: Jerin Jacob
---
drivers/net/thunderx/nicvf_ethdev.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/thunderx/nicvf_ethdev.c
b/drivers/net/thunderx/nicvf_ethdev.c
index 1060319..ad7b5d6 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1410,7 +1410,7 @@ static int
nicvf_vf_start(struct rte_eth_dev *dev, struct nicvf *nic, uint32_t rbdrsz)
{
int ret;
- uint16_t qidx;
+ uint16_t qidx, data_off;
uint32_t total_rxq_desc, nb_rbdr_desc, exp_buffs;
uint64_t mbuf_phys_off = 0;
struct nicvf_rxq *rxq;
@@ -1451,10 +1451,17 @@ nicvf_vf_start(struct rte_eth_dev *dev, struct nicvf
*nic, uint32_t rbdrsz)
nic->vf_id, qidx, rxq->pool->name);
return -ENOMEM;
}
- rxq->mbuf_phys_off -= nicvf_mbuff_meta_length(mbuf);
- rxq->mbuf_phys_off -= RTE_PKTMBUF_HEADROOM;
+ data_off = nicvf_mbuff_meta_length(mbuf);
+ data_off += RTE_PKTMBUF_HEADROOM;
rte_pktmbuf_free(mbuf);
+ if (data_off % RTE_CACHE_LINE_SIZE) {
+ PMD_INIT_LOG(ERR, "unaligned data_offset=%d delta=%d\n",
+ data_off, data_off % RTE_CACHE_LINE_SIZE);
Do you also want to log about the particular pool having this issue?
rxq->pool->name
+ return -EINVAL;
+ }
+ rxq->mbuf_phys_off -= data_off;
+
if (mbuf_phys_off == 0)
mbuf_phys_off = rxq->mbuf_phys_off;
if (mbuf_phys_off != rxq->mbuf_phys_off) {
otherwise, you may add:
Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH] net/thunderx: check data offset alignment requirement
On Mon, Mar 06, 2017 at 11:00:01AM +0530, Hemant Agrawal wrote:
> On 3/4/2017 6:16 PM, Jerin Jacob wrote:
> > nicvf HW expects the DMA address of the packet data to be
> > aligned with cache line size.
> >
> > Packet data offset is a function of struct mbuf size,
> > mbuf private size and headroom. mbuf private size can
> > be changed from the application in pool creation, this
> > check detects HW alignment requirement constraint in pmd
> > start function.
> >
> > Signed-off-by: Jerin Jacob
> > ---
> > drivers/net/thunderx/nicvf_ethdev.c | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/thunderx/nicvf_ethdev.c
> > b/drivers/net/thunderx/nicvf_ethdev.c
> > index 1060319..ad7b5d6 100644
> > --- a/drivers/net/thunderx/nicvf_ethdev.c
> > +++ b/drivers/net/thunderx/nicvf_ethdev.c
> > @@ -1410,7 +1410,7 @@ static int
> > nicvf_vf_start(struct rte_eth_dev *dev, struct nicvf *nic, uint32_t rbdrsz)
> > {
> > int ret;
> > - uint16_t qidx;
> > + uint16_t qidx, data_off;
> > uint32_t total_rxq_desc, nb_rbdr_desc, exp_buffs;
> > uint64_t mbuf_phys_off = 0;
> > struct nicvf_rxq *rxq;
> > @@ -1451,10 +1451,17 @@ nicvf_vf_start(struct rte_eth_dev *dev, struct
> > nicvf *nic, uint32_t rbdrsz)
> > nic->vf_id, qidx, rxq->pool->name);
> > return -ENOMEM;
> > }
> > - rxq->mbuf_phys_off -= nicvf_mbuff_meta_length(mbuf);
> > - rxq->mbuf_phys_off -= RTE_PKTMBUF_HEADROOM;
> > + data_off = nicvf_mbuff_meta_length(mbuf);
> > + data_off += RTE_PKTMBUF_HEADROOM;
> > rte_pktmbuf_free(mbuf);
> >
> > + if (data_off % RTE_CACHE_LINE_SIZE) {
> > + PMD_INIT_LOG(ERR, "unaligned data_offset=%d delta=%d\n",
> > + data_off, data_off % RTE_CACHE_LINE_SIZE);
>
> Do you also want to log about the particular pool having this issue?
> rxq->pool->name
Yes.I will add the pool name in v2.
Thanks.
>
> > + return -EINVAL;
> > + }
> > + rxq->mbuf_phys_off -= data_off;
> > +
> > if (mbuf_phys_off == 0)
> > mbuf_phys_off = rxq->mbuf_phys_off;
> > if (mbuf_phys_off != rxq->mbuf_phys_off) {
> >
> otherwise, you may add:
> Acked-by: Hemant Agrawal
>
Re: [dpdk-dev] [PATCH 2/4] test: add AES DOCSIS tests for QAT PMD
Tested-by: Yang Gang < gangx.y...@intel.com >
- Check patch: success
- Apply patch: success
- compilation: success
OS: fedora23
GCC: gcc_x86-64, 5.3.1
Commit: dpdk-next-crypto(081fefb01748e7063b1b9692af89d8115ec64632)
x86_64-native-linuxapp-gcc: compile pass
- dts validation:
-- Test Commit: e5041333988936fdb09d578ec4fb7cb0ce796ecb
-- OS/Kernel: Fedora23/4.2.3-300.fc23.x86_64
-- GCC: gcc version 5.3.1
-- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 1.80GHz
-- NIC: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
-- total 2,failed 0 (case1: contain cryptodev_qat_autotest and all of others
cryptodev cases on unit test .
case 2: all of the related cases about QAT AES DOCSIS BPI
cipher only and cipher auth on l2fwd-crypto test)
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fiona Trahe
Sent: Thursday, March 02, 2017 9:03 PM
To: dev@dpdk.org; De Lara Guarch, Pablo
Cc: Jain, Deepak K ; Trahe, Fiona
Subject: [dpdk-dev] [PATCH 2/4] test: add AES DOCSIS tests for QAT PMD
Extend test suite to run AES DOCSIS tests on Intel QuickAssist PMD.
Signed-off-by: Fiona Trahe
---
app/test/test_cryptodev.c | 18 ++
app/test/test_cryptodev_aes_test_vectors.h | 18 --
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c index
7208fa6..ebc011b 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -1548,6 +1548,22 @@ test_AES_docsis_mb_all(void) }
static int
+test_AES_docsis_qat_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool, ts_params->valid_devs[0],
+ RTE_CRYPTODEV_QAT_SYM_PMD,
+ BLKCIPHER_AES_DOCSIS_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
+static int
test_authonly_mb_all(void)
{
struct crypto_testsuite_params *ts_params = &testsuite_params; @@
-7570,6 +7586,8 @@ static struct unit_test_suite cryptodev_qat_testsuite = {
test_3DES_cipheronly_qat_all),
TEST_CASE_ST(ut_setup, ut_teardown,
test_DES_cipheronly_qat_all),
+ TEST_CASE_ST(ut_setup, ut_teardown,
+ test_AES_docsis_qat_all),
TEST_CASE_ST(ut_setup, ut_teardown, test_stats),
/** AES GCM Authenticated Encryption */ diff --git
a/app/test/test_cryptodev_aes_test_vectors.h
b/app/test/test_cryptodev_aes_test_vectors.h
index aacabab..992705e 100644
--- a/app/test/test_cryptodev_aes_test_vectors.h
+++ b/app/test/test_cryptodev_aes_test_vectors.h
@@ -1439,37 +1439,43 @@ static const struct blockcipher_test_case
aes_docsis_test_cases[] = {
.test_descr = "AES-DOCSIS-BPI Full Block Encryption",
.test_data = &aes_test_data_docsis_1,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "AES-DOCSIS-BPI Runt Block Encryption",
.test_data = &aes_test_data_docsis_2,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "AES-DOCSIS-BPI Uneven Encryption",
.test_data = &aes_test_data_docsis_3,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "AES-DOCSIS-BPI Full Block Decryption",
.test_data = &aes_test_data_docsis_1,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "AES-DOCSIS-BPI Runt Block Decryption",
.test_data = &aes_test_data_docsis_2,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_MB |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "AES-DOCSIS-BPI Uneven Decryption",
.test_data = &aes_test_data_
Re: [dpdk-dev] [PATCH 3/4] test: add DES DOCSIS tests for QAT PMD
Tested-by: Yang Gang < gangx.y...@intel.com >
- Check patch: success
- Apply patch: success
- compilation: success
OS: fedora23
GCC: gcc_x86-64, 5.3.1
Commit: dpdk-next-crypto(081fefb01748e7063b1b9692af89d8115ec64632)
x86_64-native-linuxapp-gcc: compile pass
- dts validation:
-- Test Commit: e5041333988936fdb09d578ec4fb7cb0ce796ecb
-- OS/Kernel: Fedora23/4.2.3-300.fc23.x86_64
-- GCC: gcc version 5.3.1
-- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 1.80GHz
-- NIC: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
-- total 2,failed 0 (case1: contain cryptodev_qat_autotest and all of others
cryptodev cases on unit test .
case 2: all of the related cases about QAT DES DOCSIS BPI
cipher only and cipher auth on l2fwd-crypto test)
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fiona Trahe
Sent: Thursday, March 02, 2017 9:03 PM
To: dev@dpdk.org; De Lara Guarch, Pablo
Cc: Jain, Deepak K ; Trahe, Fiona
Subject: [dpdk-dev] [PATCH 3/4] test: add DES DOCSIS tests for QAT PMD
Extend test suite to run DES DOCSIS tests on Intel
QuickAssist PMD.
Signed-off-by: Fiona Trahe
---
app/test/test_cryptodev.c | 18 ++
app/test/test_cryptodev_des_test_vectors.h | 18 --
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c index
ebc011b..b7c99ed 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -1564,6 +1564,22 @@ test_AES_docsis_qat_all(void) }
static int
+test_DES_docsis_qat_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool, ts_params->valid_devs[0],
+ RTE_CRYPTODEV_QAT_SYM_PMD,
+ BLKCIPHER_DES_DOCSIS_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
+static int
test_authonly_mb_all(void)
{
struct crypto_testsuite_params *ts_params = &testsuite_params; @@
-7588,6 +7604,8 @@ static struct unit_test_suite cryptodev_qat_testsuite = {
test_DES_cipheronly_qat_all),
TEST_CASE_ST(ut_setup, ut_teardown,
test_AES_docsis_qat_all),
+ TEST_CASE_ST(ut_setup, ut_teardown,
+ test_DES_docsis_qat_all),
TEST_CASE_ST(ut_setup, ut_teardown, test_stats),
/** AES GCM Authenticated Encryption */ diff --git
a/app/test/test_cryptodev_des_test_vectors.h
b/app/test/test_cryptodev_des_test_vectors.h
index b29a49e..06dcf5e 100644
--- a/app/test/test_cryptodev_des_test_vectors.h
+++ b/app/test/test_cryptodev_des_test_vectors.h
@@ -964,37 +964,43 @@ static const struct blockcipher_test_case
des_docsis_test_cases[] = {
.test_descr = "DES-DOCSIS-BPI Full Block Encryption",
.test_data = &des_test_data_1,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "DES-DOCSIS-BPI Runt Block Encryption",
.test_data = &des_test_data_2,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "DES-DOCSIS-BPI Uneven Encryption",
.test_data = &des_test_data_3,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "DES-DOCSIS-BPI Full Block Decryption",
.test_data = &des_test_data_1,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "DES-DOCSIS-BPI Runt Block Decryption",
.test_data = &des_test_data_2,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
- .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL
+ .pmd_mask = BLOCKCIPHER_TEST_TARGET_PMD_OPENSSL |
+ BLOCKCIPHER_TEST_TARGET_PMD_QAT
},
{
.test_descr = "DES-DOCSIS-BPI Uneven Decryption",
.test_data
Re: [dpdk-dev] [PATCH 2/2] net/ixgbe: add mac type check for all filters
Hi, Ferruh
> -Original Message-
> From: Yigit, Ferruh
> Sent: Saturday, February 18, 2017 12:01 AM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: Lu, Wenzhuo
> Subject: Re: [dpdk-dev] [PATCH 2/2] net/ixgbe: add mac type check for all
> filters
>
> On 2/13/2017 7:35 AM, Wei Zhao wrote:
> > All kinds of filter need to hardware mac type check to make sure the
> > hardware support that type of fliter.
> > If not, it may cause serious issue.
> >
> > Fixes: 11777435c727 ("net/ixgbe: parse flow director filter")
> > Fixes: 672be56d76a2 ("net/ixgbe: parse n-tuple filter")
> > Fixes: eb3539fc8550 ("net/ixgbe: parse ethertype filter")
> > Fixes: 429f6ebb42cc ("net/ixgbe: parse TCP SYN filter")
> >
> > Signed-off-by: Wei Zhao
> > Signed-off-by: Wenzhuo Lu
> > ---
> > drivers/net/ixgbe/ixgbe_flow.c | 129
> > +
> > 1 file changed, 65 insertions(+), 64 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_flow.c
> > b/drivers/net/ixgbe/ixgbe_flow.c index 5a634d3..f414fa8 100644
> > --- a/drivers/net/ixgbe/ixgbe_flow.c
> > +++ b/drivers/net/ixgbe/ixgbe_flow.c
> > @@ -84,11 +84,12 @@ cons_parse_ntuple_filter(const struct rte_flow_attr
> *attr,
> > struct rte_eth_ntuple_filter *filter,
> > struct rte_flow_error *error);
> > static int
> > -ixgbe_parse_ntuple_filter(const struct rte_flow_attr *attr,
> > - const struct rte_flow_item pattern[],
> > - const struct rte_flow_action actions[],
> > - struct rte_eth_ntuple_filter *filter,
> > - struct rte_flow_error *error);
> > +ixgbe_parse_ntuple_filter(struct rte_eth_dev *dev,
> > + const struct rte_flow_attr *attr,
> > + const struct rte_flow_item pattern[],
> > + const struct rte_flow_action actions[],
> > + struct rte_eth_ntuple_filter *filter,
> > + struct rte_flow_error *error);
>
> Hi Wei,
>
> You don't need these function declarations at all. What do you think
> removing these first, in a separate patch, and won't need to update them
> here?
>
> Also it is possible to remove all function declarations if you move
> "ixgbe_flow_ops" at the end of the file, that would be something I prefer,
> but it is your call.
>
> Thanks,
> Ferruh
Sorry for late reply, I have just find your mail just now.
I think your suggestion is very good from code style, but this patch is a fix
patch set for a P2 issue.
So, it is not focus on code style. code style can be changed in
a separate patch if we need to and not mix them together?
