[dpdk-dev] Reshuffling of rte_mbuf structure.

[Thomas Monjalon]

This discussion is about improving performance of specific use cases
by moving the mbuf fields when needed.
We could consider how to configure it and how complicated it would be to
write applications or drivers (especially vector ones) for such a moving
structure.
But it is simpler to say that having an API depending of some options
is a "no-design" which could seriously slow down the DPDK adoption.
You can have a different opinion but I cannot imagine how strong must be the
arguments to make it happen.

[dpdk-dev] [PATCH v5 06/10] ixgbe: add extended statistic strings

[Thomas Monjalon]

2015-11-02 10:19, Harry van Haaren:
> +   {"rx_managment_packets", offsetof(struct ixgbe_hw_stats, mngprc)},
> +   {"rx_managment_dropped", offsetof(struct ixgbe_hw_stats, mngpdc)},
> +   {"tx_managment_packets", offsetof(struct ixgbe_hw_stats, mngptc)},

Looks to be a typo. Management?

[dpdk-dev] [PATCH] vhost-user: enable virtio 1.0

[Thomas Monjalon]

> > Make vhost-user virtio 1.0 compatible by adding it to the
> > supported features and keeping the header length
> > the same as for mergeable RX buffers.
> > 
> > Signed-off-by: Marcel Apfelbaum 
> 
> Looks good to me
> 
> Acked-by: Michael S. Tsirkin 

Applied, thanks

[dpdk-dev] [PATCH v6 0/8] virtio ring layout optimization and simple rx/tx processing

[Thomas Monjalon]

2015-11-02 23:09, Thomas Monjalon:
> > Acked-by: Jianfeng Tan
> 
> Applied with the modifications discussed in this thread, thanks.

Please Huawei,
Could you share some numbers for these optimizations?

[dpdk-dev] [PATCH v6 0/8] virtio ring layout optimization and simple rx/tx processing

[Thomas Monjalon]

> Acked-by: Jianfeng Tan

Applied with the modifications discussed in this thread, thanks.

[dpdk-dev] [PATCH v5 2/2] app/testpmd: add test commands for selecting different GRE key sizes

[Helin Zhang]

Test commands are added to support selecting differnt length of GRE key.

Signed-off-by: Helin Zhang 
Signed-off-by: Andrey Chilikin 
---
 app/test-pmd/cmdline.c  | 52 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 ++
 2 files changed, 63 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6a384a2..1018379 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6739,6 +6739,57 @@ cmdline_parse_inst_t cmd_tunnel_udp_config = {
},
 };

+/* *** GLOBAL CONFIG *** */
+struct cmd_global_config_result {
+   cmdline_fixed_string_t cmd;
+   uint8_t port_id;
+   cmdline_fixed_string_t cfg_type;
+   uint8_t len;
+};
+
+static void
+cmd_global_config_parsed(void *parsed_result,
+__attribute__((unused)) struct cmdline *cl,
+__attribute__((unused)) void *data)
+{
+   struct cmd_global_config_result *res = parsed_result;
+   struct rte_eth_global_cfg conf;
+   int ret;
+
+   memset(, 0, sizeof(conf));
+   conf.cfg_type = RTE_ETH_GLOBAL_CFG_TYPE_GRE_KEY_LEN;
+   conf.cfg.gre_key_len = res->len;
+   ret = rte_eth_dev_filter_ctrl(res->port_id, RTE_ETH_FILTER_NONE,
+ RTE_ETH_FILTER_SET, );
+   if (ret != 0)
+   printf("Global config error\n");
+}
+
+cmdline_parse_token_string_t cmd_global_config_cmd =
+   TOKEN_STRING_INITIALIZER(struct cmd_global_config_result, cmd,
+   "global_config");
+cmdline_parse_token_num_t cmd_global_config_port_id =
+   TOKEN_NUM_INITIALIZER(struct cmd_global_config_result, port_id, UINT8);
+cmdline_parse_token_string_t cmd_global_config_type =
+   TOKEN_STRING_INITIALIZER(struct cmd_global_config_result,
+   cfg_type, "gre-key-len");
+cmdline_parse_token_num_t cmd_global_config_gre_key_len =
+   TOKEN_NUM_INITIALIZER(struct cmd_global_config_result,
+   len, UINT8);
+
+cmdline_parse_inst_t cmd_global_config = {
+   .f = cmd_global_config_parsed,
+   .data = (void *)NULL,
+   .help_str = "global_config  gre-key-len ",
+   .tokens = {
+   (void *)_global_config_cmd,
+   (void *)_global_config_port_id,
+   (void *)_global_config_type,
+   (void *)_global_config_gre_key_len,
+   NULL,
+   },
+};
+
 /* *** CONFIGURE VM MIRROR VLAN/POOL RULE *** */
 struct cmd_set_mirror_mask_result {
cmdline_fixed_string_t set;
@@ -9579,6 +9630,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)_vf_rate_limit,
(cmdline_parse_inst_t *)_tunnel_filter,
(cmdline_parse_inst_t *)_tunnel_udp_config,
+   (cmdline_parse_inst_t *)_global_config,
(cmdline_parse_inst_t *)_set_mirror_mask,
(cmdline_parse_inst_t *)_set_mirror_link,
(cmdline_parse_inst_t *)_reset_mirror_rule,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 75b0a57..957f889 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1812,3 +1812,14 @@ Set the input set for Fdir::
 For example to add source IP to FD input set for flow type of ipv4 on port 0::

testpmd> set_fdir_input_set 0 ipv4 src-ipv4 add
+
+global_config
+~
+
+Set different GRE key length for input set::
+
+   global_config (port_id) gre-key-len (number in bytes)
+
+For example to set GRE key length for input set to 4 bytes on port 0::
+
+   testpmd> global_config 0 gre-key-len 4
-- 
1.9.3

[dpdk-dev] [PATCH v5 1/2] i40e: add selecting GRE key length

[Helin Zhang]

By default, only first 3 bytes of GRE key will be used for hash or FD
calculation. With these changes, it can select 3 or 4 bytes of GRE key
for hash or FD calculation.

Signed-off-by: Helin Zhang 
Signed-off-by: Andrey Chilikin 
---
 doc/guides/rel_notes/release_2_2.rst |  2 +
 drivers/net/i40e/i40e_ethdev.c   | 87 ++--
 lib/librte_ether/rte_eth_ctrl.h  | 20 +
 3 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index f42f0d4..5286233 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -61,6 +61,8 @@ New Features

 * **Added RSS/FD input set granularity on Intel X710/XL710.**

+* **Added selecting different GRE key length for input set on Intel 
X710/XL710.**
+

 Resolved Issues
 ---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 75c368f..3c11a2e 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5597,7 +5597,7 @@ i40e_pf_config_rss(struct i40e_pf *pf)

 static int
 i40e_tunnel_filter_param_check(struct i40e_pf *pf,
-   struct rte_eth_tunnel_filter_conf *filter)
+  struct rte_eth_tunnel_filter_conf *filter)
 {
if (pf == NULL || filter == NULL) {
PMD_DRV_LOG(ERR, "Invalid parameter");
@@ -5629,9 +5629,85 @@ i40e_tunnel_filter_param_check(struct i40e_pf *pf,
return 0;
 }

+#define I40E_GL_PRS_FVBM_MSK_ENA 0x8000
+#define I40E_GL_PRS_FVBM(_i) (0x00269760 + ((_i) * 4))
 static int
-i40e_tunnel_filter_handle(struct rte_eth_dev *dev, enum rte_filter_op 
filter_op,
-   void *arg)
+i40e_dev_set_gre_key_len(struct i40e_hw *hw, uint8_t len)
+{
+   uint32_t val, reg;
+   int ret = -EINVAL;
+
+   val = I40E_READ_REG(hw, I40E_GL_PRS_FVBM(2));
+   PMD_DRV_LOG(DEBUG, "Read original GL_PRS_FVBM with 0x%08x\n", val);
+
+   if (len == 3) {
+   reg = val | I40E_GL_PRS_FVBM_MSK_ENA;
+   } else if (len == 4) {
+   reg = val & ~I40E_GL_PRS_FVBM_MSK_ENA;
+   } else {
+   PMD_DRV_LOG(ERR, "Unsupported GRE key length of %u", len);
+   return ret;
+   }
+
+   if (reg != val) {
+   ret = i40e_aq_debug_write_register(hw, I40E_GL_PRS_FVBM(2),
+  reg, NULL);
+   if (ret != 0)
+   return ret;
+   } else {
+   ret = 0;
+   }
+   PMD_DRV_LOG(DEBUG, "Read modified GL_PRS_FVBM with 0x%08x\n",
+   I40E_READ_REG(hw, I40E_GL_PRS_FVBM(2)));
+
+   return ret;
+}
+
+static int
+i40e_dev_global_config_set(struct i40e_hw *hw, struct rte_eth_global_cfg *cfg)
+{
+   int ret = -EINVAL;
+
+   if (!hw || !cfg)
+   return -EINVAL;
+
+   switch (cfg->cfg_type) {
+   case RTE_ETH_GLOBAL_CFG_TYPE_GRE_KEY_LEN:
+   ret = i40e_dev_set_gre_key_len(hw, cfg->cfg.gre_key_len);
+   break;
+   default:
+   PMD_DRV_LOG(ERR, "Unknown config type %u", cfg->cfg_type);
+   break;
+   }
+
+   return ret;
+}
+
+static int
+i40e_filter_ctrl_global_config(struct rte_eth_dev *dev,
+  enum rte_filter_op filter_op,
+  void *arg)
+{
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   int ret = I40E_ERR_PARAM;
+
+   switch (filter_op) {
+   case RTE_ETH_FILTER_SET:
+   ret = i40e_dev_global_config_set(hw,
+   (struct rte_eth_global_cfg *)arg);
+   break;
+   default:
+   PMD_DRV_LOG(ERR, "unknown operation %u", filter_op);
+   break;
+   }
+
+   return ret;
+}
+
+static int
+i40e_tunnel_filter_handle(struct rte_eth_dev *dev,
+ enum rte_filter_op filter_op,
+ void *arg)
 {
struct rte_eth_tunnel_filter_conf *filter;
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
@@ -5646,6 +5722,7 @@ i40e_tunnel_filter_handle(struct rte_eth_dev *dev, enum 
rte_filter_op filter_op,
case RTE_ETH_FILTER_NOP:
if (!(pf->flags & I40E_FLAG_VXLAN))
ret = I40E_NOT_SUPPORTED;
+   break;
case RTE_ETH_FILTER_ADD:
ret = i40e_dev_tunnel_filter_set(pf, filter, 1);
break;
@@ -6639,6 +6716,10 @@ i40e_dev_filter_ctrl(struct rte_eth_dev *dev,
return -EINVAL;

switch (filter_type) {
+   case RTE_ETH_FILTER_NONE:
+   /* For global configuration */
+   ret = i40e_filter_ctrl_global_config(dev, filter_op, arg);
+   break;
case RTE_ETH_FILTER_HASH:
ret = i40e_hash_filter_ctrl(dev, filter_op, arg);
  

[dpdk-dev] [PATCH v5 0/2] add selecting different GRE key length

[Helin Zhang]

By default, only 3 bytes of GRE key will be used for hash or FD calculation.
Here adds selecting 3 or 4 bytes of GRE key for those purpose.
Note that these patches are based on another patch set of
"[PATCH v8 0/2] i40e: RSS/FD granularity configuration".

v2 changes:
Updated with RSS/FD granularity code.

v3 changes:
Updated with RSS/FD granularity code.
Updated documentation.

v4 changes:
Added the update of release note and testpmd guide to the code patches 
separately.
Updated with RSS/FD granularity code v7.

v5 changes:
Updated with RSS/FD granularity code v8.

Helin Zhang (2):
  i40e: add selecting GRE key length
  app/testpmd: add test commands for selecting different GRE key sizes

 app/test-pmd/cmdline.c  | 52 +
 doc/guides/rel_notes/release_2_2.rst|  2 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 
 drivers/net/i40e/i40e_ethdev.c  | 87 -
 lib/librte_ether/rte_eth_ctrl.h | 20 +++
 5 files changed, 169 insertions(+), 3 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH v8 2/2] app/testpmd: add test commands for RSS/FD granularity

[Helin Zhang]

Test commands are added to support selecting input set, or adding
new input set per different pctype.

Signed-off-by: Helin Zhang 
Signed-off-by: Andrey Chilikin 
---
 app/test-pmd/cmdline.c  | 218 
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  33 +
 2 files changed, 251 insertions(+)

v3 changes:
Support selecting more input set fields.

v4 changes:
Removed operation of 'delete'.
Added test commands for FD granularity.

v7 changes:
Moved the documentation as part of this patch.

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0afdc96..6a384a2 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -692,6 +692,28 @@ static void cmd_help_long_parsed(void *parsed_result,

"ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|l2_payload)"
" (enable|disable)\n"
"Set the global configurations of hash filters.\n\n"
+
+   "set_hash_input_set (port_id) (ipv4|ipv4-frag|"
+   "ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|ipv6|"
+   "ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|"
+   "l2_payload) (ovlan|ivlan|src-ipv4|dst-ipv4|src-ipv6|"
+   "dst-ipv6|ipv4-tos|ipv4-proto|ipv6-tc|"
+   "ipv6-next-header|udp-src-port|udp-dst-port|"
+   "tcp-src-port|tcp-dst-port|sctp-src-port|"
+   "sctp-dst-port|sctp-veri-tag|udp-key|gre-key|fld-1st|"
+   "fld-2nd|fld-3rd|fld-4th|fld-5th|fld-6th|fld-7th|"
+   "fld-8th|none) (select|add)\n"
+   "Set the input set for hash.\n\n"
+
+   "set_fdir_input_set (port_id) (ipv4|ipv4-frag|"
+   "ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|ipv6|"
+   "ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|"
+   "l2_payload) (src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|"
+   "udp-src-port|udp-dst-port|tcp-src-port|tcp-dst-port|"
+   "sctp-src-port|sctp-dst-port|sctp-veri-tag|fld-1st|"
+   "fld-2nd|fld-3rd|fld-4th|fld-5th|fld-6th|fld-7th|"
+   "fld-8th|none) (select|add)\n"
+   "Set the input set for FDir.\n\n"
);
}
 }
@@ -9205,6 +9227,200 @@ cmdline_parse_inst_t cmd_set_hash_global_config = {
},
 };

+/* Set hash input set */
+struct cmd_set_hash_input_set_result {
+   cmdline_fixed_string_t set_hash_input_set;
+   uint8_t port_id;
+   cmdline_fixed_string_t flow_type;
+   cmdline_fixed_string_t inset_field;
+   cmdline_fixed_string_t select;
+};
+
+static enum rte_eth_input_set_field
+str2inset(char *string)
+{
+   uint16_t i;
+
+   static const struct {
+   char str[32];
+   enum rte_eth_input_set_field inset;
+   } inset_table[] = {
+   {"ovlan", RTE_ETH_INPUT_SET_L2_OUTER_VLAN},
+   {"ivlan", RTE_ETH_INPUT_SET_L2_INNER_VLAN},
+   {"src-ipv4", RTE_ETH_INPUT_SET_L3_SRC_IP4},
+   {"dst-ipv4", RTE_ETH_INPUT_SET_L3_DST_IP4},
+   {"ipv4-tos", RTE_ETH_INPUT_SET_L3_IP4_TOS},
+   {"ipv4-proto", RTE_ETH_INPUT_SET_L3_IP4_PROTO},
+   {"src-ipv6", RTE_ETH_INPUT_SET_L3_SRC_IP6},
+   {"dst-ipv6", RTE_ETH_INPUT_SET_L3_DST_IP6},
+   {"ipv6-tc", RTE_ETH_INPUT_SET_L3_IP6_TC},
+   {"ipv6-next-header", RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER},
+   {"udp-src-port", RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT},
+   {"udp-dst-port", RTE_ETH_INPUT_SET_L4_UDP_DST_PORT},
+   {"tcp-src-port", RTE_ETH_INPUT_SET_L4_TCP_SRC_PORT},
+   {"tcp-dst-port", RTE_ETH_INPUT_SET_L4_TCP_DST_PORT},
+   {"sctp-src-port", RTE_ETH_INPUT_SET_L4_SCTP_SRC_PORT},
+   {"sctp-dst-port", RTE_ETH_INPUT_SET_L4_SCTP_DST_PORT},
+   {"sctp-veri-tag", RTE_ETH_INPUT_SET_L4_SCTP_VERIFICATION_TAG},
+   {"udp-key", RTE_ETH_INPUT_SET_TUNNEL_L4_UDP_KEY},
+   {"gre-key", RTE_ETH_INPUT_SET_TUNNEL_GRE_KEY},
+   {"fld-1st", RTE_ETH_INPUT_SET_FLEX_PAYLOAD_1ST_WORD},
+   {"fld-2nd", RTE_ETH_INPUT_SET_FLEX_PAYLOAD_2ND_WORD},
+   {"fld-3rd", RTE_ETH_INPUT_SET_FLEX_PAYLOAD_3RD_WORD},
+   {"fld-4th", RTE_ETH_INPUT_SET_FLEX_PAYLOAD_4TH_WORD},
+   {"fld-5th", RTE_ETH_INPUT_SET_FLEX_PAYLOAD_5TH_WORD},
+   {"fld-6th", RTE_ETH_INPUT_SET_FLEX_PAYLOAD_6TH_WORD},
+   {"fld-7th", RTE_ETH_INPUT_SET_FLEX_PAYLOAD_7TH_WORD},
+   {"fld-8th", RTE_ETH_INPUT_SET_FLEX_PAYLOAD_8TH_WORD},
+   {"none", RTE_ETH_INPUT_SET_NONE},
+   };
+
+   for (i = 0; i < RTE_DIM(inset_table); i++) {
+   if (!strcmp(string, inset_table[i].str))
+  

[dpdk-dev] [PATCH v8 1/2] i40e: RSS/FD granularity configuration

[Helin Zhang]

The default input set of fields of a received packet are loaded from
firmware, which cannot be modified even users want to use different
fields for RSS or flow director. Here adds more flexibilities of
selecting packet fields for hash calculation or flow director for
users.

Signed-off-by: Helin Zhang 
Signed-off-by: Andrey Chilikin 
---
 doc/guides/rel_notes/deprecation.rst |   5 +
 doc/guides/rel_notes/release_2_2.rst |   2 +
 drivers/net/i40e/i40e_ethdev.c   | 742 +++
 drivers/net/i40e/i40e_ethdev.h   |   7 +
 drivers/net/i40e/i40e_fdir.c |  31 ++
 lib/librte_ether/rte_eth_ctrl.h  | 114 +-
 6 files changed, 897 insertions(+), 4 deletions(-)

v2 changes:
Solved the compilation issues.

v3 changes:
Support selecting more input set fields.

v4 changes:
Removed operation of 'delete', as it is not necessary.
Added FD granularity, as it is similar to RSS granularity.

v5 changes:
Fixed issue of generating wrong input set for registers on ipv6-udp and 
ipv6-tcp pc types.
Added clear masking operations during checking if MASK registers are opcupied 
or not.
Reworked several annotations.

v7 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Moved documentation as part of this patch.

v8 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 1 to 128, as ABI changes is allowed in 
ethdev.
Updated release notes.

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index a391ff0..a4c5b51 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -52,3 +52,8 @@ Deprecation Notices
   and table action handlers will be updated:
   the pipeline parameter will be added, the packets mask parameter will be
   either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned in release 2.2 for macro of RTE_ETH_INSET_SIZE_MAX,
+  struct rte_eth_input_set_conf, to support selecting more input set items at
+  a time, and which will affect struct rte_eth_fdir_filter_info and
+  struct rte_eth_hash_filter_info.
diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 8a20044..f42f0d4 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -59,6 +59,8 @@ New Features

 * **Added port hotplug support to xenvirt.**

+* **Added RSS/FD input set granularity on Intel X710/XL710.**
+

 Resolved Issues
 ---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 8381c8e..75c368f 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -139,6 +139,142 @@
 #define I40E_DEFAULT_DCB_APP_NUM1
 #define I40E_DEFAULT_DCB_APP_PRIO   3

+#define I40E_PRTQF_FD_INSET(_i, _j)  (0x0025 + ((_i) * 64 + (_j) * 32))
+#define I40E_GLQF_FD_MSK(_i, _j) (0x00267200 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_FD_MSK_FIELD   0x
+#define I40E_GLQF_HASH_INSET(_i, _j) (0x00267600 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_HASH_MSK(_i, _j)   (0x00267A00 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_HASH_MSK_FIELD  0x
+
+#define I40E_INSET_NONE0x0ULL
+
+/* bit0 ~ bit 7 */
+#define I40E_INSET_DMAC0x0001ULL
+#define I40E_INSET_SMAC0x0002ULL
+#define I40E_INSET_VLAN_OUTER  0x0004ULL
+#define I40E_INSET_VLAN_INNER  0x0008ULL
+#define I40E_INSET_VLAN_TUNNEL 0x0010ULL
+
+/* bit 8 ~ bit 15 */
+#define I40E_INSET_IPV4_SRC0x0100ULL
+#define I40E_INSET_IPV4_DST0x0200ULL
+#define I40E_INSET_IPV6_SRC0x0400ULL
+#define I40E_INSET_IPV6_DST0x0800ULL
+#define I40E_INSET_SRC_PORT0x1000ULL
+#define I40E_INSET_DST_PORT0x2000ULL
+#define I40E_INSET_SCTP_VT 0x4000ULL
+
+/* bit 16 ~ bit 31 */
+#define I40E_INSET_IPV4_TOS0x0001ULL
+#define I40E_INSET_IPV4_PROTO  0x0002ULL
+#define I40E_INSET_IPV4_TTL0x0004ULL
+#define I40E_INSET_IPV6_TC 0x0008ULL
+#define I40E_INSET_IPV6_FLOW   0x0010ULL
+#define I40E_INSET_IPV6_NEXT_HDR   0x0020ULL
+#define I40E_INSET_IPV6_HOP_LIMIT  0x0040ULL
+#define I40E_INSET_TCP_FLAGS   0x0080ULL
+
+/* bit 32 ~ bit 47, tunnel fields */
+#define I40E_INSET_TUNNEL_IPV4_DST   0x0001ULL
+#define I40E_INSET_TUNNEL_IPV6_DST   0x0002ULL
+#define I40E_INSET_TUNNEL_DMAC   0x0004ULL
+#define I40E_INSET_TUNNEL_SRC_PORT   0x0008ULL
+#define I40E_INSET_TUNNEL_DST_PORT   0x0010ULL
+#define I40E_INSET_TUNNEL_ID 0x0020ULL
+
+/* bit 48 ~ bit 55 */
+#define I40E_INSET_LAST_ETHER_TYPE 0x0001ULL
+
+/* bit 56 ~ bit 63, Flex 

[dpdk-dev] [PATCH v8 0/2] i40e: RSS/FD granularity configuration

[Helin Zhang]

The default input set of fields of a received packet are loaded from firmware,
which cannot be modified even users want to use different fields for RSS or flow
director. Here adds more flexibilities of selecting or adding packet fields for
hash calculation or flow director to users. It also includes the modifications
in testpmd to support the testing.

v2 changes:
Solved the compilation issues.

v3 changes:
Support selecting more input set fields.

v4 changes:
Removed operation of 'delete', as it is not necessary.
Added FD granularity in both pmd and testpmd, as it is similar to RSS 
granularity.

v5 changes:
Fixed issue of generating wrong input set for registers on ipv6-udp and 
ipv6-tcp pc types.
Added clear masking operations during checking if MASK registers are opcupied 
or not.
Reworked several annotations.

v6 changes:
Updated documentation.

v7 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Split documentation into pieces and put them directly into the patch of code 
changes directly.

v8 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 1 to 128, as ABI changes is allowed in 
ethdev.
Updated release notes.

Helin Zhang (2):
  i40e: RSS/FD granularity configuration
  app/testpmd: add test commands for RSS/FD granularity

 app/test-pmd/cmdline.c  | 218 
 doc/guides/rel_notes/deprecation.rst|   5 +
 doc/guides/rel_notes/release_2_2.rst|   2 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  33 ++
 drivers/net/i40e/i40e_ethdev.c  | 742 
 drivers/net/i40e/i40e_ethdev.h  |   7 +
 drivers/net/i40e/i40e_fdir.c|  31 ++
 lib/librte_ether/rte_eth_ctrl.h | 114 -
 8 files changed, 1148 insertions(+), 4 deletions(-)

-- 
1.9.3

[dpdk-dev] Reshuffling of rte_mbuf structure.

[shesha Sreenivasamurthy (shesha)]

Ok, You are saying re-order the fields based on the configurations params. I 
took word "NO" in the param to eliminate. Sure, this does not require and 
change in the code that uses it. Will it not now boil down to same as having 
completely different layout definition and be more messier ?

For example: Rather than having:

#ifdef NO_TX_OFFLOAD
Struct mbuf_rte {
fieldA
field1
field2
fieldB
field4
filed5
};
#endif

#ifdef NO_MULTISEG
Struct mbuf_rte{
fieldA
field2
field1
fieldB
filed5
field4
}
#endif

We end up having

Struct mbuf_rte {
fieldA
#ifdef NO_TX_OFFLOAD
field1
field2
#endif
#ifdef NO_MULTISEG
field2
field1
#endif
fieldB
#ifdef NO_TX_OFFLOAD
field4
field5
#endif
#ifdef NO_MULTISEG
field5
field4
#endif
};



--
- Thanks
char * (*shesha) (uint64_t cache, uint8_t F00D)
{ return 0xC0DE; }

From: Arnon Warshavsky mailto:ar...@qwilt.com>>
Date: Monday, November 2, 2015 at 10:35 AM
To: Cisco Employee mailto:shesha at cisco.com>>
Cc: Stephen Hemminger mailto:stephen at 
networkplumber.org>>, "dev at dpdk.org" mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure.

If NO_TX_OFFLOAD only changes the layout in terms of relative field location in 
cache lines, and does not eliminate the fields themselves
why should the using code be affected?

On Mon, Nov 2, 2015 at 8:30 PM, shesha Sreenivasamurthy (shesha) mailto:shesha at cisco.com>> wrote:
One issue I see with optimization config options such as NO_TX_OFFLOAD, 
NO_MULTISEG, NO_REFCOUNT is: It is not sufficient to have those "Ifdefs" inside 
mbuf structure, but should be sprinkled all over the code where corresponding 
fields are used. This may make the code messier.

--
- Thanks
char * (*shesha) (uint64_t cache, uint8_t F00D)
{ return 0xC0DE; }

From: Stephen Hemminger mailto:step...@networkplumber.org>>
Date: Monday, November 2, 2015 at 8:24 AM
To: Arnon Warshavsky mailto:arnon at qwilt.com>>
Cc: Cisco Employee mailto:shesha at cisco.com>>, "dev at 
dpdk.org" mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure.

On Sun, 1 Nov 2015 06:45:31 +0200
Arnon Warshavsky mailto:arnon at qwilt.com>> wrote:

My 2 cents,
This was brought up in the recent user space summit, and it seems that
indeed there is no one cache lines arrangement that fits all.
OTOH multiple compile time options to suffice all flavors, would make it
unpleasant to read maintain test and debug.
(I think there was quiet a consensus in favor of reducing compile options
in general)
Currently I manage similar deviations via our own source control which I
admit to be quite a pain.
I would prefer an option of code manipulation/generation by some script
during dpdk install,
which takes the default version of rte_mbuf.h,
along with an optional user file (json,xml,elvish,whatever) defining the
structure replacements,
creating your custom version, and placing it instead of the installed copy
of rte_mbuf.h.
Maybe the only facility required from dpdk is just the ability to register
calls to such user scripts at some install stage(s), providing the mean
along with responsibility to the user.
/Arnon
On Sat, Oct 31, 2015 at 6:44 AM, shesha Sreenivasamurthy (shesha) <
shesha at cisco.com> wrote:
> In Cisco, we are using DPDK for a very high speed packet processor
> application. We don't use NIC TCP offload / RSS hashing. Putting those
> fields in the first cache-line - and the obligatory mb->next datum in the
> second cache line - causes significant LSU pressure and performance
> degradation. If it does not affect other applications, I would like to
> propose reshuffling of fields so that the obligator "next" field falls in
> first cache line and RSS hashing goes to next. If this re-shuffling indeed
> hurts other applications, another idea is to make it compile time
> configurable. Please provide feedback.
>
> --
> - Thanks
> char * (*shesha) (uint64_t cache, uint8_t F00D)
> { return 0xC0DE; }
>

Having different layouts will be a disaster for distro's they have to choose 
one.
And I hate to introduce more configuration!

But we see the same issue. It would make sense if there were configuration 
options
for some common optimizations NO_TX_OFFLOAD, NO_MULTISEG, NO_REFCOUNT and then
the mbuf got optimized for those combinations. Seems better than config options
like LAYOUT1, LAYOUT2, ...

In this specific case, I think lots of driver could be check nb_segs == 1 and 
avoiding
the next field for simple packets.

Long term, I think this will be losing battle. As DPDK grows more features, the 
current
mbuf structure will grow there is really nothing stopping the bloat of meta 
data.




--

Arnon Warshavsky
Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at 
qwilt.com

[dpdk-dev] [PATCH 2/3] arm64: acl: add neon based acl implementation

[Jerin Jacob]

On Mon, Nov 02, 2015 at 04:39:37PM +0100, Jan Viktorin wrote:
> On Mon, 2 Nov 2015 19:48:40 +0530
> Jerin Jacob  wrote:
> 
> > Signed-off-by: Jerin Jacob 
> > ---
> >  app/test-acl/main.c   |   4 +
> >  lib/librte_acl/Makefile   |   5 +
> >  lib/librte_acl/acl.h  |   4 +
> >  lib/librte_acl/acl_run_neon.c |  46 +++
> >  lib/librte_acl/acl_run_neon.h | 290 
> > ++
> >  lib/librte_acl/rte_acl.c  |  25 
> >  lib/librte_acl/rte_acl.h  |   1 +
> >  7 files changed, 375 insertions(+)
> >  create mode 100644 lib/librte_acl/acl_run_neon.c
> >  create mode 100644 lib/librte_acl/acl_run_neon.h
> > 
> > diff --git a/app/test-acl/main.c b/app/test-acl/main.c
> > index 72ce83c..0b0c093 100644
> > --- a/app/test-acl/main.c
> > +++ b/app/test-acl/main.c
> > @@ -101,6 +101,10 @@ static const struct acl_alg acl_alg[] = {
> > .name = "avx2",
> > .alg = RTE_ACL_CLASSIFY_AVX2,
> > },
> > +   {
> > +   .name = "neon",
> > +   .alg = RTE_ACL_CLASSIFY_NEON,
> > +   },
> >  };
> >  
> >  static struct {
> > diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
> > index 7a1cf8a..27f91d5 100644
> > --- a/lib/librte_acl/Makefile
> > +++ b/lib/librte_acl/Makefile
> > @@ -48,9 +48,14 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += rte_acl.c
> >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c
> >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c
> >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c
> > +ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
> > +SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_neon.c
> 
> Are the used NEON instrinsics for ACL ARMv8-specific? If so, the file should 
> be named
> something like acl_run_neonv8.c...
> 

Yes, bit of armv8 specific, looks like vqtbl1q_u8 NEON instrinsics
defined only in armv8. I could rename to acl_run_neonv8.c but keeping
as acl_run_neon.c, may in future it can be extend to armv7 also.
I am open to any decision, let me know your views.

> > +else
> >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_sse.c
> > +endif
> >  
> >  CFLAGS_acl_run_sse.o += -msse4.1
> > +CFLAGS_acl_run_neon.o += -flax-vector-conversions -Wno-maybe-uninitialized
> 
> From man gcc:
> 
> -flax-vector-conversions
>  Allow implicit conversions between vectors with differing numbers of 
> elements and/or
>  incompatible element types.  This option should not be used for new code.
> 
> I've already pointed to this in the Dave's ARMv8 patchset. They dropped it 
> silently.
> What is the purpose? Is it necessary?

Yes, the same tr hi value we can representing as unsigned and signed
based on it DFA or QRANGE .


> 
> Jan
> 
> >  
> >  #
> >  # If the compiler supports AVX2 instructions,
> > diff --git a/lib/librte_acl/acl.h b/lib/librte_acl/acl.h
> > index eb4930c..09d6784 100644
> > --- a/lib/librte_acl/acl.h
> > +++ b/lib/librte_acl/acl.h
> > @@ -230,6 +230,10 @@ int
> >  rte_acl_classify_avx2(const struct rte_acl_ctx *ctx, const uint8_t **data,
> > uint32_t *results, uint32_t num, uint32_t categories);
> >  
> --snip--
> 
> -- 
>Jan Viktorin  E-mail: Viktorin at RehiveTech.com
>System Architect  Web:www.RehiveTech.com
>RehiveTech
>Brno, Czech Republic

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bagh Fares
> Sent: Monday, November 2, 2015 6:03 PM
> To: Dave Neary; CHIOSI, MARGARET T; Stephen Hemminger
> Cc: dev at dpdk.org; Pradeep Kathail (pkathail at cisco.com)
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> DPDK Userspace (was Notes from ...)
> 
> Yes. Thank you. What we like is to get to a point where we discuss API
> and align on APIs for SOC as Margaret mention. As you know Arm has been
> driving ODP as the API for SOC.
> What we like to do is to drive the APIs under DPDK even for Arm SOC.
> Long term, and based on shrinking silicon geometries, and desire to fill
> fabs, Intel will do more SOCs. I was SOC design manager in Intel :-)
> We like to spare the customers like red hat, Cisco, and ATT the pain of
> supporting multiple APIs and code bases.

That's our goal too, so it's good to hear that we're in agreement on this.

> So we need have a forum/place where this can be worked at .

If you have some ideas, then the best way to get some discussion going is 
through the mailing list. You could post a set of patches for proposed changes, 
a higher-level RFC outlining your thoughts, or just specific questions/issues 
that you see.

On the TSC that was specifically referenced earlier in this thread, there is a 
proposal for what we're now calling the Architecture Board at: 
http://dpdk.org/ml/archives/dev/2015-October/026598.html. As Dave mentioned, we 
agreed at our recent Userspace event in Dublin that membership of the board 
should be based on contributions and technical standing in the community. The 
board will review and approve new members on an annual basis.

> We are reaching out and we like to feel welcome and some love :-)

As Thomas already said, new contributors are always welcome!


Tim


> 
> -Original Message-
> From: Dave Neary [mailto:dneary at redhat.com]
> Sent: Monday, November 02, 2015 11:55 AM
> To: Bagh Fares-B25033 ; CHIOSI, MARGARET T
> ; Stephen Hemminger 
> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail
> (pkathail at cisco.com) 
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> DPDK Userspace (was Notes from ...)
> 
> Hi,
> 
> On the contrary! I am aware that Freescale has been engaged for some
> time in DPDK. I was responding to Margaret's contention that future
> contributors (and she called out ARM and SOC vendors) should have a
> voice.
> 
> I hope that clarifies my position and meaning.
> 
> Thanks,
> Dave.
> 
> On 11/02/2015 12:44 PM, Bagh Fares wrote:
> > As SOC vendor we will contribute heavily to the project. Example
> crypto acceleration. We already contribute a lot to the linux community.
> > So not sure why the doubt about of contribution?
> >
> >
> > -Original Message-
> > From: Dave Neary [mailto:dneary at redhat.com]
> > Sent: Monday, November 02, 2015 11:31 AM
> > To: CHIOSI, MARGARET T ; Stephen Hemminger
> > ; Bagh Fares-B25033
> > 
> > Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail
> > (pkathail at cisco.com) 
> > Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> > DPDK Userspace (was Notes from ...)
> >
> > Hi Margaret,
> >
> > On 11/02/2015 12:28 PM, CHIOSI, MARGARET T wrote:
> >> I think it is very important for the first version of governance that
> we have ARM/SOC vendor/future contributors to be part of TSC.
> >> If based on historical contribution - they will be at a disadvantage.
> >> We need to have the DPDK organization support an API which supports a
> broader set of chips.
> >
> > I think there is definitely a role for SOC vendors in the project
> governance, but the TSC should be representative of the technical
> contributors to the project, rather than an aspirational body aiming to
> get more people involved.
> >
> > I think there is an opportunity for future contributors/users to form
> a powerful constituency in the project, but the TSC is not the right
> place for that to happen IMHO.
> >
> > Thanks,
> > Dave.
> >
> >> -Original Message-
> >> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> >> Sent: Monday, November 02, 2015 12:22 PM
> >> To: Bagh Fares
> >> Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; 
> >> Pradeep
> >> Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
> >> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> >> DPDK Userspace (was Notes from ...)
> >>
> >> There were two outcomes.
> >>
> >> One was a proposal to move governance under Linux Foundation.
> >>
> >> The other was to have a technical steering committee.
> >> It was agreed the TSC would be based on the contributors to the
> >> project, although we didn't come to a conclusion on a voting model.
> >>
> >>
> >> I would propose that TSC should be elected at regular user summit
> >> from nominees; in a manner similar to LF Technical Advisory Board.
> >>
> >
> > --
> > Dave Neary - 

[dpdk-dev] Reshuffling of rte_mbuf structure.

[Arnon Warshavsky]

If NO_TX_OFFLOAD only changes the layout in terms of relative field
location in cache lines, and does not eliminate the fields themselves
why should the using code be affected?

On Mon, Nov 2, 2015 at 8:30 PM, shesha Sreenivasamurthy (shesha) <
shesha at cisco.com> wrote:

> One issue I see with optimization config options such as NO_TX_OFFLOAD,
> NO_MULTISEG, NO_REFCOUNT is: It is not sufficient to have those ?Ifdefs?
> inside mbuf structure, but should be sprinkled all over the code where
> corresponding fields are used. This may make the code messier.
>
> --
> *- Thanks*
> *char * (*shesha) (uint64_t cache, uint8_t F00D)*
> *{ return 0xC0DE; } *
>
> From: Stephen Hemminger 
> Date: Monday, November 2, 2015 at 8:24 AM
> To: Arnon Warshavsky 
> Cc: Cisco Employee , "dev at dpdk.org" 
> Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure.
>
> On Sun, 1 Nov 2015 06:45:31 +0200
> Arnon Warshavsky  wrote:
>
> My 2 cents,
> This was brought up in the recent user space summit, and it seems that
> indeed there is no one cache lines arrangement that fits all.
> OTOH multiple compile time options to suffice all flavors, would make it
> unpleasant to read maintain test and debug.
> (I think there was quiet a consensus in favor of reducing compile options
> in general)
> Currently I manage similar deviations via our own source control which I
> admit to be quite a pain.
> I would prefer an option of code manipulation/generation by some script
> during dpdk install,
> which takes the default version of rte_mbuf.h,
> along with an optional user file (json,xml,elvish,whatever) defining the
> structure replacements,
> creating your custom version, and placing it instead of the installed copy
> of rte_mbuf.h.
> Maybe the only facility required from dpdk is just the ability to register
> calls to such user scripts at some install stage(s), providing the mean
> along with responsibility to the user.
> /Arnon
> On Sat, Oct 31, 2015 at 6:44 AM, shesha Sreenivasamurthy (shesha) <
> shesha at cisco.com> wrote:
> > In Cisco, we are using DPDK for a very high speed packet processor
> > application. We don't use NIC TCP offload / RSS hashing. Putting those
> > fields in the first cache-line - and the obligatory mb->next datum in the
> > second cache line - causes significant LSU pressure and performance
> > degradation. If it does not affect other applications, I would like to
> > propose reshuffling of fields so that the obligator "next" field falls in
> > first cache line and RSS hashing goes to next. If this re-shuffling
> indeed
> > hurts other applications, another idea is to make it compile time
> > configurable. Please provide feedback.
> >
> > --
> > - Thanks
> > char * (*shesha) (uint64_t cache, uint8_t F00D)
> > { return 0xC0DE; }
> >
>
>
> Having different layouts will be a disaster for distro's they have to
> choose one.
> And I hate to introduce more configuration!
>
> But we see the same issue. It would make sense if there were configuration
> options
> for some common optimizations NO_TX_OFFLOAD, NO_MULTISEG, NO_REFCOUNT and
> then
> the mbuf got optimized for those combinations. Seems better than config
> options
> like LAYOUT1, LAYOUT2, ...
>
> In this specific case, I think lots of driver could be check nb_segs == 1
> and avoiding
> the next field for simple packets.
>
> Long term, I think this will be losing battle. As DPDK grows more
> features, the current
> mbuf structure will grow there is really nothing stopping the bloat of
> meta data.
>
>


-- 

*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*

[dpdk-dev] [PATCH 3/3] arm64: defconfig: enabled CONFIG_RTE_LIBRTE_ACL

[Jerin Jacob]

Signed-off-by: Jerin Jacob 
---
 config/defconfig_arm64-armv8a-linuxapp-gcc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 79a9533..3e3bf12 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -48,7 +48,6 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
 CONFIG_RTE_LIBRTE_EAL_HOTPLUG=n

 CONFIG_RTE_LIBRTE_LPM=n
-CONFIG_RTE_LIBRTE_ACL=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n

-- 
2.1.0

[dpdk-dev] [PATCH 2/3] arm64: acl: add neon based acl implementation

[Jerin Jacob]

Signed-off-by: Jerin Jacob 
---
 app/test-acl/main.c   |   4 +
 lib/librte_acl/Makefile   |   5 +
 lib/librte_acl/acl.h  |   4 +
 lib/librte_acl/acl_run_neon.c |  46 +++
 lib/librte_acl/acl_run_neon.h | 290 ++
 lib/librte_acl/rte_acl.c  |  25 
 lib/librte_acl/rte_acl.h  |   1 +
 7 files changed, 375 insertions(+)
 create mode 100644 lib/librte_acl/acl_run_neon.c
 create mode 100644 lib/librte_acl/acl_run_neon.h

diff --git a/app/test-acl/main.c b/app/test-acl/main.c
index 72ce83c..0b0c093 100644
--- a/app/test-acl/main.c
+++ b/app/test-acl/main.c
@@ -101,6 +101,10 @@ static const struct acl_alg acl_alg[] = {
.name = "avx2",
.alg = RTE_ACL_CLASSIFY_AVX2,
},
+   {
+   .name = "neon",
+   .alg = RTE_ACL_CLASSIFY_NEON,
+   },
 };

 static struct {
diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
index 7a1cf8a..27f91d5 100644
--- a/lib/librte_acl/Makefile
+++ b/lib/librte_acl/Makefile
@@ -48,9 +48,14 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += rte_acl.c
 SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c
 SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c
 SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c
+ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
+SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_neon.c
+else
 SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_sse.c
+endif

 CFLAGS_acl_run_sse.o += -msse4.1
+CFLAGS_acl_run_neon.o += -flax-vector-conversions -Wno-maybe-uninitialized

 #
 # If the compiler supports AVX2 instructions,
diff --git a/lib/librte_acl/acl.h b/lib/librte_acl/acl.h
index eb4930c..09d6784 100644
--- a/lib/librte_acl/acl.h
+++ b/lib/librte_acl/acl.h
@@ -230,6 +230,10 @@ int
 rte_acl_classify_avx2(const struct rte_acl_ctx *ctx, const uint8_t **data,
uint32_t *results, uint32_t num, uint32_t categories);

+int
+rte_acl_classify_neon(const struct rte_acl_ctx *ctx, const uint8_t **data,
+   uint32_t *results, uint32_t num, uint32_t categories);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/lib/librte_acl/acl_run_neon.c b/lib/librte_acl/acl_run_neon.c
new file mode 100644
index 000..b014451
--- /dev/null
+++ b/lib/librte_acl/acl_run_neon.c
@@ -0,0 +1,46 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) Cavium networks Ltd. 2015.
+ *
+ *   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 Cavium networks 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.
+*/
+
+#include "acl_run_neon.h"
+
+int
+rte_acl_classify_neon(const struct rte_acl_ctx *ctx, const uint8_t **data,
+ uint32_t *results, uint32_t num, uint32_t categories)
+{
+   if (likely(num >= 8))
+   return search_neon_8(ctx, data, results, num, categories);
+   else if (num >= 4)
+   return search_neon_4(ctx, data, results, num, categories);
+   else
+   return rte_acl_classify_scalar(ctx, data, results, num,
+   categories);
+}
diff --git a/lib/librte_acl/acl_run_neon.h b/lib/librte_acl/acl_run_neon.h
new file mode 100644
index 000..4579476
--- /dev/null
+++ b/lib/librte_acl/acl_run_neon.h
@@ -0,0 +1,290 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) Cavium networks Ltd. 2015.
+ *
+ *   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 

[dpdk-dev] [PATCH 1/3] arm: ret_vector.h improvements

[Jerin Jacob]

added the definition of rte_xmm and xmm_t for acl noen implementation
removed the emulated _mm_* functions

Signed-off-by: Jerin Jacob 
---
 lib/librte_eal/common/include/arch/arm/rte_vect.h | 58 +++
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h 
b/lib/librte_eal/common/include/arch/arm/rte_vect.h
index 7d5de97..21cdb4d 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2015 RehiveTech. All rights reserved.
+ *   Copyright(c) 2015 Cavium Networks. All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
@@ -13,7 +13,7 @@
  *   notice, this list of conditions and the following disclaimer in
  *   the documentation and/or other materials provided with the
  *   distribution.
- * * Neither the name of RehiveTech nor the names of its
+ * * Neither the name of Cavium Networks nor the names of its
  *   contributors may be used to endorse or promote products derived
  *   from this software without specific prior written permission.
  *
@@ -33,49 +33,25 @@
 #ifndef _RTE_VECT_ARM_H_
 #define _RTE_VECT_ARM_H_

+#include "arm_neon.h"
+
 #ifdef __cplusplus
 extern "C" {
 #endif

-#define XMM_SIZE 16
-#define XMM_MASK (XMM_MASK - 1)
-
-typedef struct {
-   union uint128 {
-   uint8_t uint8[16];
-   uint32_t uint32[4];
-   } val;
-} __m128i;
-
-static inline __m128i
-_mm_set_epi32(uint32_t v0, uint32_t v1, uint32_t v2, uint32_t v3)
-{
-   __m128i res;
-
-   res.val.uint32[0] = v0;
-   res.val.uint32[1] = v1;
-   res.val.uint32[2] = v2;
-   res.val.uint32[3] = v3;
-   return res;
-}
-
-static inline __m128i
-_mm_loadu_si128(__m128i *v)
-{
-   __m128i res;
-
-   res = *v;
-   return res;
-}
-
-static inline __m128i
-_mm_load_si128(__m128i *v)
-{
-   __m128i res;
-
-   res = *v;
-   return res;
-}
+typedef int32x4_t xmm_t;
+
+#defineXMM_SIZE(sizeof(xmm_t))
+#defineXMM_MASK(XMM_SIZE - 1)
+
+typedef union rte_xmm {
+   xmm_tx;
+   uint8_t  u8[XMM_SIZE / sizeof(uint8_t)];
+   uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
+   uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
+   uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
+   double   pd[XMM_SIZE / sizeof(double)];
+} __attribute__((aligned(16))) rte_xmm_t;

 #ifdef __cplusplus
 }
-- 
2.1.0

[dpdk-dev] [PATCH 0/3] ARM64: NEON ACL implementation

[Jerin Jacob]

ARM64 Neon based ACL implementation

This patch is based on David's armv8 v3 patch set


Jerin Jacob (3):
  arm: ret_vector.h improvements
  arm64: acl: add neon based acl implementation
  arm64: defconfig: enabled CONFIG_RTE_LIBRTE_ACL

 app/test-acl/main.c   |   4 +
 config/defconfig_arm64-armv8a-linuxapp-gcc|   1 -
 lib/librte_acl/Makefile   |   5 +
 lib/librte_acl/acl.h  |   4 +
 lib/librte_acl/acl_run_neon.c |  46 
 lib/librte_acl/acl_run_neon.h | 290 ++
 lib/librte_acl/rte_acl.c  |  25 ++
 lib/librte_acl/rte_acl.h  |   1 +
 lib/librte_eal/common/include/arch/arm/rte_vect.h |  58 ++---
 9 files changed, 392 insertions(+), 42 deletions(-)
 create mode 100644 lib/librte_acl/acl_run_neon.c
 create mode 100644 lib/librte_acl/acl_run_neon.h

-- 
2.1.0

[dpdk-dev] [PATCH v2 09/13] mlx5: add link update device operation

[Adrien Mazarguil]

On Mon, Nov 02, 2015 at 09:52:17AM -0800, Stephen Hemminger wrote:
> On Fri, 30 Oct 2015 19:52:38 +0100
> Adrien Mazarguil  wrote:
> 
> > +static int
> > +mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
> > +{
> > +   struct priv *priv = dev->data->dev_private;
> > +   struct ethtool_cmd edata = {
> > +   .cmd = ETHTOOL_GSET
> > +   };
> > +   struct ifreq ifr;
> > +   struct rte_eth_link dev_link;
> > +   int link_speed = 0;
> > +
> > +   (void)wait_to_complete;
> 
> DPDK style is to use the __rte_unused attribute rather than dummy statements
> to avoid unused warnings.

Thanks for pointing this out, I'm used to avoiding C extensions whenever
possible but will stick to DPDK style next time.

Still, it would be nice if we could steer DPDK away from such extensions as
much as possible. As a library, we should allow user applications to compile
with flags we can't control (such as -pedantic -std=c99, and various
-Wsomething).

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] Reshuffling of rte_mbuf structure.

[Matthew Hall]

On Mon, Nov 02, 2015 at 11:51:23PM +0100, Thomas Monjalon wrote:
> But it is simpler to say that having an API depending of some options
> is a "no-design" which could seriously slow down the DPDK adoption.

What about something similar to how Java JNI works? It needed to support 
multiple Java JRE / JDK brands, implementations etc. Upon initialization, a 
function pointer array is created, and specific slots are filled with pointers 
to the real implementation of some native API functions you can call from 
inside your library to perform operations.

In the DPDK case, we need flexible data instead of flexible function 
implementations.

To do this there would be some pointer slots in the mbuf that are are filled 
with pointers to metadata for required DPDK features. The data could be placed 
in the following cachelines, using some reserved tailroom between the mbuf 
control block and the packet data block. Then the prefetch could be set up to 
prefetch only the used parts of the tailroom at any given point, to prevent 
unwanted slowdowns.

Matthew.

[dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library

[Ferruh Yigit]

On Mon, Nov 02, 2015 at 05:26:21PM +0100, Thomas Monjalon wrote:
> 2015-11-02 15:23, Ferruh Yigit:
> > +ifeq ($(COMBINED_BUILD),1)
> >  include $(RTE_SDK)/mk/rte.sharelib.mk
> > +endif
> 
> Why this ifeq?
> rte.sharelib.mk is always used for combined lib.
> 

When combine lib config selected, other libraries still build
And all libraris include sharelib.mk
This cause CPU_LDFLAGS conflict, the CPU_LDFLAGS set specially for combined lib 
used by all libraries.

When not linking combined library, there is no need/benefit of including 
sharelib.mk
COMBINED_BUILD only set when linking combined library and that is when 
sharelib.mk included

I can try to prevent linking other libraries when combined library enabled, 
then sharelib.mk included only for combined lib, and we can remove that check.
But I am not sure how hard it is, and does it worth spending extra effort to it?

Thanks,
ferruh

[dpdk-dev] [PATCH v3] mlx5: RETA query/update support

[Adrien Mazarguil]

From: Nelio Laranjeiro 

ConnectX-4 adapters to not have a constant indirection table size, which is
set at runtime from the number of RX queues. The maximum size is retrieved
using a hardware query and is normally 512.

Since the current RETA API cannot handle a variable size, any query/update
command causes it to be silently updated to RSS_INDIRECTION_TABLE_SIZE
entries regardless of the original size.

Also due to the underlying type of the configuration structure, the maximum
size is limited to RSS_INDIRECTION_TABLE_SIZE (currently 128, at most 256
entries).

A port stop/start must be done to apply the new RETA configuration.

Signed-off-by: Nelio Laranjeiro 
---
 drivers/net/mlx5/mlx5.c|   8 +-
 drivers/net/mlx5/mlx5.h|   7 ++
 drivers/net/mlx5/mlx5_ethdev.c |  29 
 drivers/net/mlx5/mlx5_rss.c| 163 +
 drivers/net/mlx5/mlx5_rxq.c|  53 ++
 drivers/net/mlx5/mlx5_utils.h  |  20 +
 6 files changed, 234 insertions(+), 46 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 9636588..5a95260 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -133,6 +133,8 @@ mlx5_dev_close(struct rte_eth_dev *dev)
rte_free((*priv->rss_conf)[i]);
rte_free(priv->rss_conf);
}
+   if (priv->reta_idx != NULL)
+   rte_free(priv->reta_idx);
priv_unlock(priv);
memset(priv, 0, sizeof(*priv));
 }
@@ -160,6 +162,8 @@ static const struct eth_dev_ops mlx5_dev_ops = {
.mac_addr_remove = mlx5_mac_addr_remove,
.mac_addr_add = mlx5_mac_addr_add,
.mtu_set = mlx5_dev_set_mtu,
+   .reta_update = mlx5_dev_rss_reta_update,
+   .reta_query = mlx5_dev_rss_reta_query,
.rss_hash_update = mlx5_rss_hash_update,
.rss_hash_conf_get = mlx5_rss_hash_conf_get,
 };
@@ -373,7 +377,9 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)
DEBUG("L2 tunnel checksum offloads are %ssupported",
  (priv->hw_csum_l2tun ? "" : "not "));

-   priv->ind_table_max_size = 
exp_device_attr.rx_hash_caps.max_rwq_indirection_table_size;
+   priv->ind_table_max_size =
+   RTE_MIN((unsigned int)RSS_INDIRECTION_TABLE_SIZE,
+   
exp_device_attr.rx_hash_caps.max_rwq_indirection_table_size);
DEBUG("maximum RX indirection table size is %u",
  priv->ind_table_max_size);

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 0daacc8..b84d31d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -118,6 +118,8 @@ struct priv {
/* RSS configuration array indexed by hash RX queue type. */
struct rte_eth_rss_conf *(*rss_conf)[];
struct rte_intr_handle intr_handle; /* Interrupt handler. */
+   unsigned int (*reta_idx)[]; /* RETA index table. */
+   unsigned int reta_idx_n; /* RETA index size. */
rte_spinlock_t lock; /* Lock for control functions. */
 };

@@ -184,6 +186,11 @@ int rss_hash_rss_conf_new_key(struct priv *, const uint8_t 
*, unsigned int,
  uint64_t);
 int mlx5_rss_hash_update(struct rte_eth_dev *, struct rte_eth_rss_conf *);
 int mlx5_rss_hash_conf_get(struct rte_eth_dev *, struct rte_eth_rss_conf *);
+int priv_rss_reta_index_resize(struct priv *, unsigned int);
+int mlx5_dev_rss_reta_query(struct rte_eth_dev *,
+   struct rte_eth_rss_reta_entry64 *, uint16_t);
+int mlx5_dev_rss_reta_update(struct rte_eth_dev *,
+struct rte_eth_rss_reta_entry64 *, uint16_t);

 /* mlx5_rxmode.c */

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 84e877c..1159fa3 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -410,6 +410,9 @@ dev_configure(struct rte_eth_dev *dev)
struct priv *priv = dev->data->dev_private;
unsigned int rxqs_n = dev->data->nb_rx_queues;
unsigned int txqs_n = dev->data->nb_tx_queues;
+   unsigned int i;
+   unsigned int j;
+   unsigned int reta_idx_n;

priv->rxqs = (void *)dev->data->rx_queues;
priv->txqs = (void *)dev->data->tx_queues;
@@ -418,11 +421,31 @@ dev_configure(struct rte_eth_dev *dev)
 (void *)dev, priv->txqs_n, txqs_n);
priv->txqs_n = txqs_n;
}
+   if (rxqs_n > priv->ind_table_max_size) {
+   ERROR("cannot handle this many RX queues (%u)", rxqs_n);
+   return EINVAL;
+   }
if (rxqs_n == priv->rxqs_n)
return 0;
INFO("%p: RX queues number update: %u -> %u",
 (void *)dev, priv->rxqs_n, rxqs_n);
priv->rxqs_n = rxqs_n;
+   /* If the requested number of RX queues is not a power of two, use the
+* maximum 

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Thomas Monjalon]

Hi,

It is really great to see various companies desiring to be part of the project.

2015-11-02 17:44, Bagh Fares:
> As SOC vendor we will contribute heavily to the project. Example crypto 
> acceleration.
> We already contribute a lot to the linux community.
> So not sure why the doubt about of contribution?

I think there is no doubt and you are very welcome.

It is planned (in the proposal) to welcome regularly some new contributors in 
the board.

[dpdk-dev] [PATCH v3 6/6] test: add checks for cpu flags on armv8

[Jerin Jacob]

On Mon, Nov 02, 2015 at 10:47:53AM +, Hunt, David wrote:
> On 02/11/2015 06:32, Jerin Jacob wrote:
> >On Fri, Oct 30, 2015 at 04:28:25PM +, Hunt, David wrote:
>
> --snip--
>
> >
> >Hi Jan and Dave,
> >
> >I have reviewed your patches for arm[64] support. Please check the
> >review comments.
>
> Hi Jerin,
>
> I'm looking at the comments now, and working on getting the suggested
> changes merged into the patch-set.
>
> >Cavium would like to contribute on armv8 port and remaining libraries
> >(ACL, LPM, HASH) implementation for armv8. Currently i am re-basing
> >our ACL,HASH libraries implementation based on existing patches.
> >Happy to work with you guys to have full fledged armv8 support for DPDK.
> >
> >Jerin
>
> Thanks for that, it's good news indeed.
>
> >other query on rte_cpu_get_flag_enabled for armv8,
> >I have tried to run the existing patches on armv8-thunderX platform.
> >But there application start failure due to mismatch in
> >rte_cpu_get_flag_enabled() encoding.
> >
> >In my platform rte_cpu_get_flag_enabled() works based on
> >AT_HWCAP with following values[1] which different from
> >existing lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
> >
> >[1]http://lxr.free-electrons.com/source/arch/arm64/include/uapi/asm/hwcap.h
> >
> >In order to debug this, Could provide the following
> >values in tested armv8 platform. Look like its running 32bit compatible
> >mode in your environment
>
> I'm using a Gigabyte MP30AR0 motherboard with an 8-core X-Gene, Running a
> 4.3.0-rc6 kernel.
> Here's the information on the cpu_flags issue you requested:
>
> >AT_SYSINFO_EHDR: 0x3ff859f
> >AT_??? (0x26): 0x430f0a10
> >AT_HWCAP:fb
> >AT_PAGESZ:   65536
> >AT_CLKTCK:   100
> >AT_PHDR: 0x400040
> >AT_PHENT:56
> >AT_PHNUM:7
> >AT_BASE: 0x3ff85a0
> >AT_FLAGS:0x0
> >AT_ENTRY:0x401900
> >AT_UID:  0
> >AT_EUID: 0
> >AT_GID:  0
> >AT_EGID: 0
> >AT_SECURE:   0
> >AT_RANDOM:   0x3ffef1c7988
> >AT_EXECFN:   /bin/sleep
> >AT_PLATFORM: aarch64
>
> root at mp30ar0:~# LD_SHOW_AUXV=1 sleep 1000
> AT_SYSINFO_EHDR: 0x7f7956d000
> AT_HWCAP:7
> AT_PAGESZ:   4096
> AT_CLKTCK:   100
> AT_PHDR: 0x400040
> AT_PHENT:56
> AT_PHNUM:7
> AT_BASE: 0x7f79543000
> AT_FLAGS:0x0
> AT_ENTRY:0x401900
> AT_UID:  0
> AT_EUID: 0
> AT_GID:  0
> AT_EGID: 0
> AT_SECURE:   0
> AT_RANDOM:   0x7ffcaf2e48
> AT_EXECFN:   /bin/sleep
> AT_PLATFORM: aarch64
>

If am not wrong existing  rte_cpu_get_flag_enabled() implementation
should be broken in your platform also for arm64. as I could see only AT_HWCAP
not AT_HWCAP2 and AT_HWCAP is 0x7 that means your platform also
follows

http://lxr.free-electrons.com/source/arch/arm64/include/uapi/asm/hwcap.h

and the implmentation is

FEAT_DEF(SWP,   0x0001, 0, REG_HWCAP,  0) // not correct for arm64
FEAT_DEF(HALF,  0x0001, 0, REG_HWCAP,  1) // not correct for arm64
FEAT_DEF(THUMB, 0x0001, 0, REG_HWCAP,  2) // not correct for arm64
FEAT_DEF(A26BIT,0x0001, 0, REG_HWCAP,  3)
FEAT_DEF(FAST_MULT, 0x0001, 0, REG_HWCAP,  4)
FEAT_DEF(FPA,   0x0001, 0, REG_HWCAP,  5)
FEAT_DEF(VFP,   0x0001, 0, REG_HWCAP,  6)
FEAT_DEF(EDSP,  0x0001, 0, REG_HWCAP,  7)
FEAT_DEF(JAVA,  0x0001, 0, REG_HWCAP,  8)
FEAT_DEF(IWMMXT,0x0001, 0, REG_HWCAP,  9)
FEAT_DEF(CRUNCH,0x0001, 0, REG_HWCAP,  10)
FEAT_DEF(THUMBEE,   0x0001, 0, REG_HWCAP,  11)
FEAT_DEF(NEON,  0x0001, 0, REG_HWCAP,  12)
FEAT_DEF(VFPv3, 0x0001, 0, REG_HWCAP,  13)
FEAT_DEF(VFPv3D16,  0x0001, 0, REG_HWCAP,  14)
FEAT_DEF(TLS,   0x0001, 0, REG_HWCAP,  15)
FEAT_DEF(VFPv4, 0x0001, 0, REG_HWCAP,  16)
FEAT_DEF(IDIVA, 0x0001, 0, REG_HWCAP,  17)
FEAT_DEF(IDIVT, 0x0001, 0, REG_HWCAP,  18)
FEAT_DEF(VFPD32,0x0001, 0, REG_HWCAP,  19)
FEAT_DEF(LPAE,  0x0001, 0, REG_HWCAP,  20)
FEAT_DEF(EVTSTRM,   0x0001, 0, REG_HWCAP,  21)
FEAT_DEF(AES,   0x0001, 0, REG_HWCAP2,  0)
FEAT_DEF(PMULL, 0x0001, 0, REG_HWCAP2,  1)
FEAT_DEF(SHA1,  0x0001, 0, REG_HWCAP2,  2)
FEAT_DEF(SHA2,  0x0001, 0, REG_HWCAP2,  3)
FEAT_DEF(CRC32, 0x0001, 0, REG_HWCAP2,  4)
FEAT_DEF(AARCH32,   0x0001, 0, REG_PLATFORM, 0)
FEAT_DEF(AARCH64,   0x0001, 0, REG_PLATFORM, 1)

Am I missing something ?


> >root at arm64:/export/dpdk-arm64# zcat /proc/config.gz  | grep CONFIG_COMPAT
> ># CONFIG_COMPAT_BRK is not set
> >CONFIG_COMPAT_BINFMT_ELF=y
> >CONFIG_COMPAT=y
> >CONFIG_COMPAT_NETLINK_MESSAGES=y
>
> root at mp30ar0:~# zcat /proc/config.gz  | grep CONFIG_COMPAT
> # CONFIG_COMPAT_BRK is not set
> CONFIG_COMPAT_OLD_SIGACTION=y
> CONFIG_COMPAT_BINFMT_ELF=y
> CONFIG_COMPAT=y
>
>
> >root at arm64:/export/dpdk-arm64# cat /proc/cpuinfo
> >Processor   : AArch64 Processor rev 0 (aarch64)
> >processor   

[dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue with PF mbox

[David Marchand]

On Nov 2, 2015 6:23 PM, "Ananyev, Konstantin" 
wrote:
> >>Probably user deliberately doesn't want to call dev_start() for PF
device -
> >>as he doesn't plan to use it for RX/TX.
> >>Or might be dev_stop() was called just to do some re-configuration
> >>(allow to TX scattered packets on the PF queues or so).
> >>Or dev_start() for PF has not yet been called.
> >>Why VF should stop working properly because of that?
>
> >Why not.
>
> I thought I explained it above.

Sorry wrong choice of words with this "Why not".
I agree with you for this case.

-- 
David Marchand

[dpdk-dev] [PATCH v7 02/28] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data

[Thomas Monjalon]

2015-11-02 16:44, Iremonger, Bernard:
> Hi Thomas,
> 
> 
> 
> > Subject: Re: [dpdk-dev] [PATCH v7 02/28] librte_ether: add fields from
> > rte_pci_driver to rte_eth_dev_data
> > 
> > 2015-11-02 10:36, Iremonger, Bernard:
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > > 2015-10-30 15:08, Bernard Iremonger:
> > > > > add dev_flags to rte_eth_dev_data, add macros for dev_flags.
> > > > > add kdrv to rte_eth_dev_data.
> > > > > add numa_node to rte_eth_dev_data.
> > > > > add drv_name to rte_eth_dev_data.
> > > >
> > > > A commit message should explain why things are done.
> > > >
> > > > > + uint32_t dev_flags; /**< Flags controlling handling of device.
> > > > > +*/
> > > >
> > > > Where are defined this flags? What is the scope?
> > >
> > > These flags are defined in the following file:
> > >
> > > lib/librte_ether/rte_ethdev.h
> > >
> > > These flags are visible to all the vdevs and pdevs.
> > 
> > I mean it should be more explicit. Having an enum name will help.
> > Note: I understand your patch. I'm just asking the questions an user will 
> > ask
> > when trying to use your new API.
> > Thanks
> 
> I will try to be clearer in the commit message.
> I tried an enum for the dev_flags but it does not work well.
> There can be multiple flags set in dev_flags, it is intended to be a bit 
> field similar to the pci flags.

Yes. You can assign some bits in an enum.
But if you prefer the defines, it's also OK if they are clearly identifiable:
with a prefix and good comments allowing to map the structure field and the 
flags.

> I have squashed down to 19 patches now, I don't want to over squash.

The proposal of 5 patches was good.

[dpdk-dev] [PATCH 2/3] arm64: acl: add neon based acl implementation

[Jan Viktorin]

On Mon, 2 Nov 2015 21:49:54 +0530
Jerin Jacob  wrote:

> On Mon, Nov 02, 2015 at 04:39:37PM +0100, Jan Viktorin wrote:
> > On Mon, 2 Nov 2015 19:48:40 +0530
> > Jerin Jacob  wrote:
> >   
> > > Signed-off-by: Jerin Jacob 
> > > ---
> > >  app/test-acl/main.c   |   4 +
> > >  lib/librte_acl/Makefile   |   5 +
> > >  lib/librte_acl/acl.h  |   4 +
> > >  lib/librte_acl/acl_run_neon.c |  46 +++
> > >  lib/librte_acl/acl_run_neon.h | 290 
> > > ++
> > >  lib/librte_acl/rte_acl.c  |  25 
> > >  lib/librte_acl/rte_acl.h  |   1 +
> > >  7 files changed, 375 insertions(+)
> > >  create mode 100644 lib/librte_acl/acl_run_neon.c
> > >  create mode 100644 lib/librte_acl/acl_run_neon.h
> > > 
> > > diff --git a/app/test-acl/main.c b/app/test-acl/main.c
> > > index 72ce83c..0b0c093 100644
> > > --- a/app/test-acl/main.c
> > > +++ b/app/test-acl/main.c
> > > @@ -101,6 +101,10 @@ static const struct acl_alg acl_alg[] = {
> > >   .name = "avx2",
> > >   .alg = RTE_ACL_CLASSIFY_AVX2,
> > >   },
> > > + {
> > > + .name = "neon",
> > > + .alg = RTE_ACL_CLASSIFY_NEON,
> > > + },
> > >  };
> > >  
> > >  static struct {
> > > diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
> > > index 7a1cf8a..27f91d5 100644
> > > --- a/lib/librte_acl/Makefile
> > > +++ b/lib/librte_acl/Makefile
> > > @@ -48,9 +48,14 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += rte_acl.c
> > >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c
> > >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c
> > >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c
> > > +ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
> > > +SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_neon.c  
> > 
> > Are the used NEON instrinsics for ACL ARMv8-specific? If so, the file 
> > should be named
> > something like acl_run_neonv8.c...
> >   
> 
> Yes, bit of armv8 specific, looks like vqtbl1q_u8 NEON instrinsics
> defined only in armv8. I could rename to acl_run_neonv8.c but keeping
> as acl_run_neon.c, may in future it can be extend to armv7 also.
> I am open to any decision, let me know your views.

OK, this sounds reasonable. Leave it as it is.

> 
> > > +else
> > >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_sse.c
> > > +endif
> > >  
> > >  CFLAGS_acl_run_sse.o += -msse4.1
> > > +CFLAGS_acl_run_neon.o += -flax-vector-conversions 
> > > -Wno-maybe-uninitialized  
> > 
> > From man gcc:
> > 
> > -flax-vector-conversions
> >  Allow implicit conversions between vectors with differing numbers of 
> > elements and/or
> >  incompatible element types.  This option should not be used for new code.
> > 
> > I've already pointed to this in the Dave's ARMv8 patchset. They dropped it 
> > silently.
> > What is the purpose? Is it necessary?  
> 
> Yes, the same tr hi value we can representing as unsigned and signed
> based on it DFA or QRANGE .

I don't understand your answer. What is "tr hi"? What means DFA and
QRANGE here?

I just wanted to point to the note: "This option should not be used for
new code."

Jan

> 
> 
> > 
> > Jan
> >   
> > >  
> > >  #
> > >  # If the compiler supports AVX2 instructions,
> > > diff --git a/lib/librte_acl/acl.h b/lib/librte_acl/acl.h
> > > index eb4930c..09d6784 100644
> > > --- a/lib/librte_acl/acl.h
> > > +++ b/lib/librte_acl/acl.h
> > > @@ -230,6 +230,10 @@ int
> > >  rte_acl_classify_avx2(const struct rte_acl_ctx *ctx, const uint8_t 
> > > **data,
> > >   uint32_t *results, uint32_t num, uint32_t categories);
> > >
> > --snip--
> > 
> > -- 
> >Jan Viktorin  E-mail: Viktorin at RehiveTech.com
> >System Architect  Web:www.RehiveTech.com
> >RehiveTech
> >Brno, Czech Republic  



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH] mlx5: RETA query/update support

[Adrien Mazarguil]

From: Nelio Laranjeiro 

ConnectX-4 is able to use indirection tables size of power of two, but
with the current API it is impossible to predict its size, so to simplify,
for any query/update RETA command, the indirection table is modified to use
256 entries.

A port stop/start must be done to apply the new RETA configuration.

Signed-off-by: Nelio Laranjeiro 
---
 drivers/net/mlx5/mlx5.c|   8 +-
 drivers/net/mlx5/mlx5.h|   7 ++
 drivers/net/mlx5/mlx5_ethdev.c |  29 
 drivers/net/mlx5/mlx5_rss.c| 163 +
 drivers/net/mlx5/mlx5_rxq.c|  53 ++
 drivers/net/mlx5/mlx5_utils.h  |  20 +
 6 files changed, 234 insertions(+), 46 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 9636588..5a95260 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -133,6 +133,8 @@ mlx5_dev_close(struct rte_eth_dev *dev)
rte_free((*priv->rss_conf)[i]);
rte_free(priv->rss_conf);
}
+   if (priv->reta_idx != NULL)
+   rte_free(priv->reta_idx);
priv_unlock(priv);
memset(priv, 0, sizeof(*priv));
 }
@@ -160,6 +162,8 @@ static const struct eth_dev_ops mlx5_dev_ops = {
.mac_addr_remove = mlx5_mac_addr_remove,
.mac_addr_add = mlx5_mac_addr_add,
.mtu_set = mlx5_dev_set_mtu,
+   .reta_update = mlx5_dev_rss_reta_update,
+   .reta_query = mlx5_dev_rss_reta_query,
.rss_hash_update = mlx5_rss_hash_update,
.rss_hash_conf_get = mlx5_rss_hash_conf_get,
 };
@@ -373,7 +377,9 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)
DEBUG("L2 tunnel checksum offloads are %ssupported",
  (priv->hw_csum_l2tun ? "" : "not "));

-   priv->ind_table_max_size = 
exp_device_attr.rx_hash_caps.max_rwq_indirection_table_size;
+   priv->ind_table_max_size =
+   RTE_MIN((unsigned int)RSS_INDIRECTION_TABLE_SIZE,
+   
exp_device_attr.rx_hash_caps.max_rwq_indirection_table_size);
DEBUG("maximum RX indirection table size is %u",
  priv->ind_table_max_size);

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 0daacc8..b84d31d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -118,6 +118,8 @@ struct priv {
/* RSS configuration array indexed by hash RX queue type. */
struct rte_eth_rss_conf *(*rss_conf)[];
struct rte_intr_handle intr_handle; /* Interrupt handler. */
+   unsigned int (*reta_idx)[]; /* RETA index table. */
+   unsigned int reta_idx_n; /* RETA index size. */
rte_spinlock_t lock; /* Lock for control functions. */
 };

@@ -184,6 +186,11 @@ int rss_hash_rss_conf_new_key(struct priv *, const uint8_t 
*, unsigned int,
  uint64_t);
 int mlx5_rss_hash_update(struct rte_eth_dev *, struct rte_eth_rss_conf *);
 int mlx5_rss_hash_conf_get(struct rte_eth_dev *, struct rte_eth_rss_conf *);
+int priv_rss_reta_index_resize(struct priv *, unsigned int);
+int mlx5_dev_rss_reta_query(struct rte_eth_dev *,
+   struct rte_eth_rss_reta_entry64 *, uint16_t);
+int mlx5_dev_rss_reta_update(struct rte_eth_dev *,
+struct rte_eth_rss_reta_entry64 *, uint16_t);

 /* mlx5_rxmode.c */

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 84e877c..1159fa3 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -410,6 +410,9 @@ dev_configure(struct rte_eth_dev *dev)
struct priv *priv = dev->data->dev_private;
unsigned int rxqs_n = dev->data->nb_rx_queues;
unsigned int txqs_n = dev->data->nb_tx_queues;
+   unsigned int i;
+   unsigned int j;
+   unsigned int reta_idx_n;

priv->rxqs = (void *)dev->data->rx_queues;
priv->txqs = (void *)dev->data->tx_queues;
@@ -418,11 +421,31 @@ dev_configure(struct rte_eth_dev *dev)
 (void *)dev, priv->txqs_n, txqs_n);
priv->txqs_n = txqs_n;
}
+   if (rxqs_n > priv->ind_table_max_size) {
+   ERROR("cannot handle this many RX queues (%u)", rxqs_n);
+   return EINVAL;
+   }
if (rxqs_n == priv->rxqs_n)
return 0;
INFO("%p: RX queues number update: %u -> %u",
 (void *)dev, priv->rxqs_n, rxqs_n);
priv->rxqs_n = rxqs_n;
+   /* If the requested number of RX queues is not a power of two, use the
+* maximum indirection table size for better balancing.
+* The result is always rounded to the next power of two. */
+   reta_idx_n = (1 << log2above((rxqs_n & (rxqs_n - 1)) ?
+priv->ind_table_max_size :
+rxqs_n));
+   if 

[dpdk-dev] Reshuffling of rte_mbuf structure.

[shesha Sreenivasamurthy (shesha)]

One issue I see with optimization config options such as NO_TX_OFFLOAD, 
NO_MULTISEG, NO_REFCOUNT is: It is not sufficient to have those "Ifdefs" inside 
mbuf structure, but should be sprinkled all over the code where corresponding 
fields are used. This may make the code messier.

--
- Thanks
char * (*shesha) (uint64_t cache, uint8_t F00D)
{ return 0xC0DE; }

From: Stephen Hemminger mailto:step...@networkplumber.org>>
Date: Monday, November 2, 2015 at 8:24 AM
To: Arnon Warshavsky mailto:arnon at qwilt.com>>
Cc: Cisco Employee mailto:shesha at cisco.com>>, "dev at 
dpdk.org" mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure.

On Sun, 1 Nov 2015 06:45:31 +0200
Arnon Warshavsky mailto:arnon at qwilt.com>> wrote:

My 2 cents,
This was brought up in the recent user space summit, and it seems that
indeed there is no one cache lines arrangement that fits all.
OTOH multiple compile time options to suffice all flavors, would make it
unpleasant to read maintain test and debug.
(I think there was quiet a consensus in favor of reducing compile options
in general)
Currently I manage similar deviations via our own source control which I
admit to be quite a pain.
I would prefer an option of code manipulation/generation by some script
during dpdk install,
which takes the default version of rte_mbuf.h,
along with an optional user file (json,xml,elvish,whatever) defining the
structure replacements,
creating your custom version, and placing it instead of the installed copy
of rte_mbuf.h.
Maybe the only facility required from dpdk is just the ability to register
calls to such user scripts at some install stage(s), providing the mean
along with responsibility to the user.
/Arnon
On Sat, Oct 31, 2015 at 6:44 AM, shesha Sreenivasamurthy (shesha) <
shesha at cisco.com> wrote:
> In Cisco, we are using DPDK for a very high speed packet processor
> application. We don't use NIC TCP offload / RSS hashing. Putting those
> fields in the first cache-line - and the obligatory mb->next datum in the
> second cache line - causes significant LSU pressure and performance
> degradation. If it does not affect other applications, I would like to
> propose reshuffling of fields so that the obligator "next" field falls in
> first cache line and RSS hashing goes to next. If this re-shuffling indeed
> hurts other applications, another idea is to make it compile time
> configurable. Please provide feedback.
>
> --
> - Thanks
> char * (*shesha) (uint64_t cache, uint8_t F00D)
> { return 0xC0DE; }
>

Having different layouts will be a disaster for distro's they have to choose 
one.
And I hate to introduce more configuration!

But we see the same issue. It would make sense if there were configuration 
options
for some common optimizations NO_TX_OFFLOAD, NO_MULTISEG, NO_REFCOUNT and then
the mbuf got optimized for those combinations. Seems better than config options
like LAYOUT1, LAYOUT2, ...

In this specific case, I think lots of driver could be check nb_segs == 1 and 
avoiding
the next field for simple packets.

Long term, I think this will be losing battle. As DPDK grows more features, the 
current
mbuf structure will grow there is really nothing stopping the bloat of meta 
data.

[dpdk-dev] [PATCH v3 1/6] eal/arm: add 64-bit armv8 version of rte_memcpy.h

[Jan Viktorin]

On Mon, 2 Nov 2015 21:59:12 +0530
Jerin Jacob  wrote:

> On Mon, Nov 02, 2015 at 03:49:17PM +, Hunt, David wrote:
> > On 02/11/2015 15:36, Jan Viktorin wrote:  
> > >On Mon, 2 Nov 2015 15:26:19 +  
> > --snip--  
> > >It was looking like we can share a lot of common code for both
> > >architectures. I didn't know how much different are the cpuflags.  
> > 
> > CPU flags for ARMv8 are looking like this now. Quite different to the ARMv7
> > ones.
> > 
> > static const struct feature_entry cpu_feature_table[] = {
> > FEAT_DEF(FP,0x0001, 0, REG_HWCAP,  0)
> > FEAT_DEF(ASIMD, 0x0001, 0, REG_HWCAP,  1)
> > FEAT_DEF(EVTSTRM,   0x0001, 0, REG_HWCAP,  2)
> > FEAT_DEF(AES,   0x0001, 0, REG_HWCAP,  3)
> > FEAT_DEF(PMULL, 0x0001, 0, REG_HWCAP,  4)
> > FEAT_DEF(SHA1,  0x0001, 0, REG_HWCAP,  5)
> > FEAT_DEF(SHA2,  0x0001, 0, REG_HWCAP,  6)
> > FEAT_DEF(CRC32, 0x0001, 0, REG_HWCAP,  7)
> > FEAT_DEF(AARCH32,   0x0001, 0, REG_PLATFORM, 0)
> > FEAT_DEF(AARCH64,   0x0001, 0, REG_PLATFORM, 1)
> > };
> >   
> > >IMHO, it'd be better to have two directories arm and arm64. I thought
> > >to refer from arm64 to arm where possible. But I don't know whether is
> > >this possible with the DPDK build system.  
> > 
> > I think both methodologies have their pros and cons. However, I'd lean
> > towards the common directory with the "filename_32/64.h" scheme, as that
> > similar to the x86 methodology, and we don't need to tweak the include paths
> > to pull files from multiple directories.
> >   
> 
> I agree. Jan, could you please send the next version with
> filename_32/64.h for atomic and cpuflags(ie for all header files).
> I can re-base and send the complete arm64 patch based on your version.
> 

I am working on it, however, after I've removed the unnecessary
intrinsics code and set the RTE_FORCE_INTRINSICS=y, it doesn't
build... So I'm figuring out what is wrong.

Jan

> Thanks,
> Jerin
> 
> 
> 
> > Dave
> >   



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH v3 1/6] eal/arm: add 64-bit armv8 version of rte_memcpy.h

[Jerin Jacob]

On Mon, Nov 02, 2015 at 12:22:47PM +, Hunt, David wrote:
> On 02/11/2015 04:57, Jerin Jacob wrote:
> >On Fri, Oct 30, 2015 at 01:49:14PM +, David Hunt wrote:
> >>Signed-off-by: David Hunt 
> --snip--
> >>+#ifndef _RTE_MEMCPY_ARM_64_H_
> >>+#define _RTE_MEMCPY_ARM_64_H_
> >>+
> >>+#include 
> >>+#include 
> >>+
> >>+#ifdef __cplusplus
> >>+extern "C" {
> >>+#endif
> >>+
> >>+#include "generic/rte_memcpy.h"
> >>+
> >>+#ifdef __ARM_NEON_FP
> >
> >SIMD is not optional in armv8 spec.So every armv8 machine will have
> >SIMD instruction unlike armv7.More over LDP/STP instruction is
> >not part of SIMD.So this check is not required or it can
> >be replaced with a check that select memcpy from either libc or this specific
> >implementation
> 
> Jerin,
>I've just benchmarked the libc version against the hand-coded version of
> the memcpy routines, and the libc wins in most cases. This code was just an
> initial attempt at optimising the memccpy's, so I feel that with the current
> benchmark results, it would better just to remove the assembly versions, and
> use the libc version for the initial release on ARMv8.
> Then, in the future, the ARMv8 experts are free to submit an optimised
> version as a patch in the future. Does that sound reasonable to you?

Make sense. Based on my understanding, other blocks are also not optimized 
for arm64.
So better to revert back to CONFIG_RTE_FORCE_INTRINSICS and
libc for initial version.

BTW: I just tested ./arm64-armv8a-linuxapp-gcc/app/test and
"byteorder_autotest" is broken. I think existing arm64 code is not optimized
beyond CONFIG_RTE_FORCE_INTRINSICS. So better to use verified
CONFIG_RTE_FORCE_INTRINSICS scheme.

if you guys are OK with arm and arm64 as two different platform then
I can summit the complete working patch for arm64.(as in my current source
code "arm64" is a different platform(lib/librte_eal/common/include/arch/arm64/)


> Rgds,
> Dave.
> 
> 
> --snip--
> 
> 
> 

[dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue with PF mbox

[David Marchand]

On Mon, Nov 2, 2015 at 5:41 PM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:

> > If you don't want rx/tx, don't poll the port.
>
> Well, the question is why to add an extra restriction here?
>

Well, until I start a port, I would expect it to do nothing.

Probably user deliberately doesn't want to call dev_start() for PF device -
> as he doesn't plan to use it for RX/TX.
> Or might be dev_stop() was called just to do some re-configuration
> (allow to TX scattered packets on the PF queues or so).
> Or dev_start() for PF has not yet been called.
> Why VF should stop working properly because of that?
>

Why not.


-- 
David Marchand

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Bagh Fares]

Yes. Thank you. What we like is to get to a point where we discuss API and 
align on APIs for SOC as Margaret mention. As you know Arm has been driving ODP 
as the API for SOC.
What we like to do is to drive the APIs under DPDK even for Arm SOC. Long term, 
and based on shrinking silicon geometries, and desire to fill fabs, Intel will 
do more SOCs. I was SOC design manager in Intel :-)
We like to spare the customers like red hat, Cisco, and ATT the pain of 
supporting multiple APIs and code bases. 
So we need have a forum/place where this can be worked at . 
We are reaching out and we like to feel welcome and some love :-) 

-Original Message-
From: Dave Neary [mailto:dne...@redhat.com] 
Sent: Monday, November 02, 2015 11:55 AM
To: Bagh Fares-B25033 ; CHIOSI, MARGARET T ; Stephen Hemminger 
Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail (pkathail at 
cisco.com) 
Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK 
Userspace (was Notes from ...)

Hi,

On the contrary! I am aware that Freescale has been engaged for some time in 
DPDK. I was responding to Margaret's contention that future contributors (and 
she called out ARM and SOC vendors) should have a voice.

I hope that clarifies my position and meaning.

Thanks,
Dave.

On 11/02/2015 12:44 PM, Bagh Fares wrote:
> As SOC vendor we will contribute heavily to the project. Example crypto 
> acceleration. We already contribute a lot to the linux community. 
> So not sure why the doubt about of contribution?
> 
> 
> -Original Message-
> From: Dave Neary [mailto:dneary at redhat.com]
> Sent: Monday, November 02, 2015 11:31 AM
> To: CHIOSI, MARGARET T ; Stephen Hemminger 
> ; Bagh Fares-B25033 
> 
> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail 
> (pkathail at cisco.com) 
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at 
> DPDK Userspace (was Notes from ...)
> 
> Hi Margaret,
> 
> On 11/02/2015 12:28 PM, CHIOSI, MARGARET T wrote:
>> I think it is very important for the first version of governance that we 
>> have ARM/SOC vendor/future contributors to be part of TSC.
>> If based on historical contribution - they will be at a disadvantage.
>> We need to have the DPDK organization support an API which supports a 
>> broader set of chips.
> 
> I think there is definitely a role for SOC vendors in the project governance, 
> but the TSC should be representative of the technical contributors to the 
> project, rather than an aspirational body aiming to get more people involved.
> 
> I think there is an opportunity for future contributors/users to form a 
> powerful constituency in the project, but the TSC is not the right place for 
> that to happen IMHO.
> 
> Thanks,
> Dave.
> 
>> -Original Message-
>> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
>> Sent: Monday, November 02, 2015 12:22 PM
>> To: Bagh Fares
>> Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; 
>> Pradeep 
>> Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
>> Subject: Re: [dpdk-dev] Proposals from project governance meeting at 
>> DPDK Userspace (was Notes from ...)
>>
>> There were two outcomes.
>>
>> One was a proposal to move governance under Linux Foundation.
>>
>> The other was to have a technical steering committee.
>> It was agreed the TSC would be based on the contributors to the 
>> project, although we didn't come to a conclusion on a voting model.
>>
>>
>> I would propose that TSC should be elected at regular user summit 
>> from nominees; in a manner similar to LF Technical Advisory Board.
>>
> 
> --
> Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red 
> Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
> 

--
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[dpdk-dev] [PATCH] examples/l3fwd: fix eth-dest commandline strncmp size

[John McNamara]

Fix minor, and non critical, copy and paste error in strncmp() of eth-dest
commandline argument.

Fixes: bd785f6f6791 ("examples/l3fwd: make destination mac address 
configurable")

Signed-off-by: John McNamara 
---
 examples/l3fwd/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 1f3e5c6..9a7fd8c 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -2074,7 +2074,7 @@ parse_args(int argc, char **argv)
}

if (!strncmp(lgopts[option_index].name, 
CMD_LINE_OPT_ETH_DEST,
-   sizeof(CMD_LINE_OPT_CONFIG))) {
+   sizeof(CMD_LINE_OPT_ETH_DEST))) {
parse_eth_dest(optarg);
}

-- 
1.8.1.4

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Bagh Fares]

As SOC vendor we will contribute heavily to the project. Example crypto 
acceleration. We already contribute a lot to the linux community. 
So not sure why the doubt about of contribution?


-Original Message-
From: Dave Neary [mailto:dne...@redhat.com] 
Sent: Monday, November 02, 2015 11:31 AM
To: CHIOSI, MARGARET T ; Stephen Hemminger ; Bagh Fares-B25033 
Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail (pkathail at 
cisco.com) 
Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK 
Userspace (was Notes from ...)

Hi Margaret,

On 11/02/2015 12:28 PM, CHIOSI, MARGARET T wrote:
> I think it is very important for the first version of governance that we have 
> ARM/SOC vendor/future contributors to be part of TSC.
> If based on historical contribution - they will be at a disadvantage.
> We need to have the DPDK organization support an API which supports a broader 
> set of chips.

I think there is definitely a role for SOC vendors in the project governance, 
but the TSC should be representative of the technical contributors to the 
project, rather than an aspirational body aiming to get more people involved.

I think there is an opportunity for future contributors/users to form a 
powerful constituency in the project, but the TSC is not the right place for 
that to happen IMHO.

Thanks,
Dave.

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Monday, November 02, 2015 12:22 PM
> To: Bagh Fares
> Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; Pradeep 
> Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at 
> DPDK Userspace (was Notes from ...)
> 
> There were two outcomes.
> 
> One was a proposal to move governance under Linux Foundation.
> 
> The other was to have a technical steering committee.
> It was agreed the TSC would be based on the contributors to the 
> project, although we didn't come to a conclusion on a voting model.
> 
> 
> I would propose that TSC should be elected at regular user summit from 
> nominees; in a manner similar to LF Technical Advisory Board.
> 

--
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[dpdk-dev] ixgbe: ierrors counter spuriously increasing in DPDK 2.1

[Van Haaren, Harry]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Martin Weiser
> Sent: Wednesday, October 21, 2015 9:38 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] ixgbe: ierrors counter spuriously increasing in DPDK 2.1

> with DPDK 2.1 we are seeing the ierrors counter increasing for 82599ES
> ports without reason. Even directly after starting test-pmd the error
> counter immediately is 1 without even a single packet being sent to the
> device

Hi Martin,

To dig up an old thread - I've recently experienced similar issues that the rx 
error count increases on 82599, so I dug into the sources and realized that the 
MAC fault counters were being added to the rx error count.

The following patch removes the MAC local and remote fault counts from rx 
errors, and this has fixed the issue here:
http://dpdk.org/dev/patchwork/patch/8525/

If this issue is still open perhaps try the patch and see if it improves the 
situation.

On a related note, I'm currently implementing extended statistics for ixgbe, 
which showed me that the MAC faults were the root cause of the rx increase in 
my case.

-Harry

[dpdk-dev] [PATCH] igbvf: fix vlan filtering

[David Marchand]

Hello,

On Mon, Nov 2, 2015 at 8:21 AM, Lu, Wenzhuo  wrote:

>
> > @@ -2502,7 +2503,14 @@ static int igbvf_set_vfta(struct e1000_hw *hw,
> > uint16_t vid, bool on)
> >   if (on)
> >   msgbuf[0] |= E1000_VF_SET_VLAN_ADD;
> >
> > - return (mbx->ops.write_posted(hw, msgbuf, 2, 0));
> > + mbx->ops.write_posted(hw, msgbuf, 2, 0);
> How about if write failed? I think we'd better check it.
>

Yes, just trying to test this before resubmitting.

Thanks.


-- 
David Marchand

[dpdk-dev] [PATCH v7 02/28] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data

[Thomas Monjalon]

2015-11-02 10:36, Iremonger, Bernard:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 2015-10-30 15:08, Bernard Iremonger:
> > > add dev_flags to rte_eth_dev_data, add macros for dev_flags.
> > > add kdrv to rte_eth_dev_data.
> > > add numa_node to rte_eth_dev_data.
> > > add drv_name to rte_eth_dev_data.
> > 
> > A commit message should explain why things are done.
> > 
> > > + uint32_t dev_flags; /**< Flags controlling handling of device. */
> > 
> > Where are defined this flags? What is the scope?
> 
> These flags are defined in the following file:
> 
> lib/librte_ether/rte_ethdev.h
> 
> These flags are visible to all the vdevs and pdevs.

I mean it should be more explicit. Having an enum name will help.
Note: I understand your patch. I'm just asking the questions an user
will ask when trying to use your new API.
Thanks

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[CHIOSI, MARGARET T]

I think it is very important for the first version of governance that we have 
ARM/SOC vendor/future contributors to be part of TSC.
If based on historical contribution - they will be at a disadvantage.
We need to have the DPDK organization support an API which supports a broader 
set of chips.

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Monday, November 02, 2015 12:22 PM
To: Bagh Fares
Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; Pradeep 
Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK 
Userspace (was Notes from ...)

There were two outcomes.

One was a proposal to move governance under Linux Foundation.

The other was to have a technical steering committee.
It was agreed the TSC would be based on the contributors to the project,
although we didn't come to a conclusion on a voting model.


I would propose that TSC should be elected at regular user summit from nominees;
in a manner similar to LF Technical Advisory Board.

[dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library

[Thomas Monjalon]

2015-11-02 15:23, Ferruh Yigit:
> +ifeq ($(COMBINED_BUILD),1)
>  include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif

Why this ifeq?
rte.sharelib.mk is always used for combined lib.

[dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue with PF mbox

[Ananyev, Konstantin]

>>> If you don't want rx/tx, don't poll the port.

>>Well, the question is why to add an extra restriction here?

>Well, until I start a port, I would expect it to do nothing.

>>Probably user deliberately doesn't want to call dev_start() for PF device -
>>as he doesn't plan to use it for RX/TX.
>>Or might be dev_stop() was called just to do some re-configuration
>>(allow to TX scattered packets on the PF queues or so).
>>Or dev_start() for PF has not yet been called.
>>Why VF should stop working properly because of that?

>Why not.

I thought I explained it above.
Basically it means that you can't stop your PF without forcing to stop all VFs 
first.
And you can't start any of your VFs without starting PF first.
I think that adds an unnecessary restrictions and limits systems availability 
quite significantly.
Konstantin 

[dpdk-dev] [PATCH v4 02/10] ethdev: update xstats_get() strings and Q handling

[Thomas Monjalon]

2015-11-02 10:17, Van Haaren, Harry:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Monday, November 2, 2015 7:59 AM
> > > +   /* if xstats_get() is implemented by the PMD, the Q stats are 
> > > done */
> > > +   if (dev->dev_ops->xstats_get != NULL)
> > > +   return count + xcount;
> > > +
> > > /* per-rxq stats */
> > > for (q = 0; q < dev->data->nb_rx_queues; q++) {
> > > for (i = 0; i < RTE_NB_RXQ_STATS; i++) {
> > 
> > Please could you explain why the generic per-queue stats are not used when
> > xstats is implemented in the driver?
> 
> Each PMD exposes its own queue stats so it has the flexibility of presenting 
> them exactly has the hardware counts, in a human-readable order.
> 
> If the generic xstats were used, testpmd> xstats output would split a single 
> queue's xstats to two places in the list. As stats are used during debugging, 
> readability and clarity of the stats is vital in my opinion.

Output control is the role of testpmd, not the driver.
I think you can reorder the stats in testpmd given that you have defined
a clear scheme naming (thanks).

[dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue with PF mbox

[David Marchand]

On Mon, Nov 2, 2015 at 5:09 PM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:

>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand
> > Sent: Monday, November 02, 2015 4:03 PM
> > To: Liang, Cunming
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible
> issue with PF mbox
> >
> > On Thu, Sep 24, 2015 at 7:33 AM, Cunming Liang 
> > wrote:
> >
> > > When ixgbe runs as a PF, mbox interrupt is prerequisite to make VF
> start
> > > normally.
> > > And PF sometimes won't 'dev_start', so the mbox interrupt register
> during
> > > 'dev_init' is required.
> > >
> >
> > Can you describe the cases/situations where you would want a device to
> > handle interrupts while not started ?
>
> When PF and VF are both controlled by DPDK process(es).
> And user doesn't really want to do any RX/TX through PF - uses PF just to
> control/configure VF(s).
>
>
Ok, but the user still needs to whitelist the PF (or ensure the PF is not
blacklisted) in one of these processes.
Then, the application would do a "partial" initialisation ?
If you don't want rx/tx, don't poll the port.

Anyway, this is your code :-)


-- 
David Marchand

[dpdk-dev] [PATCH v2 07/11] ixgbevf: cleanup unnecessary interrupt handler

[David Marchand]

On Fri, Oct 30, 2015 at 6:27 AM, Cunming Liang 
wrote:

> As ixgbe vf doesn't support lsc, the patch removes those unused code.
> In addition, it does some tiny cleanup.
>

Please, can you describe this tiny cleanup ?
Did it trigger some bug ?


> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 366923f..794171c 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> [snip]
> @@ -3492,11 +3442,11 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
> ixgbevf_dev_rxtx_start(dev);
>
> /* check and configure queue intr-vector mapping */
> -   if (dev->data->dev_conf.intr_conf.rxq != 0)
> +   if (dev->data->dev_conf.intr_conf.rxq != 0) {
> intr_vector = dev->data->nb_rx_queues;
> -
> -   if (rte_intr_efd_enable(intr_handle, intr_vector))
> -   return -1;
> +   if (rte_intr_efd_enable(intr_handle, intr_vector))
> +   return -1;
> +   }
>
>


-- 
David Marchand

[dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue with PF mbox

[David Marchand]

On Thu, Sep 24, 2015 at 7:33 AM, Cunming Liang 
wrote:

> When ixgbe runs as a PF, mbox interrupt is prerequisite to make VF start
> normally.
> And PF sometimes won't 'dev_start', so the mbox interrupt register during
> 'dev_init' is required.
>

Can you describe the cases/situations where you would want a device to
handle interrupts while not started ?


Thanks.
-- 
David Marchand

[dpdk-dev] [PATCH v2 05/11] eal/linux: add intr api to report multi-vector capability

[David Marchand]

On Fri, Oct 30, 2015 at 6:27 AM, Cunming Liang 
wrote:

> VFIO allows multiple MSI-X vector, others doesn't, but maybe will allow it
> in the future.
> Device drivers need to be aware of the capability.
> It's better to avoid condition check on interrupt type(VFIO) everywhere,
> instead
> a capability api is more flexible for the condition change.
>
> Signed-off-by: Cunming Liang 
> ---
>  lib/librte_eal/linuxapp/eal/eal_interrupts.c  |  9
> +
>  lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h | 10
> ++
>  lib/librte_eal/linuxapp/eal/rte_eal_version.map   |  7 +++
>  3 files changed, 26 insertions(+)
>
>
BSD has wrappers for the rest of this api, please add one for this too.


-- 
David Marchand

[dpdk-dev] [PATCH v2 01/11] eal/linux: vfio map misc intr to vector zero

[David Marchand]

Hello,

On Fri, Oct 30, 2015 at 6:27 AM, Cunming Liang 
wrote:
[snip]

> diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h
> b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h
> index 45071b7..b8fd318 100644
> --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h
> +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h
> @@ -77,6 +77,9 @@ struct rte_epoll_event {
> struct rte_epoll_data epdata;
>  };
>
> +#define MISC_VEC_ID(0)
>

"misc" is not really descriptive ...


> +#define RX_VEC_START   (MISC_VEC_ID + 1)
> +
>

Please, prefix these macros properly.
Else, when looking at the driver code, this kind of macros seems to be
local to the driver.


-- 
David Marchand

[dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue with PF mbox

[Ananyev, Konstantin]

> 
> From: David Marchand [mailto:david.marchand at 6wind.com]
> Sent: Monday, November 02, 2015 4:22 PM
> To: Ananyev, Konstantin
> Cc: Liang, Cunming; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue 
> with PF mbox
> 
> On Mon, Nov 2, 2015 at 5:09 PM, Ananyev, Konstantin  intel.com> wrote:
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand
> > Sent: Monday, November 02, 2015 4:03 PM
> > To: Liang, Cunming
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible 
> > issue with PF mbox
> >
> > On Thu, Sep 24, 2015 at 7:33 AM, Cunming Liang 
> > wrote:
> >
> > > When ixgbe runs as a PF, mbox interrupt is prerequisite to make VF start
> > > normally.
> > > And PF sometimes won't 'dev_start', so the mbox interrupt register during
> > > 'dev_init' is required.
> > >
> >
> > Can you describe the cases/situations where you would want a device to
> > handle interrupts while not started ?
> 
> When PF and VF are both controlled by DPDK process(es).
> And user doesn't really want to do any RX/TX through PF - uses PF just to 
> control/configure VF(s).
> 
> Ok, but the user still needs to whitelist the PF (or ensure the PF is not 
> blacklisted) in one of these processes.

Yes, at least dev_init() need to be called for that device. 

> Then, the application would do a "partial" initialisation ?

Yep, sort of.

> If you don't want rx/tx, don't poll the port.

Well, the question is why to add an extra restriction here?
Probably user deliberately doesn't want to call dev_start() for PF device -
as he doesn't plan to use it for RX/TX.
Or might be dev_stop() was called just to do some re-configuration 
(allow to TX scattered packets on the PF queues or so).
Or dev_start() for PF has not yet been called.
Why VF should stop working properly because of that? 
Konstantin

> Anyway, this is your code :-)
> 
> 
> --
> David Marchand

[dpdk-dev] [PATCH 2/3] arm64: acl: add neon based acl implementation

[Jan Viktorin]

On Mon, 2 Nov 2015 19:48:40 +0530
Jerin Jacob  wrote:

> Signed-off-by: Jerin Jacob 
> ---
>  app/test-acl/main.c   |   4 +
>  lib/librte_acl/Makefile   |   5 +
>  lib/librte_acl/acl.h  |   4 +
>  lib/librte_acl/acl_run_neon.c |  46 +++
>  lib/librte_acl/acl_run_neon.h | 290 
> ++
>  lib/librte_acl/rte_acl.c  |  25 
>  lib/librte_acl/rte_acl.h  |   1 +
>  7 files changed, 375 insertions(+)
>  create mode 100644 lib/librte_acl/acl_run_neon.c
>  create mode 100644 lib/librte_acl/acl_run_neon.h
> 
> diff --git a/app/test-acl/main.c b/app/test-acl/main.c
> index 72ce83c..0b0c093 100644
> --- a/app/test-acl/main.c
> +++ b/app/test-acl/main.c
> @@ -101,6 +101,10 @@ static const struct acl_alg acl_alg[] = {
>   .name = "avx2",
>   .alg = RTE_ACL_CLASSIFY_AVX2,
>   },
> + {
> + .name = "neon",
> + .alg = RTE_ACL_CLASSIFY_NEON,
> + },
>  };
>  
>  static struct {
> diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
> index 7a1cf8a..27f91d5 100644
> --- a/lib/librte_acl/Makefile
> +++ b/lib/librte_acl/Makefile
> @@ -48,9 +48,14 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += rte_acl.c
>  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c
>  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c
>  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c
> +ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
> +SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_neon.c

Are the used NEON instrinsics for ACL ARMv8-specific? If so, the file should be 
named
something like acl_run_neonv8.c...

> +else
>  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_sse.c
> +endif
>  
>  CFLAGS_acl_run_sse.o += -msse4.1
> +CFLAGS_acl_run_neon.o += -flax-vector-conversions -Wno-maybe-uninitialized

[dpdk-dev] [PATCH v3 1/6] eal/arm: add 64-bit armv8 version of rte_memcpy.h

[Jan Viktorin]

On Mon, 2 Nov 2015 15:26:19 +
"Hunt, David"  wrote:

> On 02/11/2015 12:57, Jerin Jacob wrote:
> > On Mon, Nov 02, 2015 at 12:22:47PM +, Hunt, David wrote:  
> >> Jerin,
> >> I've just benchmarked the libc version against the hand-coded version 
> >> of
> >> the memcpy routines, and the libc wins in most cases. This code was just an
> >> initial attempt at optimising the memccpy's, so I feel that with the 
> >> current
> >> benchmark results, it would better just to remove the assembly versions, 
> >> and
> >> use the libc version for the initial release on ARMv8.
> >> Then, in the future, the ARMv8 experts are free to submit an optimised
> >> version as a patch in the future. Does that sound reasonable to you?  
> >
> > Make sense. Based on my understanding, other blocks are also not optimized
> > for arm64.
> > So better to revert back to CONFIG_RTE_FORCE_INTRINSICS and
> > libc for initial version.
> >
> > BTW: I just tested ./arm64-armv8a-linuxapp-gcc/app/test and
> > "byteorder_autotest" is broken. I think existing arm64 code is not optimized
> > beyond CONFIG_RTE_FORCE_INTRINSICS. So better to use verified
> > CONFIG_RTE_FORCE_INTRINSICS scheme.  
> 
> Agreed.
> 
> > if you guys are OK with arm and arm64 as two different platform then
> > I can summit the complete working patch for arm64.(as in my current source
> > code "arm64" is a different 
> > platform(lib/librte_eal/common/include/arch/arm64/)  
> 
> Sure. That would be great. We initially started with two ARMv7 
> patch-sets, and Jan merged into one. Something similar could happen for 
> the ARMv8 patch set. We just want to end up with the best implementation 
> possible. :)
> 

It was looking like we can share a lot of common code for both
architectures. I didn't know how much different are the cpuflags.

IMHO, it'd be better to have two directories arm and arm64. I thought
to refer from arm64 to arm where possible. But I don't know whether is
this possible with the DPDK build system.

Jan

> Dave.
> 
> 
> 
> 



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH v3 6/6] test: add checks for cpu flags on armv8

[Jan Viktorin]

On Mon, 2 Nov 2015 10:47:53 +
"Hunt, David"  wrote:

> On 02/11/2015 06:32, Jerin Jacob wrote:
> > On Fri, Oct 30, 2015 at 04:28:25PM +, Hunt, David wrote:  
> 
> --snip--
> 
> >
> > Hi Jan and Dave,
> >
> > I have reviewed your patches for arm[64] support. Please check the
> > review comments.  
> 
--snip--
> > In order to debug this, Could provide the following
> > values in tested armv8 platform. Look like its running 32bit compatible
> > mode in your environment  
> 
> I'm using a Gigabyte MP30AR0 motherboard with an 8-core X-Gene, Running 
> a 4.3.0-rc6 kernel.
> Here's the information on the cpu_flags issue you requested:
> 
--snip--
> 
> root at mp30ar0:~#
> 
> Hope this helps.
> 
> Regards,
> Dave.
> 

My few bits to compare to ARMv7. There is AT_PLATFORM=v7l (and no
aarch32), this is probably to be fixed...

Altera SoC FPGA:

# LD_SHOW_AUXV=1 sleep 1
AT_HWCAP:swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
AT_PAGESZ:   4096
AT_CLKTCK:   100
AT_PHDR: 0x10034
AT_PHENT:32
AT_PHNUM:8
AT_BASE: 0x76fd3000
AT_FLAGS:0x0
AT_ENTRY:0x149d9
AT_UID:  0
AT_EUID: 0
AT_GID:  0
AT_EGID: 0
AT_SECURE:   0
AT_RANDOM:   0x7ebbcf2f
AT_EXECFN:   /bin/sleep
AT_PLATFORM: v7l

# cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 0 (v7l)
Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3
tls vfpd32 CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part: 0xc09
CPU revision: 0

processor   : 1
model name  : ARMv7 Processor rev 0 (v7l)
Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3
tls vfpd32 CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part: 0xc09
CPU revision: 0

Hardware: Altera SOCFPGA
Revision: 
Serial  : 


Odroid XU4:

# LD_SHOW_AUXV=1 sleep 1
AT_HWCAP:swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
AT_PAGESZ:   4096
AT_CLKTCK:   100
AT_PHDR: 0x10034
AT_PHENT:32
AT_PHNUM:9
AT_BASE: 0xb6f8c000
AT_FLAGS:0x0
AT_ENTRY:0x11191
AT_UID:  1000
AT_EUID: 1000
AT_GID:  1000
AT_EGID: 1000
AT_SECURE:   0
AT_RANDOM:   0xbec42ed6
AT_EXECFN:   /bin/sleep
AT_PLATFORM: v7l

# cat /proc/cpuinfo
Processor   : ARMv7 Processor rev 1 (v7l)
processor   : 0
BogoMIPS: 3.07

processor   : 1
BogoMIPS: 3.07

processor   : 2
BogoMIPS: 3.07

processor   : 3
BogoMIPS: 3.07

Features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc05
CPU revision: 1

Hardware: ODROIDC
Revision: 000a
Serial  : 1b00

-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH v3 6/6] test: add checks for cpu flags on armv8

[Jan Viktorin]

On Mon, 2 Nov 2015 15:04:14 +
"Hunt, David"  wrote:

> On 02/11/2015 13:17, Jerin Jacob wrote:
> -snip--
> > If am not wrong existing  rte_cpu_get_flag_enabled() implementation
> > should be broken in your platform also for arm64. as I could see only 
> > AT_HWCAP
> > not AT_HWCAP2 and AT_HWCAP is 0x7 that means your platform also
> > follows
> >
> > http://lxr.free-electrons.com/source/arch/arm64/include/uapi/asm/hwcap.h
> >
> > and the implmentation is
> >
> > FEAT_DEF(SWP,   0x0001, 0, REG_HWCAP,  0) // not correct for arm64
> > FEAT_DEF(HALF,  0x0001, 0, REG_HWCAP,  1) // not correct for arm64
> > FEAT_DEF(THUMB, 0x0001, 0, REG_HWCAP,  2) // not correct for arm64
> > FEAT_DEF(A26BIT,0x0001, 0, REG_HWCAP,  3)  
> --snip--
> > FEAT_DEF(CRC32, 0x0001, 0, REG_HWCAP2,  4)
> > FEAT_DEF(AARCH32,   0x0001, 0, REG_PLATFORM, 0)
> > FEAT_DEF(AARCH64,   0x0001, 0, REG_PLATFORM, 1)
> >
> > Am I missing something ?  
> 
> You are correct. I need to re-visit this. In merging the ARMv7 and 
> ARVv8, I should have split the hardware capabilities flags into 32-but 
> and 64-bit versions. I'll do that in the next patch.
> Thanks,
> Dave.

Should I split the rte_atomic.h and rte_cpuflags.h then?

Jan

> 
> 
> 
> 
> 



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue with PF mbox

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand
> Sent: Monday, November 02, 2015 4:03 PM
> To: Liang, Cunming
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 06/11] ixgbe: fix rx intr compatible issue 
> with PF mbox
> 
> On Thu, Sep 24, 2015 at 7:33 AM, Cunming Liang 
> wrote:
> 
> > When ixgbe runs as a PF, mbox interrupt is prerequisite to make VF start
> > normally.
> > And PF sometimes won't 'dev_start', so the mbox interrupt register during
> > 'dev_init' is required.
> >
> 
> Can you describe the cases/situations where you would want a device to
> handle interrupts while not started ?

When PF and VF are both controlled by DPDK process(es).
And user doesn't really want to do any RX/TX through PF - uses PF just to 
control/configure VF(s). 

> 
> 
> Thanks.
> --
> David Marchand

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[CHIOSI, MARGARET T]

To add to Bagh's comments - AT is very interested in the governance being 
proposed in expanding to allow more equal voice including from the SOC vendors.
We think it is important to rally around one API for data plane acceleration 
which allows innovation to continue at the chip level.

From: Bagh Fares [mailto:fares.b...@freescale.com]
Sent: Friday, October 30, 2015 2:01 PM
To: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; Pradeep 
Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK 
Userspace (was Notes from ...)

Hi dave
My name is Fares Bagh. I am from Freescale networking division.
We are very interested and supportive in the proposal below.
Our main interest is enabling HW acceleration options for our customers 
starting with crypto function. We like to have a road map for acceleration 
beyond crypto.
We support having the group under linux foundation.
Lot of work ahead so please let me know how I can help.
Fares
VP. Hardware and Architecture, Networking.
fares.bagh at freescale.com

Hi,

To explicitly call out the proposals and action items from the meeting:

- Legal entity proposal:
   - PROPOSAL: Chris proposes moving DPDK to Linux Foundation, with low
overhead option
   - Minimal governance, event, marketing budget
   - Legal governance around project name, trademark

- Project leadership proposal (roadmap, scope)
   - ACTION: Venky to write a proposal for broadening scope as a patch
to the website
   - PROPOSAL: Thomas proposes several smaller projects, rather than one
umbrella project as scope broadens
   - ACTION: Jim proposed documenting current decision process, and
improving on it - documenting it will help make it better.
   - ACTION: Tim proposed to resurface his TSC proposal and drive it to
agreement and action
   - Proposed criteria which should be met by any technical governance
model:
1. Everyone has a voice
2. Some voices carry more weight than others, based on technical
seniority and participation in the community
3. Decisions should be time bound - after community debate, decision
should converge quickly one way or the other to give clarity

- Day to day patch review:
   - PROPOSAL: Thomas: Create hierarchical review process with
maintainers responsible for sub-trees (to be housed in DPDK Git)
   - ACTION: (without owner?) Subtrees and maintainers to be identified,
-next, crypto and (drivers, IIRC?) to be first trees
   - PROPOSAL: Thomas to identify replacement maintainers short-term
when he is unable to do it (vacation, sickness, etc)

- Stable patch maintenance
   - PROPOSAL: Maintain one release per year as a long term release,
with point releases being made regularly (based on patch volume), with
branches maintained for 2 years (2 stable branches + 1 devel branch
active at all times).

In addition to Thomas's notes, does this cover all of the conclusions
that came out of the meeting?

Thanks,
Dave.

On 10/11/2015 01:36 AM, Dave Neary wrote:
> Hi everyone,
>
> I took some notes from a discussion we had at the end of DPDK Userspace
> in Dublin, concerning the growth and project structure for DPDK. If I
> missed anyone's name, I apologise - there were many active contributors,
> including most prominently Venky, Jim St Leger, Bruce Richardson,
> Stephen Hemminger, Chris Wright, myself, Keith Wiles, Cristian
> Dumitrescu, Tim O'Driscoll, Thomas Monjalon, and (until he had to leave)
> Vincent Jardin. There were a few others from Intel, ARM, and others, but
> I didn't get all the names during the discussion. If you see a comment
> you made and would like attribution, reply - especially if it doesn't
> quite match your view.
>
> The discussion was wide ranging and we didn't quite stay on one topic
> until we reached a conclusion, so some of these notes are not in strict
> time order.
>
> These are a mixture of notes and proposals for the project coming out of
> the meeting - comments are welcome, all proposals are up for discussion,
> and nothing has been decided on the basis of this meeting. However, all
> present expressed agreement that there are issues we need to address in
> the near future.
>
> Apologies for the non-linear note taking, for those who were not there I
> hope they're useful.
>
> Thanks,
> Dave.
>
>
>
> Topic 1: Legal entity
> =
>
> Do we need/want a legal entity independent of a commercial vendor who
> can represent the project?
>
> Things a legal entity could do:
> - Sign contracts and raise money for events
> - Organise events
> - Own the trademark
> - Own project infrastructure like DNS, website infrastructure
> - Centralised pool for marketing budget?
> - Brand awareness?
>
> There was agreement that legal governance should be lightweight, and
> completely independent of technical governance. Vincent insisted on the
> low cost structure for entities like 6WIND who would not be able to
> justify a 6 

[dpdk-dev] [PATCH v3 1/6] eal/arm: add 64-bit armv8 version of rte_memcpy.h

[Hunt, David]

On 02/11/2015 15:36, Jan Viktorin wrote:
> On Mon, 2 Nov 2015 15:26:19 +
--snip--
> It was looking like we can share a lot of common code for both
> architectures. I didn't know how much different are the cpuflags.

CPU flags for ARMv8 are looking like this now. Quite different to the 
ARMv7 ones.

static const struct feature_entry cpu_feature_table[] = {
 FEAT_DEF(FP,0x0001, 0, REG_HWCAP,  0)
 FEAT_DEF(ASIMD, 0x0001, 0, REG_HWCAP,  1)
 FEAT_DEF(EVTSTRM,   0x0001, 0, REG_HWCAP,  2)
 FEAT_DEF(AES,   0x0001, 0, REG_HWCAP,  3)
 FEAT_DEF(PMULL, 0x0001, 0, REG_HWCAP,  4)
 FEAT_DEF(SHA1,  0x0001, 0, REG_HWCAP,  5)
 FEAT_DEF(SHA2,  0x0001, 0, REG_HWCAP,  6)
 FEAT_DEF(CRC32, 0x0001, 0, REG_HWCAP,  7)
 FEAT_DEF(AARCH32,   0x0001, 0, REG_PLATFORM, 0)
 FEAT_DEF(AARCH64,   0x0001, 0, REG_PLATFORM, 1)
};

> IMHO, it'd be better to have two directories arm and arm64. I thought
> to refer from arm64 to arm where possible. But I don't know whether is
> this possible with the DPDK build system.

I think both methodologies have their pros and cons. However, I'd lean 
towards the common directory with the "filename_32/64.h" scheme, as that 
similar to the x86 methodology, and we don't need to tweak the include 
paths to pull files from multiple directories.

Dave

[dpdk-dev] [PATCH v3 1/6] eal/arm: add 64-bit armv8 version of rte_memcpy.h

[Hunt, David]

On 02/11/2015 12:57, Jerin Jacob wrote:
> On Mon, Nov 02, 2015 at 12:22:47PM +, Hunt, David wrote:
>> Jerin,
>> I've just benchmarked the libc version against the hand-coded version of
>> the memcpy routines, and the libc wins in most cases. This code was just an
>> initial attempt at optimising the memccpy's, so I feel that with the current
>> benchmark results, it would better just to remove the assembly versions, and
>> use the libc version for the initial release on ARMv8.
>> Then, in the future, the ARMv8 experts are free to submit an optimised
>> version as a patch in the future. Does that sound reasonable to you?
>
> Make sense. Based on my understanding, other blocks are also not optimized
> for arm64.
> So better to revert back to CONFIG_RTE_FORCE_INTRINSICS and
> libc for initial version.
>
> BTW: I just tested ./arm64-armv8a-linuxapp-gcc/app/test and
> "byteorder_autotest" is broken. I think existing arm64 code is not optimized
> beyond CONFIG_RTE_FORCE_INTRINSICS. So better to use verified
> CONFIG_RTE_FORCE_INTRINSICS scheme.

Agreed.

> if you guys are OK with arm and arm64 as two different platform then
> I can summit the complete working patch for arm64.(as in my current source
> code "arm64" is a different 
> platform(lib/librte_eal/common/include/arch/arm64/)

Sure. That would be great. We initially started with two ARMv7 
patch-sets, and Jan merged into one. Something similar could happen for 
the ARMv8 patch set. We just want to end up with the best implementation 
possible. :)

Dave.

[dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library

[Ferruh Yigit]

Fixes following error:
  LD libdpdk.so
  /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
  for symbol @DPDK_x.y

Defines version symbols in a fixed path libdpdk.map file and this
value hardcoded into makefile

Signed-off-by: Ferruh Yigit 
---
 drivers/net/Makefile |  3 +++
 lib/Makefile |  3 +++
 lib/libdpdk.map  | 12 
 mk/rte.sdkbuild.mk   |  2 +-
 mk/rte.sharelib.mk   |  1 +
 5 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 lib/libdpdk.map

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6da1ce2..d30018c 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -50,5 +50,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
 DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt

+ifeq ($(COMBINED_BUILD),1)
 include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/Makefile b/lib/Makefile
index 9727b83..33d76a6 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -62,5 +62,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
 DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
 endif

+ifeq ($(COMBINED_BUILD),1)
 include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/libdpdk.map b/lib/libdpdk.map
new file mode 100644
index 000..3988a3f
--- /dev/null
+++ b/lib/libdpdk.map
@@ -0,0 +1,12 @@
+DPDK_2.0 {
+
+};
+
+DPDK_2.1 {
+
+} DPDK_2.0;
+
+DPDK_2.2 {
+
+} DPDK_2.1;
+
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 38ec7bd..d4e3abf 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -94,7 +94,7 @@ $(ROOTDIRS-y):
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
@if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
-   $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+   COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
fi

 %_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..1f71fcb 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,7 @@ LIB_ONE := lib$(RTE_LIBNAME).so
 else
 LIB_ONE := lib$(RTE_LIBNAME).a
 endif
+CPU_LDFLAGS += --version-script=$(SRCDIR)/lib/libdpdk.map
 endif

 .PHONY:sharelib
-- 
1.9.3

[dpdk-dev] [PATCH v3 6/6] test: add checks for cpu flags on armv8

[Hunt, David]

On 02/11/2015 15:13, Jan Viktorin wrote:
> On Mon, 2 Nov 2015 15:04:14 +
> "Hunt, David"  wrote:
>
>> On 02/11/2015 13:17, Jerin Jacob wrote:
>> -snip--
>>> If am not wrong existing  rte_cpu_get_flag_enabled() implementation
>>> should be broken in your platform also for arm64. as I could see only 
>>> AT_HWCAP
>>> not AT_HWCAP2 and AT_HWCAP is 0x7 that means your platform also
>>> follows
>>>
>>> http://lxr.free-electrons.com/source/arch/arm64/include/uapi/asm/hwcap.h
>>>
>>> and the implmentation is
>>>
>>> FEAT_DEF(SWP,   0x0001, 0, REG_HWCAP,  0) // not correct for arm64
>>> FEAT_DEF(HALF,  0x0001, 0, REG_HWCAP,  1) // not correct for arm64
>>> FEAT_DEF(THUMB, 0x0001, 0, REG_HWCAP,  2) // not correct for arm64
>>> FEAT_DEF(A26BIT,0x0001, 0, REG_HWCAP,  3)
>> --snip--
>>> FEAT_DEF(CRC32, 0x0001, 0, REG_HWCAP2,  4)
>>> FEAT_DEF(AARCH32,   0x0001, 0, REG_PLATFORM, 0)
>>> FEAT_DEF(AARCH64,   0x0001, 0, REG_PLATFORM, 1)
>>>
>>> Am I missing something ?
>>
>> You are correct. I need to re-visit this. In merging the ARMv7 and
>> ARVv8, I should have split the hardware capabilities flags into 32-but
>> and 64-bit versions. I'll do that in the next patch.
>> Thanks,
>> Dave.
>
> Should I split the rte_atomic.h and rte_cpuflags.h then?
>
> Jan

It looks like we're headed in that direction, so yes, I think that would 
be a good idea.

Dave

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Pradeep Kathail]

Tim and Dave,

I agree that an architecture board membership should be based on 
technical standing and contribution but at the same time,
if you are trying to bring a new hardware paradigm into a project, you 
need to give a chance to some of those experts to
participate and gain the standing.

If community is serious about supporting SOC's, my suggestion will be 
to allow few (2?) members from SOC community for
limited time (6? months) and then evaluate based on their contributions.

Pradeep

On 11/2/15 1:44 PM, O'Driscoll, Tim wrote:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bagh Fares
>> Sent: Monday, November 2, 2015 6:03 PM
>> To: Dave Neary; CHIOSI, MARGARET T; Stephen Hemminger
>> Cc: dev at dpdk.org; Pradeep Kathail (pkathail at cisco.com)
>> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
>> DPDK Userspace (was Notes from ...)
>>
>> Yes. Thank you. What we like is to get to a point where we discuss API
>> and align on APIs for SOC as Margaret mention. As you know Arm has been
>> driving ODP as the API for SOC.
>> What we like to do is to drive the APIs under DPDK even for Arm SOC.
>> Long term, and based on shrinking silicon geometries, and desire to fill
>> fabs, Intel will do more SOCs. I was SOC design manager in Intel :-)
>> We like to spare the customers like red hat, Cisco, and ATT the pain of
>> supporting multiple APIs and code bases.
> That's our goal too, so it's good to hear that we're in agreement on this.
>
>> So we need have a forum/place where this can be worked at .
> If you have some ideas, then the best way to get some discussion going is 
> through the mailing list. You could post a set of patches for proposed 
> changes, a higher-level RFC outlining your thoughts, or just specific 
> questions/issues that you see.
>
> On the TSC that was specifically referenced earlier in this thread, there is 
> a proposal for what we're now calling the Architecture Board at: 
> http://dpdk.org/ml/archives/dev/2015-October/026598.html. As Dave mentioned, 
> we agreed at our recent Userspace event in Dublin that membership of the 
> board should be based on contributions and technical standing in the 
> community. The board will review and approve new members on an annual basis.
>   
>> We are reaching out and we like to feel welcome and some love :-)
> As Thomas already said, new contributors are always welcome!
>
>
> Tim
>
>
>> -Original Message-
>> From: Dave Neary [mailto:dneary at redhat.com]
>> Sent: Monday, November 02, 2015 11:55 AM
>> To: Bagh Fares-B25033 ; CHIOSI, MARGARET T
>> ; Stephen Hemminger 
>> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail
>> (pkathail at cisco.com) 
>> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
>> DPDK Userspace (was Notes from ...)
>>
>> Hi,
>>
>> On the contrary! I am aware that Freescale has been engaged for some
>> time in DPDK. I was responding to Margaret's contention that future
>> contributors (and she called out ARM and SOC vendors) should have a
>> voice.
>>
>> I hope that clarifies my position and meaning.
>>
>> Thanks,
>> Dave.
>>
>> On 11/02/2015 12:44 PM, Bagh Fares wrote:
>>> As SOC vendor we will contribute heavily to the project. Example
>> crypto acceleration. We already contribute a lot to the linux community.
>>> So not sure why the doubt about of contribution?
>>>
>>>
>>> -Original Message-
>>> From: Dave Neary [mailto:dneary at redhat.com]
>>> Sent: Monday, November 02, 2015 11:31 AM
>>> To: CHIOSI, MARGARET T ; Stephen Hemminger
>>> ; Bagh Fares-B25033
>>> 
>>> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail
>>> (pkathail at cisco.com) 
>>> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
>>> DPDK Userspace (was Notes from ...)
>>>
>>> Hi Margaret,
>>>
>>> On 11/02/2015 12:28 PM, CHIOSI, MARGARET T wrote:
 I think it is very important for the first version of governance that
>> we have ARM/SOC vendor/future contributors to be part of TSC.
 If based on historical contribution - they will be at a disadvantage.
 We need to have the DPDK organization support an API which supports a
>> broader set of chips.
>>> I think there is definitely a role for SOC vendors in the project
>> governance, but the TSC should be representative of the technical
>> contributors to the project, rather than an aspirational body aiming to
>> get more people involved.
>>> I think there is an opportunity for future contributors/users to form
>> a powerful constituency in the project, but the TSC is not the right
>> place for that to happen IMHO.
>>> Thanks,
>>> Dave.
>>>
 -Original Message-
 From: Stephen Hemminger [mailto:stephen at networkplumber.org]
 Sent: Monday, November 02, 2015 12:22 PM
 To: Bagh Fares
 Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; 
 Pradeep
 Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
 Subject: 

[dpdk-dev] [PATCH v3 6/6] test: add checks for cpu flags on armv8

[Hunt, David]

On 02/11/2015 13:17, Jerin Jacob wrote:
-snip--
> If am not wrong existing  rte_cpu_get_flag_enabled() implementation
> should be broken in your platform also for arm64. as I could see only AT_HWCAP
> not AT_HWCAP2 and AT_HWCAP is 0x7 that means your platform also
> follows
>
> http://lxr.free-electrons.com/source/arch/arm64/include/uapi/asm/hwcap.h
>
> and the implmentation is
>
> FEAT_DEF(SWP,   0x0001, 0, REG_HWCAP,  0) // not correct for arm64
> FEAT_DEF(HALF,  0x0001, 0, REG_HWCAP,  1) // not correct for arm64
> FEAT_DEF(THUMB, 0x0001, 0, REG_HWCAP,  2) // not correct for arm64
> FEAT_DEF(A26BIT,0x0001, 0, REG_HWCAP,  3)
--snip--
> FEAT_DEF(CRC32, 0x0001, 0, REG_HWCAP2,  4)
> FEAT_DEF(AARCH32,   0x0001, 0, REG_PLATFORM, 0)
> FEAT_DEF(AARCH64,   0x0001, 0, REG_PLATFORM, 1)
>
> Am I missing something ?

You are correct. I need to re-visit this. In merging the ARMv7 and 
ARVv8, I should have split the hardware capabilities flags into 32-but 
and 64-bit versions. I'll do that in the next patch.
Thanks,
Dave.

[dpdk-dev] [PATCH] doc: update release notes for e1000 base code update

[Wenzhuo Lu]

Signed-off-by: Wenzhuo Lu 
---
 doc/guides/rel_notes/release_2_2.rst | 110 +++
 1 file changed, 110 insertions(+)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index cf510e9..dc03905 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -57,6 +57,22 @@ New Features

 * **Added port hotplug support to xenvirt.**

+* **Updated the e1000 base driver.**
+  The e1000 base driver was updated with several features including the
+  following:
+
+  * Add new i218 devices
+  * Allow both ULP and EEE in Sx state
+  * Initialize 88E1543(Marvell 1543) PHY
+  * Add flags to set EEE advertisement modes
+  * Support inverted format ETrackId
+  * Add bit to disable packetbuffer read
+  * Add defaults for i210 Rx/Tx PBSIZE
+  * Check more errors for ESB2 init and reset
+  * Check more NVM read errors
+  * Return code after setting receive address register
+  * Remove all NAHUM6LP_HW tags.
+

 Resolved Issues
 ---
@@ -106,6 +122,100 @@ Drivers

   Fixed issue when releasing null control queue.

+* **e1000/base: Synchronize PHY interface on non-ME systems.**
+
+  On power up, the MAC - PHY interface needs to be set to PCIe, even if
+  cable is disconnected.  In ME systems, the ME handles this on exit from
+  Sx(Sticky mode) state. In non-ME, the driver handles it. Add a check
+  for non-ME system to the driver code that handles that.
+
+* **e1000/base: Increase timeout of reset check.**
+
+  Previously, in check_reset_block RSPCIPHY was polled for 100 ms before
+  determining that the ME veto is set. It's not enough. It need to be increased
+  to 300 ms.
+
+* **e1000/base: Disable IPv6 extension header parsing on 82575.**
+
+  Disable IPv6 options as per hardware limitation.
+
+* **e1000/base: Prevent ULP flow if cable connected.**
+
+  Enabling ulp on link down when cable is connect caused an infinite
+  loop of linkup/down indications in the NDIS driver.
+  After discussed, correct flow is to enable ULP only when cable is
+  disconnected.
+
+* **e1000/base: Support different EEARBC for i210.**
+
+  EEARBC has changed on i210. It means EEARBC has a different address on
+  i210 than on other NICs. So, add a new entity named EEARBC_I210 to the
+  register list and make sure the right one is being used on i210.
+
+* **e1000/base: Fix K1 configuration**
+
+  This patch is for the following updates to the K1 configurations:
+  Tx idle period for entering K1 should be 128 ns.
+  Minimum Tx idle period in K1 should be 256 ns.
+
+* **e1000/base: Fix link detect flow**
+
+  In case that auto-negotiate is not enabled, call
+  e1000_setup_copper_link_generic instead of e1000_phy_setup_autoneg.
+
+* **e1000/base: Fix link check for i354 M88E1112 PHY**
+
+  e1000_check_for_link_media_swap() is supposed to check PHY page 0 for
+  copper and PHY page 1 for "other" (fiber) link. We switched back from
+  page 1 to page 0 too soon, before e1000_check_for_link_82575() is
+  executed and we were never finding link on fiber (other).
+
+  If the link is copper, as the M88E1112 page address is set to 1, it should be
+  set back to 0 before checking this link.
+
+* **e1000/base: Fix beacon duration for i217**
+
+  Fix for I217 Packet Loss issue - The Management Engine sets the FEXTNVM4
+  Beacon Duration incorrectly.  This fix ensures that the correct value will
+  always be set. Correct value for this field is 8 usec.
+
+* **e1000/base: Fix TIPG for non 10 half duplex mode**
+
+  TIPG value is increased when setting speed to 10 half to prevent
+  packet loss. However, it was never decreased again when speed
+  changes. This caused performance issues in the NDIS driver.
+  Fix this to restore TIPG to default value on non 10 half.
+
+* **e1000/base: Fix reset of DH89XXCC SGMII**
+
+  For DH89XXCC_SGMII, write flush leaves registers of this device trashed
+  (0x). Add check for this device.
+  Also, after both for Port SW Reset and Device Reset case, platform should
+  wait at least 3ms before reading any registers. Since waiting is
+  conditionally executed only for Device Reset - remove the condition.
+
+* **e1000/base: Fix redundant PHY power down for i210**
+
+  Bit 11 of PHYREG 0 is used to power down PHY. The use of PHYREG 16 is
+  unnecessary any more.
+
+* **e1000/base: fix jumbo frame CRC failures**
+
+  change the value of register 776.20[11:2] for jumbo mode from 0x1A to 0x1F.
+  This is to enlarge the gap between read and write pointers in the TX Fifo.
+  And replace the magic number with a macro by the way.
+
+* **e1000/base: Fix link flap on 82579**
+
+  Several customers have reported a link flap issue on 82579. The symptoms
+  are random and intermittent link losses when 82579 is connected to specific
+  switches. Issue has been root caused as interoperability problem between
+  the NIC and at least some Broadcom PHYs in the Energy Efficient Ethernet
+  wake mechanism.
+  To fix the issue, we are 

[dpdk-dev] [PATCH v5 01/15] eal/arm: atomic operations for ARM

[Jan Viktorin]

On Mon, 2 Nov 2015 11:23:05 +0530
Jerin Jacob  wrote:

--snip--
> > +#ifndef _RTE_ATOMIC_ARM_H_
> > +#define _RTE_ATOMIC_ARM_H_
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include "generic/rte_atomic.h"
> > +
> > +/**
> > + * General memory barrier.
> > + *
> > + * Guarantees that the LOAD and STORE operations generated before the
> > + * barrier occur before the LOAD and STORE operations generated after.
> > + */
> > +#definerte_mb()  __sync_synchronize()
> > +
> > +/**
> > + * Write memory barrier.
> > + *
> > + * Guarantees that the STORE operations generated before the barrier
> > + * occur before the STORE operations generated after.
> > + */
> > +#definerte_wmb() do { asm volatile ("dmb st" : : : "memory"); } while 
> > (0)
> > +
> > +/**
> > + * Read memory barrier.
> > + *
> > + * Guarantees that the LOAD operations generated before the barrier
> > + * occur before the LOAD operations generated after.
> > + */
> > +#definerte_rmb() __sync_synchronize()
> > +  
> 
> #define dmb(opt)asm volatile("dmb " #opt : : : "memory")
> 
> static inline void rte_mb(void)
> {
> dmb(ish);
> }
> 
> static inline void rte_wmb(void)
> {
> dmb(ishst);
> }
> 
> static inline void rte_rmb(void)
> {
> dmb(ishld);

I cannot see this option in the doc for ARMv7
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0588b/CIHGHHIE.html).

> }
> 
> For armv8, it make sense to have above definition for rte_*mb().

If it is OK to restrict the barriers to the inner-domain then OK. Quite
frankly, I don't know.

> If doesn't make sense for armv7 then we need split this file 
> rte_atomic_32/64.h
> 
> 


-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH v5 01/15] eal/arm: atomic operations for ARM

[Jan Viktorin]

On Mon, 2 Nov 2015 11:23:05 +0530
Jerin Jacob  wrote:

--snip--
> > +/*- 16 bit atomic operations 
> > -*/
> > +
> > +#ifndef RTE_FORCE_INTRINSICS
> > +static inline int
> > +rte_atomic16_cmpset(volatile uint16_t *dst, uint16_t exp, uint16_t src)
> > +{
> > +   return __atomic_compare_exchange(dst, , , 0, __ATOMIC_ACQUIRE,
> > +   __ATOMIC_ACQUIRE) ? 1 : 0;
> > +}  
> 
> IMO, it should be __ATOMIC_SEQ_CST be instead of __ATOMIC_ACQUIRE.
> __ATOMIC_ACQUIRE works in conjunction with __ATOMIC_RELEASE.
> AFAIK, DPDK atomic api expects full barrier. C11 memory model not yet
> used.

Seems to be reasonable, thanks.

> So why can't we use RTE_FORCE_INTRINSICS based generic
> implementation. Same holds true for spinlock implementation too(i.e using
> RTE_FORCE_INTRINSICS). Am I missing something here ?

True. This was done with the intention to rewrite as a platform-specific
assembly. But it's never been done yet... If you mean to set
RTE_FORCE_INTRINSICS=y in the defconfig and remove this code entirely
(at least for ARMv7), I would agree.

> 
> 
> 
> > +
> > +static inline int rte_atomic16_test_and_set(rte_atomic16_t *v)
> > +{
> > +   return rte_atomic16_cmpset((volatile uint16_t *)>cnt, 0, 1);
> > +}
--snip--

-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH] app/testpmd: add 'show (rxq|txq)' command description into UG and cmdline help

[Konstantin Ananyev]

Signed-off-by: Konstantin Ananyev 
---
 app/test-pmd/cmdline.c  | 3 +++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0afdc96..ae9be81 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -199,6 +199,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"clear port (info|stats|xstats|fdir|stat_qmap) 
(port_id|all)\n"
"Clear information for port_id, or all.\n\n"

+   "show (rxq|txq) info (port_id) (queue_id)\n"
+   "Display information for configured RX/TX 
queue.\n\n"
+
"show config (rxtx|cores|fwd)\n"
"Display the given configuration.\n\n"

diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 2d0599d..ad9889d 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -205,6 +205,13 @@ For example::

testpmd> clear port stats all

+show (rxq|txq)
+~~
+
+Display information for a given port's RX/TX queue::
+
+   testpmd> show (rxq|txq) info (port_id) (queue_id)
+
 show config
 ~~~

-- 
1.8.5.3

[dpdk-dev] [PATCH v3 1/6] eal/arm: add 64-bit armv8 version of rte_memcpy.h

[Jan Viktorin]

On Mon, 2 Nov 2015 12:22:47 +
"Hunt, David"  wrote:

> On 02/11/2015 04:57, Jerin Jacob wrote:
> > On Fri, Oct 30, 2015 at 01:49:14PM +, David Hunt wrote:  
> >> Signed-off-by: David Hunt   
> --snip--
> >> +#ifndef _RTE_MEMCPY_ARM_64_H_
> >> +#define _RTE_MEMCPY_ARM_64_H_
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +#ifdef __cplusplus
> >> +extern "C" {
> >> +#endif
> >> +
> >> +#include "generic/rte_memcpy.h"
> >> +
> >> +#ifdef __ARM_NEON_FP  
> >
> > SIMD is not optional in armv8 spec.So every armv8 machine will have
> > SIMD instruction unlike armv7.More over LDP/STP instruction is
> > not part of SIMD.So this check is not required or it can
> > be replaced with a check that select memcpy from either libc or this 
> > specific
> > implementation  
> 
> Jerin,
> I've just benchmarked the libc version against the hand-coded 
> version of the memcpy routines, and the libc wins in most cases. This 
> code was just an initial attempt at optimising the memccpy's, so I feel 
> that with the current benchmark results, it would better just to remove 
> the assembly versions, and use the libc version for the initial release 
> on ARMv8.
> Then, in the future, the ARMv8 experts are free to submit an optimised 
> version as a patch in the future. Does that sound reasonable to you?
> Rgds,
> Dave.

As there is no use of NEON in the code, this optimization seems to be
useless to me...

Jan

> 
> 
> --snip--
> 
> 
> 



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCHv7 8/9] testpmd: add new command to display RX/TX queue information

[Ananyev, Konstantin]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Sunday, November 01, 2015 11:16 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org; Mcnamara, John
> Subject: Re: [dpdk-dev] [PATCHv7 8/9] testpmd: add new command to display 
> RX/TX queue information
> 
> 2015-10-27 12:51, Konstantin Ananyev:
> > Signed-off-by: Konstantin Ananyev 
> > ---
> >  app/test-pmd/cmdline.c | 48 +++
> >  app/test-pmd/config.c  | 77 
> > ++
> >  app/test-pmd/testpmd.h |  2 ++
> >  3 files changed, 127 insertions(+)
> 
> Should we update the testpmd guide?

Ah yes, forgot about that one.
Will send a separate patch then.
Thanks
Konstantin

[dpdk-dev] [PATCH] bnx2x: use bnx2xvf driver for VF devices

[Chas Williams]

Signed-off-by: Chas Williams <3chas3 at gmail.com>
---
 lib/librte_eal/common/include/rte_pci_dev_ids.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h 
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 93aa38a..c722e64 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -621,16 +621,16 @@ RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, 
PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
 #define BNX2X_DEV_ID_57840_VF  0x16ad

 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800_VF)
+RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800_VF)
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57711)
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810)
 RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810_VF)
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811_VF)
+RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811_VF)
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57840_OBS)
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57840_4_10)
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57840_2_20)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57840_VF)
+RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57840_VF)
 #ifdef RTE_LIBRTE_BNX2X_MF_SUPPORT
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810_MF)
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811_MF)
-- 
2.1.0

[dpdk-dev] [PATCH v2 2/2] vhost: Add VHOST PMD

[Tetsuya Mukawa]

The patch introduces a new PMD. This PMD is implemented as thin wrapper
of librte_vhost. It means librte_vhost is also needed to compile the PMD.
The vhost messages will be handled only when a port is started. So start
a port first, then invoke QEMU.

The PMD has 2 parameters.
 - iface:  The parameter is used to specify a path to connect to a
   virtio-net device.
 - queues: The parameter is used to specify the number of the queues
   virtio-net device has.
   (Default: 1)

Here is an example.
$ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i

To connect above testpmd, here is qemu command example.

$ qemu-system-x86_64 \

-chardev socket,id=chr0,path=/tmp/sock0 \
-netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
-device virtio-net-pci,netdev=net0

Signed-off-by: Tetsuya Mukawa 
---
 config/common_linuxapp  |   6 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/vhost.rst   |  82 +++
 doc/guides/rel_notes/release_2_2.rst|   2 +
 drivers/net/Makefile|   4 +
 drivers/net/vhost/Makefile  |  62 +++
 drivers/net/vhost/rte_eth_vhost.c   | 765 
 drivers/net/vhost/rte_eth_vhost.h   |  65 +++
 drivers/net/vhost/rte_pmd_vhost_version.map |   8 +
 mk/rte.app.mk   |   8 +-
 10 files changed, 1002 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/nics/vhost.rst
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

diff --git a/config/common_linuxapp b/config/common_linuxapp
index c1d4bbd..fd103e7 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -457,6 +457,12 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 CONFIG_RTE_LIBRTE_VHOST_DEBUG=n

 #
+# Compile vhost PMD
+# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
+#
+CONFIG_RTE_LIBRTE_PMD_VHOST=y
+
+#
 #Compile Xen domain0 support
 #
 CONFIG_RTE_LIBRTE_XEN_DOM0=n
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 2d4936d..57d1041 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -47,6 +47,7 @@ Network Interface Controller Drivers
 mlx4
 mlx5
 virtio
+vhost
 vmxnet3
 pcap_ring

diff --git a/doc/guides/nics/vhost.rst b/doc/guides/nics/vhost.rst
new file mode 100644
index 000..2ec8d79
--- /dev/null
+++ b/doc/guides/nics/vhost.rst
@@ -0,0 +1,82 @@
+..  BSD LICENSE
+Copyright(c) 2015 IGEL Co., Ltd.. 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 IGEL Co., Ltd. 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.
+
+Poll Mode Driver that wraps vhost library
+=
+
+This PMD is a thin wrapper of the DPDK vhost library.
+The User can handle virtqueues as one of normal DPDK port.
+
+Vhost Implementation in DPDK
+
+
+Please refer to Chapter "Vhost Library" of Programmer's Guide to know detail 
of vhost.
+
+Features and Limitations of vhost PMD
+-
+
+In this release, the vhost PMD provides the basic functionality of packet 
reception and transmission.
+
+*   It provides the function to convert port_id to a pointer of virtio_net 
device.
+It allows the user to use vhost library with the PMD in parallel.
+
+*   

[dpdk-dev] [PATCH v2 1/2] vhost: Add callback and private data for vhost PMD

[Tetsuya Mukawa]

These variables are needed to be able to manage one of virtio devices
using both vhost library APIs and vhost PMD.
For example, if vhost PMD uses current callback handler and private data
provided by vhost library, A DPDK application that links vhost library
cannot use some of vhost library APIs. To avoid it, callback and private
data for vhost PMD are needed.

Signed-off-by: Tetsuya Mukawa 
---
 lib/librte_vhost/rte_vhost_version.map|  6 +++
 lib/librte_vhost/rte_virtio_net.h |  3 ++
 lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +++
 lib/librte_vhost/virtio-net.c | 56 +--
 lib/librte_vhost/virtio-net.h |  4 +-
 5 files changed, 70 insertions(+), 12 deletions(-)

diff --git a/lib/librte_vhost/rte_vhost_version.map 
b/lib/librte_vhost/rte_vhost_version.map
index 3d8709e..00a9ce5 100644
--- a/lib/librte_vhost/rte_vhost_version.map
+++ b/lib/librte_vhost/rte_vhost_version.map
@@ -20,3 +20,9 @@ DPDK_2.1 {
rte_vhost_driver_unregister;

 } DPDK_2.0;
+
+DPDK_2.2 {
+   global:
+
+   rte_vhost_driver_pmd_callback_register;
+} DPDK_2.1;
diff --git a/lib/librte_vhost/rte_virtio_net.h 
b/lib/librte_vhost/rte_virtio_net.h
index b6386f9..033edde 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -121,6 +121,7 @@ struct virtio_net {
charifname[IF_NAME_SZ]; /**< Name of the tap 
device or socket path. */
uint32_tvirt_qp_nb; /**< number of queue pair we 
have allocated */
void*priv;  /**< private context */
+   void*pmd_priv;  /**< private context for vhost 
PMD */
struct vhost_virtqueue  *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];  /**< 
Contains all virtqueue information. */
 } __rte_cache_aligned;

@@ -217,6 +218,8 @@ int rte_vhost_driver_unregister(const char *dev_name);

 /* Register callbacks. */
 int rte_vhost_driver_callback_register(struct virtio_net_device_ops const * 
const);
+/* Register callbacks for vhost PMD (Only for internal). */
+int rte_vhost_driver_pmd_callback_register(struct virtio_net_device_ops const 
* const);
 /* Start vhost driver session blocking loop. */
 int rte_vhost_driver_session_start(void);

diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c 
b/lib/librte_vhost/vhost_user/virtio-net-user.c
index d07452a..d8ae2fc 100644
--- a/lib/librte_vhost/vhost_user/virtio-net-user.c
+++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
@@ -111,7 +111,7 @@ user_set_mem_table(struct vhost_device_ctx ctx, struct 
VhostUserMsg *pmsg)

/* Remove from the data plane. */
if (dev->flags & VIRTIO_DEV_RUNNING)
-   notify_ops->destroy_device(dev);
+   notify_destroy_device(dev);

if (dev->mem) {
free_mem_region(dev);
@@ -272,7 +272,7 @@ user_set_vring_kick(struct vhost_device_ctx ctx, struct 
VhostUserMsg *pmsg)

if (virtio_is_ready(dev) &&
!(dev->flags & VIRTIO_DEV_RUNNING))
-   notify_ops->new_device(dev);
+   notify_new_device(dev);
 }

 /*
@@ -288,7 +288,7 @@ user_get_vring_base(struct vhost_device_ctx ctx,
return -1;
/* We have to stop the queue (virtio) if it is running. */
if (dev->flags & VIRTIO_DEV_RUNNING)
-   notify_ops->destroy_device(dev);
+   notify_destroy_device(dev);

/* Here we are safe to get the last used index */
ops->get_vring_base(ctx, state->index, state);
@@ -324,10 +324,7 @@ user_set_vring_enable(struct vhost_device_ctx ctx,
"set queue enable: %d to qp idx: %d\n",
enable, state->index);

-   if (notify_ops->vring_state_changed) {
-   notify_ops->vring_state_changed(dev, base_idx / VIRTIO_QNUM,
-   enable);
-   }
+   notify_vring_state_changed(dev, base_idx / VIRTIO_QNUM, enable);

dev->virtqueue[base_idx + VIRTIO_RXQ]->enabled = enable;
dev->virtqueue[base_idx + VIRTIO_TXQ]->enabled = enable;
@@ -341,7 +338,7 @@ user_destroy_device(struct vhost_device_ctx ctx)
struct virtio_net *dev = get_device(ctx);

if (dev && (dev->flags & VIRTIO_DEV_RUNNING))
-   notify_ops->destroy_device(dev);
+   notify_destroy_device(dev);

if (dev && dev->mem) {
free_mem_region(dev);
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 3e82605..ee54beb 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -65,6 +65,8 @@ struct virtio_net_config_ll {

 /* device ops to add/remove device to/from data core. */
 struct virtio_net_device_ops const *notify_ops;
+/* device ops for vhost PMD to add/remove device to/from data core. */
+struct virtio_net_device_ops const *pmd_notify_ops;
 /* root address of the linked list 

[dpdk-dev] [PATCH v2 0/2] Add VHOST PMD

[Tetsuya Mukawa]

The patch introduces a new PMD. This PMD is implemented as thin wrapper
of librte_vhost. The patch will work on below patch series.
 - [PATCH v7 00/28] remove pci driver from vdevs

* Known issue.
We may see issues while handling RESET_OWNER message.
These handlings are done in vhost library, so not a part of vhost PMD.
So far, we are waiting for QEMU fixing.

PATCH v2 changes:
 - Remove a below patch that fixes vhost library.
   The patch was applied as a separate patch.
   - vhost: fix crash with multiqueue enabled
 - Fix typos.
   (Thanks to Thomas, Monjalon)
 - Rebase on latest tree with above bernard's patches.

PATCH v1 changes:
 - Support vhost multiple queues.
 - Rebase on "remove pci driver from vdevs".
 - Optimize RX/TX functions.
 - Fix resource leaks.
 - Fix compile issue.
 - Add patch to fix vhost library.

RFC PATCH v3 changes:
 - Optimize performance.
   In RX/TX functions, change code to access only per core data.
 - Add below API to allow user to use vhost library APIs for a port managed
   by vhost PMD. There are a few limitations. See "rte_eth_vhost.h".
- rte_eth_vhost_portid2vdev()
   To support this functionality, vhost library is also changed.
   Anyway, if users doesn't use vhost PMD, can fully use vhost library APIs.
 - Add code to support vhost multiple queues.
   Actually, multiple queues functionality is not enabled so far.

RFC PATCH v2 changes:
 - Fix issues reported by checkpatch.pl
   (Thanks to Stephen Hemminger)


Tetsuya Mukawa (2):
  vhost: Add callback and private data for vhost PMD
  vhost: Add VHOST PMD

 config/common_linuxapp|   6 +
 doc/guides/nics/index.rst |   1 +
 doc/guides/nics/vhost.rst |  82 +++
 doc/guides/rel_notes/release_2_2.rst  |   2 +
 drivers/net/Makefile  |   4 +
 drivers/net/vhost/Makefile|  62 +++
 drivers/net/vhost/rte_eth_vhost.c | 765 ++
 drivers/net/vhost/rte_eth_vhost.h |  65 +++
 drivers/net/vhost/rte_pmd_vhost_version.map   |   8 +
 lib/librte_vhost/rte_vhost_version.map|   6 +
 lib/librte_vhost/rte_virtio_net.h |   3 +
 lib/librte_vhost/vhost_user/virtio-net-user.c |  13 +-
 lib/librte_vhost/virtio-net.c |  56 +-
 lib/librte_vhost/virtio-net.h |   4 +-
 mk/rte.app.mk |   8 +-
 15 files changed, 1072 insertions(+), 13 deletions(-)
 create mode 100644 doc/guides/nics/vhost.rst
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

-- 
2.1.4

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Dave Neary]

Hi,

On the contrary! I am aware that Freescale has been engaged for some
time in DPDK. I was responding to Margaret's contention that future
contributors (and she called out ARM and SOC vendors) should have a voice.

I hope that clarifies my position and meaning.

Thanks,
Dave.

On 11/02/2015 12:44 PM, Bagh Fares wrote:
> As SOC vendor we will contribute heavily to the project. Example crypto 
> acceleration. We already contribute a lot to the linux community. 
> So not sure why the doubt about of contribution?
> 
> 
> -Original Message-
> From: Dave Neary [mailto:dneary at redhat.com] 
> Sent: Monday, November 02, 2015 11:31 AM
> To: CHIOSI, MARGARET T ; Stephen Hemminger  networkplumber.org>; Bagh Fares-B25033 
> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail (pkathail at 
> cisco.com) 
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK 
> Userspace (was Notes from ...)
> 
> Hi Margaret,
> 
> On 11/02/2015 12:28 PM, CHIOSI, MARGARET T wrote:
>> I think it is very important for the first version of governance that we 
>> have ARM/SOC vendor/future contributors to be part of TSC.
>> If based on historical contribution - they will be at a disadvantage.
>> We need to have the DPDK organization support an API which supports a 
>> broader set of chips.
> 
> I think there is definitely a role for SOC vendors in the project governance, 
> but the TSC should be representative of the technical contributors to the 
> project, rather than an aspirational body aiming to get more people involved.
> 
> I think there is an opportunity for future contributors/users to form a 
> powerful constituency in the project, but the TSC is not the right place for 
> that to happen IMHO.
> 
> Thanks,
> Dave.
> 
>> -Original Message-
>> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
>> Sent: Monday, November 02, 2015 12:22 PM
>> To: Bagh Fares
>> Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; 
>> Pradeep 
>> Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
>> Subject: Re: [dpdk-dev] Proposals from project governance meeting at 
>> DPDK Userspace (was Notes from ...)
>>
>> There were two outcomes.
>>
>> One was a proposal to move governance under Linux Foundation.
>>
>> The other was to have a technical steering committee.
>> It was agreed the TSC would be based on the contributors to the 
>> project, although we didn't come to a conclusion on a voting model.
>>
>>
>> I would propose that TSC should be elected at regular user summit from 
>> nominees; in a manner similar to LF Technical Advisory Board.
>>
> 
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Dave Neary]

Hi Margaret,

On 11/02/2015 12:28 PM, CHIOSI, MARGARET T wrote:
> I think it is very important for the first version of governance that we have 
> ARM/SOC vendor/future contributors to be part of TSC.
> If based on historical contribution - they will be at a disadvantage.
> We need to have the DPDK organization support an API which supports a broader 
> set of chips.

I think there is definitely a role for SOC vendors in the project
governance, but the TSC should be representative of the technical
contributors to the project, rather than an aspirational body aiming to
get more people involved.

I think there is an opportunity for future contributors/users to form a
powerful constituency in the project, but the TSC is not the right place
for that to happen IMHO.

Thanks,
Dave.

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org] 
> Sent: Monday, November 02, 2015 12:22 PM
> To: Bagh Fares
> Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; Pradeep 
> Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK 
> Userspace (was Notes from ...)
> 
> There were two outcomes.
> 
> One was a proposal to move governance under Linux Foundation.
> 
> The other was to have a technical steering committee.
> It was agreed the TSC would be based on the contributors to the project,
> although we didn't come to a conclusion on a voting model.
> 
> 
> I would propose that TSC should be elected at regular user summit from 
> nominees;
> in a manner similar to LF Technical Advisory Board.
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[dpdk-dev] [PATCH v5 9/9] nfp: adding maintainers and release info

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 MAINTAINERS  |5 +
 doc/guides/rel_notes/release_2_2.rst |4 
 2 files changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7b1e079..284d93c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -260,6 +260,11 @@ M: Adrien Mazarguil 
 F: drivers/net/mlx5/
 F: doc/guides/nics/mlx5.rst

+Netronome nfp
+M: Alejandro Lucero 
+F: drivers/net/nfp/
+F: doc/guides/nics/nfp.rst
+
 RedHat virtio
 M: Huawei Xie 
 M: Changchun Ouyang 
diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 8a20044..865317a 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -108,6 +108,10 @@ Drivers

   Fixed issue when releasing null control queue.

+* **nfp: New PMD for Netronome nfp-6xxx card.**
+
+  New PMD integrated with DPDK build.
+

 Libraries
 ~
-- 
1.7.9.5

[dpdk-dev] [PATCH v5 8/9] nfp: adding nic guide

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 doc/guides/nics/index.rst |1 +
 doc/guides/nics/nfp.rst   |  189 +
 2 files changed, 190 insertions(+)
 create mode 100644 doc/guides/nics/nfp.rst

diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 2d4936d..1a7bffe 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -46,6 +46,7 @@ Network Interface Controller Drivers
 intel_vf
 mlx4
 mlx5
+nfp
 virtio
 vmxnet3
 pcap_ring
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
new file mode 100644
index 000..bb2afda
--- /dev/null
+++ b/doc/guides/nics/nfp.rst
@@ -0,0 +1,189 @@
+..  BSD LICENSE
+Copyright(c) 2015 Netronome Systems, Inc. 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.
+
+NFP poll mode driver library
+
+
+Netronome's sixth generation of flow processors pack 216 programmable
+cores and over 100 hardware accelerators that uniquely combine packet,
+flow, security and content processing in a single device that scales
+up to 400 Gbps.
+
+This document explains how to use DPDK with the Netronome Poll Mode
+Driver (PMD) supporting Netronome's Network Flow Processor 6xxx
+(NFP-6xxx).
+
+Currently the driver supports virtual functions (VFs) only.
+
+Dependencies
+
+
+Before using the Netronome's DPDK PMD some NFP-6xxx configuration,
+which is not related to DPDK, is required. The system requires
+installation of **Netronome's BSP (Board Support Package)** which includes
+Linux drivers, programs and libraries.
+
+If you have a NFP-6xxx device you should already have the code and
+documentation for doing this configuration. Contact
+**support at netronome.com** to obtain the latest available firmware.
+
+The NFP Linux kernel drivers (including the required PF driver for the
+NFP) are available on Github at
+**https://github.com/Netronome/nfp-drv-kmods** along with build
+instructions.
+
+Using Netronome?s NFP PMD requires to have the Netronome?s BSP module
+loaded.
+
+Building the software
+-
+
+Netronome's PMD code is provided in the **drivers/net/nfp** directory.
+This PMD is included as part of the DPDK **common_linuxapp configuration**
+file, but it is not enabled by default. If it is enabled without a BSP
+installed in the system, the compilation will fail.
+
+For enabling the PMD, just modifies the **common_linuxapp** file with:
+
+- **CONFIG_RTE_LIBRTE_NFP_PMD=y**
+
+Once DPDK is built all the DPDK apps and examples include support for
+the NFP PMD.
+
+System configuration
+
+
+Using the NFP PMD is not different to using other PMDs. Usual steps are:
+
+#. **Configure hugepages:** All major Linux distributions have the hugepages
+   functionality enabled by default. By default this allows the system uses for
+   working with transparent hugepages. But in this case some hugepages need to
+   be created/reserved for use with the DPDK through the hugetlbfs file system.
+   First the virtual file system need to be mounted:
+
+   .. code-block:: console
+
+  mount -t hugetlbfs none /mnt/hugetlbfs
+
+   The command uses the common mount point for this file system and it needs to
+   be created if necessary.
+
+   Configuring hugepages is performed via sysfs:
+
+   .. code-block:: console
+
+  

[dpdk-dev] [PATCH v5 7/9] nfp: integration with dpdk build system

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 config/common_linuxapp |6 ++
 drivers/net/Makefile   |1 +
 mk/rte.app.mk  |1 +
 3 files changed, 8 insertions(+)

diff --git a/config/common_linuxapp b/config/common_linuxapp
index c1d4bbd..7ae1e94 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -249,6 +249,12 @@ CONFIG_RTE_LIBRTE_ENIC_PMD=y
 CONFIG_RTE_LIBRTE_ENIC_DEBUG=n

 #
+# Compile burst-oriented Netronome NFP PMD driver
+#
+CONFIG_RTE_LIBRTE_NFP_PMD=n
+CONFIG_RTE_LIBRTE_NFP_DEBUG=n
+
+#
 # Compile burst-oriented VIRTIO PMD driver
 #
 CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6da1ce2..9d5cb78 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -42,6 +42,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e
 DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe
 DIRS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4
 DIRS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5
+DIRS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += nfp
 DIRS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += mpipe
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += null
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += pcap
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 724efa7..cf4756c 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -142,6 +142,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD)  += 
-lrte_pmd_ixgbe
 _LDLIBS-$(CONFIG_RTE_LIBRTE_E1000_PMD)  += -lrte_pmd_e1000
 _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD)   += -lrte_pmd_mlx4
 _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD)   += -lrte_pmd_mlx5
+_LDLIBS-$(CONFIG_RTE_LIBRTE_NFP_PMD)+= -lrte_pmd_nfp
 _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD)  += -lrte_pmd_mpipe -lgxio
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING)   += -lrte_pmd_ring
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP)   += -lrte_pmd_pcap
-- 
1.7.9.5

[dpdk-dev] [PATCH v5 6/9] nfp: adding functionality to pmd

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

 - nfp_net_promisc_enable
 - nfp_net_promisc_disable
 - nfp_net_infos_get
 - nfp_net_dev_mtu_set
 - nfp_net_vlan_offload_set

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 drivers/net/nfp/nfp_net.c |  181 +
 1 file changed, 181 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 9cc7776..98c835e 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -739,6 +739,65 @@ nfp_net_close(struct rte_eth_dev *dev)
 */
 }

+static void
+nfp_net_promisc_enable(struct rte_eth_dev *dev)
+{
+   uint32_t new_ctrl, update = 0;
+   struct nfp_net_hw *hw;
+
+   PMD_DRV_LOG(DEBUG, "Promiscuous mode enable\n");
+
+   hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   if (!(hw->cap & NFP_NET_CFG_CTRL_PROMISC)) {
+   PMD_INIT_LOG(INFO, "Promiscuous mode not supported\n");
+   return;
+   }
+
+   if (hw->ctrl & NFP_NET_CFG_CTRL_PROMISC) {
+   PMD_DRV_LOG(INFO, "Promiscuous mode already enabled\n");
+   return;
+   }
+
+   new_ctrl = hw->ctrl | NFP_NET_CFG_CTRL_PROMISC;
+   update = NFP_NET_CFG_UPDATE_GEN;
+
+   /*
+* DPDK sets promiscuous mode on just after this call assuming
+* it can not fail ...
+*/
+   if (nfp_net_reconfig(hw, new_ctrl, update) < 0)
+   return;
+
+   hw->ctrl = new_ctrl;
+}
+
+static void
+nfp_net_promisc_disable(struct rte_eth_dev *dev)
+{
+   uint32_t new_ctrl, update = 0;
+   struct nfp_net_hw *hw;
+
+   hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   if ((hw->ctrl & NFP_NET_CFG_CTRL_PROMISC) == 0) {
+   PMD_DRV_LOG(INFO, "Promiscuous mode already disabled\n");
+   return;
+   }
+
+   new_ctrl = hw->ctrl & ~NFP_NET_CFG_CTRL_PROMISC;
+   update = NFP_NET_CFG_UPDATE_GEN;
+
+   /*
+* DPDK sets promiscuous mode off just before this call
+* assuming it can not fail ...
+*/
+   if (nfp_net_reconfig(hw, new_ctrl, update) < 0)
+   return;
+
+   hw->ctrl = new_ctrl;
+}
+
 /*
  * return 0 means link status changed, -1 means not changed
  *
@@ -953,6 +1012,65 @@ nfp_net_stats_reset(struct rte_eth_dev *dev)
nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_DISCARDS);
 }

+static void
+nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
+{
+   struct nfp_net_hw *hw;
+
+   hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   dev_info->driver_name = dev->driver->pci_drv.name;
+   dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
+   dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
+   dev_info->min_rx_bufsize = ETHER_MIN_MTU;
+   dev_info->max_rx_pktlen = hw->max_mtu;
+   /* Next should change when PF support is implemented */
+   dev_info->max_mac_addrs = 1;
+
+   if (hw->cap & NFP_NET_CFG_CTRL_RXVLAN)
+   dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+
+   if (hw->cap & NFP_NET_CFG_CTRL_RXCSUM)
+   dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_IPV4_CKSUM |
+DEV_RX_OFFLOAD_UDP_CKSUM |
+DEV_RX_OFFLOAD_TCP_CKSUM;
+
+   if (hw->cap & NFP_NET_CFG_CTRL_TXVLAN)
+   dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT;
+
+   if (hw->cap & NFP_NET_CFG_CTRL_TXCSUM)
+   dev_info->tx_offload_capa |= DEV_TX_OFFLOAD_IPV4_CKSUM |
+DEV_RX_OFFLOAD_UDP_CKSUM |
+DEV_RX_OFFLOAD_TCP_CKSUM;
+
+   dev_info->default_rxconf = (struct rte_eth_rxconf) {
+   .rx_thresh = {
+   .pthresh = DEFAULT_RX_PTHRESH,
+   .hthresh = DEFAULT_RX_HTHRESH,
+   .wthresh = DEFAULT_RX_WTHRESH,
+   },
+   .rx_free_thresh = DEFAULT_RX_FREE_THRESH,
+   .rx_drop_en = 0,
+   };
+
+   dev_info->default_txconf = (struct rte_eth_txconf) {
+   .tx_thresh = {
+   .pthresh = DEFAULT_TX_PTHRESH,
+   .hthresh = DEFAULT_TX_HTHRESH,
+   .wthresh = DEFAULT_TX_WTHRESH,
+   },
+   .tx_free_thresh = DEFAULT_TX_FREE_THRESH,
+   .tx_rs_thresh = DEFAULT_TX_RSBIT_THRESH,
+   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
+ETH_TXQ_FLAGS_NOOFFLOADS,
+   };
+
+   dev_info->reta_size = NFP_NET_CFG_RSS_ITBL_SZ;
+#if RTE_VER_MAJOR == 2 && RTE_VER_MINOR >= 1
+   dev_info->hash_key_size = NFP_NET_CFG_RSS_KEY_SZ;
+#endif
+}
+
 static uint32_t
 nfp_net_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx)
 {
@@ -998,6 +1116,34 @@ 

[dpdk-dev] [PATCH v5 5/9] nfp: adding link functionality

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 drivers/net/nfp/nfp_net.c |   94 +
 1 file changed, 94 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index e1badc3..9cc7776 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -232,6 +232,57 @@ ring_dma_zone_reserve(struct rte_eth_dev *dev, const char 
*ring_name,
   NFP_MEMZONE_ALIGN);
 }

+/*
+ * Atomically reads link status information from global structure rte_eth_dev.
+ *
+ * @param dev
+ *   - Pointer to the structure rte_eth_dev to read from.
+ *   - Pointer to the buffer to be saved with the link status.
+ *
+ * @return
+ *   - On success, zero.
+ *   - On failure, negative value.
+ */
+static inline int
+nfp_net_dev_atomic_read_link_status(struct rte_eth_dev *dev,
+   struct rte_eth_link *link)
+{
+   struct rte_eth_link *dst = link;
+   struct rte_eth_link *src = >data->dev_link;
+
+   if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
+   *(uint64_t *)src) == 0)
+   return -1;
+
+   return 0;
+}
+
+/*
+ * Atomically writes the link status information into global
+ * structure rte_eth_dev.
+ *
+ * @param dev
+ *   - Pointer to the structure rte_eth_dev to read from.
+ *   - Pointer to the buffer to be saved with the link status.
+ *
+ * @return
+ *   - On success, zero.
+ *   - On failure, negative value.
+ */
+static inline int
+nfp_net_dev_atomic_write_link_status(struct rte_eth_dev *dev,
+struct rte_eth_link *link)
+{
+   struct rte_eth_link *dst = >data->dev_link;
+   struct rte_eth_link *src = link;
+
+   if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
+   *(uint64_t *)src) == 0)
+   return -1;
+
+   return 0;
+}
+
 static void
 nfp_net_rx_queue_release_mbufs(struct nfp_net_rxq *rxq)
 {
@@ -688,6 +739,49 @@ nfp_net_close(struct rte_eth_dev *dev)
 */
 }

+/*
+ * return 0 means link status changed, -1 means not changed
+ *
+ * Wait to complete is needed as it can take up to 9 seconds to get the Link
+ * status.
+ */
+static int
+nfp_net_link_update(struct rte_eth_dev *dev, __rte_unused int wait_to_complete)
+{
+   struct nfp_net_hw *hw;
+   struct rte_eth_link link, old;
+   uint32_t nn_link_status;
+
+   PMD_DRV_LOG(DEBUG, "Link update\n");
+
+   hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   memset(, 0, sizeof(old));
+   nfp_net_dev_atomic_read_link_status(dev, );
+
+   nn_link_status = nn_cfg_readl(hw, NFP_NET_CFG_STS);
+
+   memset(, 0, sizeof(struct rte_eth_link));
+
+   if (nn_link_status & NFP_NET_CFG_STS_LINK)
+   link.link_status = 1;
+
+   link.link_duplex = ETH_LINK_FULL_DUPLEX;
+   /* Other cards can limit the tx and rx rate per VF */
+   link.link_speed = ETH_LINK_SPEED_40G;
+
+   if (old.link_status != link.link_status) {
+   nfp_net_dev_atomic_write_link_status(dev, );
+   if (link.link_status)
+   PMD_DRV_LOG(INFO, "NIC Link is Up\n");
+   else
+   PMD_DRV_LOG(INFO, "NIC Link is Down\n");
+   return 0;
+   }
+
+   return -1;
+}
+
 static void
 nfp_net_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
 {
-- 
1.7.9.5

[dpdk-dev] [PATCH v5 4/9] nfp: adding stats functionality

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 drivers/net/nfp/nfp_net.c |  171 +
 1 file changed, 171 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 51855b1..e1badc3 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -688,6 +688,177 @@ nfp_net_close(struct rte_eth_dev *dev)
 */
 }

+static void
+nfp_net_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
+{
+   int i;
+   struct nfp_net_hw *hw;
+   struct rte_eth_stats nfp_dev_stats;
+
+   hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* RTE_ETHDEV_QUEUE_STAT_CNTRS default value is 16 */
+
+   /* reading per RX ring stats */
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   if (i == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+   break;
+
+   nfp_dev_stats.q_ipackets[i] =
+   nn_cfg_readq(hw, NFP_NET_CFG_RXR_STATS(i));
+
+   nfp_dev_stats.q_ipackets[i] -=
+   hw->eth_stats_base.q_ipackets[i];
+
+   nfp_dev_stats.q_ibytes[i] =
+   nn_cfg_readq(hw, NFP_NET_CFG_RXR_STATS(i) + 0x8);
+
+   nfp_dev_stats.q_ibytes[i] -=
+   hw->eth_stats_base.q_ibytes[i];
+   }
+
+   /* reading per TX ring stats */
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   if (i == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+   break;
+
+   nfp_dev_stats.q_opackets[i] =
+   nn_cfg_readq(hw, NFP_NET_CFG_TXR_STATS(i));
+
+   nfp_dev_stats.q_opackets[i] -=
+   hw->eth_stats_base.q_opackets[i];
+
+   nfp_dev_stats.q_obytes[i] =
+   nn_cfg_readq(hw, NFP_NET_CFG_TXR_STATS(i) + 0x8);
+
+   nfp_dev_stats.q_obytes[i] -=
+   hw->eth_stats_base.q_obytes[i];
+   }
+
+   nfp_dev_stats.ipackets =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_FRAMES);
+
+   nfp_dev_stats.ipackets -= hw->eth_stats_base.ipackets;
+
+   nfp_dev_stats.ibytes =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_OCTETS);
+
+   nfp_dev_stats.ibytes -= hw->eth_stats_base.ibytes;
+
+   nfp_dev_stats.opackets =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_TX_FRAMES);
+
+   nfp_dev_stats.opackets -= hw->eth_stats_base.opackets;
+
+   nfp_dev_stats.obytes =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_TX_OCTETS);
+
+   nfp_dev_stats.obytes -= hw->eth_stats_base.obytes;
+
+   nfp_dev_stats.imcasts =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_MC_FRAMES);
+
+   nfp_dev_stats.imcasts -= hw->eth_stats_base.imcasts;
+
+   /* reading general device stats */
+   nfp_dev_stats.ierrors =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_ERRORS);
+
+   nfp_dev_stats.ierrors -= hw->eth_stats_base.ierrors;
+
+   nfp_dev_stats.oerrors =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_TX_ERRORS);
+
+   nfp_dev_stats.oerrors -= hw->eth_stats_base.oerrors;
+
+   /* Multicast frames received */
+   nfp_dev_stats.imcasts =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_MC_FRAMES);
+
+   nfp_dev_stats.imcasts -= hw->eth_stats_base.imcasts;
+
+   /* RX ring mbuf allocation failures */
+   nfp_dev_stats.rx_nombuf = dev->data->rx_mbuf_alloc_failed;
+
+   nfp_dev_stats.imissed =
+   nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_DISCARDS);
+
+   nfp_dev_stats.imissed -= hw->eth_stats_base.imissed;
+
+   if (stats)
+   memcpy(stats, _dev_stats, sizeof(*stats));
+}
+
+static void
+nfp_net_stats_reset(struct rte_eth_dev *dev)
+{
+   int i;
+   struct nfp_net_hw *hw;
+
+   hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /*
+* hw->eth_stats_base records the per counter starting point.
+* Lets update it now
+*/
+
+   /* reading per RX ring stats */
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   if (i == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+   break;
+
+   hw->eth_stats_base.q_ipackets[i] =
+   nn_cfg_readq(hw, NFP_NET_CFG_RXR_STATS(i));
+
+   hw->eth_stats_base.q_ibytes[i] =
+   nn_cfg_readq(hw, NFP_NET_CFG_RXR_STATS(i) + 0x8);
+   }
+
+   /* reading per TX ring stats */
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   if (i == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+   break;
+
+   hw->eth_stats_base.q_opackets[i] =
+   nn_cfg_readq(hw, NFP_NET_CFG_TXR_STATS(i));
+
+   hw->eth_stats_base.q_obytes[i] =
+   nn_cfg_readq(hw, NFP_NET_CFG_TXR_STATS(i) + 0x8);
+   }
+
+   

[dpdk-dev] [PATCH v5 3/9] nfp: adding rss functionality

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 drivers/net/nfp/nfp_net.c |  214 +
 1 file changed, 214 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 8339c2d..51855b1 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1503,6 +1503,220 @@ xmit_end:
return i;
 }

+/* Update Redirection Table(RETA) of Receive Side Scaling of Ethernet device */
+static int
+nfp_net_reta_update(struct rte_eth_dev *dev,
+   struct rte_eth_rss_reta_entry64 *reta_conf,
+   uint16_t reta_size)
+{
+   uint32_t reta, mask;
+   int i, j;
+   int idx, shift;
+   uint32_t update;
+   struct nfp_net_hw *hw =
+   NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   if (!(hw->ctrl & NFP_NET_CFG_CTRL_RSS))
+   return -EINVAL;
+
+   if (reta_size != NFP_NET_CFG_RSS_ITBL_SZ) {
+   RTE_LOG(ERR, PMD, "The size of hash lookup table configured "
+   "(%d) doesn't match the number hardware can supported "
+   "(%d)\n", reta_size, NFP_NET_CFG_RSS_ITBL_SZ);
+   return -EINVAL;
+   }
+
+   /*
+* Update Redirection Table. There are 128 8bit-entries which can be
+* manage as 32 32bit-entries
+*/
+   for (i = 0; i < reta_size; i += 4) {
+   /* Handling 4 RSS entries per loop */
+   idx = i / RTE_RETA_GROUP_SIZE;
+   shift = i % RTE_RETA_GROUP_SIZE;
+   mask = (uint8_t)((reta_conf[idx].mask >> shift) & 0xF);
+
+   if (!mask)
+   continue;
+
+   reta = 0;
+   /* If all 4 entries were set, don't need read RETA register */
+   if (mask != 0xF)
+   reta = nn_cfg_readl(hw, NFP_NET_CFG_RSS_ITBL + i);
+
+   for (j = 0; j < 4; j++) {
+   if (!(mask & (0x1 << j)))
+   continue;
+   if (mask != 0xF)
+   /* Clearing the entry bits */
+   reta &= ~(0xFF << (8 * j));
+   reta |= reta_conf[idx].reta[shift + j] << (8 * j);
+   }
+   nn_cfg_writel(hw, NFP_NET_CFG_RSS_ITBL + shift, reta);
+   }
+
+   update = NFP_NET_CFG_UPDATE_RSS;
+
+   if (nfp_net_reconfig(hw, hw->ctrl, update) < 0)
+   return -EIO;
+
+   return 0;
+}
+
+ /* Query Redirection Table(RETA) of Receive Side Scaling of Ethernet device. 
*/
+static int
+nfp_net_reta_query(struct rte_eth_dev *dev,
+  struct rte_eth_rss_reta_entry64 *reta_conf,
+  uint16_t reta_size)
+{
+   uint8_t i, j, mask;
+   int idx, shift;
+   uint32_t reta;
+   struct nfp_net_hw *hw;
+
+   hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   if (!(hw->ctrl & NFP_NET_CFG_CTRL_RSS))
+   return -EINVAL;
+
+   if (reta_size != NFP_NET_CFG_RSS_ITBL_SZ) {
+   RTE_LOG(ERR, PMD, "The size of hash lookup table configured "
+   "(%d) doesn't match the number hardware can supported "
+   "(%d)\n", reta_size, NFP_NET_CFG_RSS_ITBL_SZ);
+   return -EINVAL;
+   }
+
+   /*
+* Reading Redirection Table. There are 128 8bit-entries which can be
+* manage as 32 32bit-entries
+*/
+   for (i = 0; i < reta_size; i += 4) {
+   /* Handling 4 RSS entries per loop */
+   idx = i / RTE_RETA_GROUP_SIZE;
+   shift = i % RTE_RETA_GROUP_SIZE;
+   mask = (uint8_t)((reta_conf[idx].mask >> shift) & 0xF);
+
+   if (!mask)
+   continue;
+
+   reta = nn_cfg_readl(hw, NFP_NET_CFG_RSS_ITBL + shift);
+   for (j = 0; j < 4; j++) {
+   if (!(mask & (0x1 << j)))
+   continue;
+   reta_conf->reta[shift + j] =
+   (uint8_t)((reta >> (8 * j)) & 0xF);
+   }
+   }
+   return 0;
+}
+
+static int
+nfp_net_rss_hash_update(struct rte_eth_dev *dev,
+   struct rte_eth_rss_conf *rss_conf)
+{
+   uint32_t update;
+   uint32_t cfg_rss_ctrl = 0;
+   uint8_t key;
+   uint64_t rss_hf;
+   int i;
+   struct nfp_net_hw *hw;
+
+   hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   rss_hf = rss_conf->rss_hf;
+
+   /* Checking if RSS is enabled */
+   if (!(hw->ctrl & NFP_NET_CFG_CTRL_RSS)) {
+   if (rss_hf != 0) { /* Enable RSS? */
+   RTE_LOG(ERR, PMD, "RSS unsupported\n");
+   return -EINVAL;
+   }
+   return 0; /* Nothing to do */
+   }

[dpdk-dev] [PATCH v5 2/9] nfp: rx/tx functionality

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 drivers/net/nfp/nfp_net.c |  921 +
 1 file changed, 921 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index a33ed37..8339c2d 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -212,6 +212,100 @@ nn_cfg_writeq(struct nfp_net_hw *hw, int off, uint64_t 
val)
nn_writeq(rte_cpu_to_le_64(val), hw->ctrl_bar + off);
 }

+/* Creating memzone for hardware rings. */
+static const struct rte_memzone *
+ring_dma_zone_reserve(struct rte_eth_dev *dev, const char *ring_name,
+ uint16_t queue_id, uint32_t ring_size, int socket_id)
+{
+   char z_name[RTE_MEMZONE_NAMESIZE];
+   const struct rte_memzone *mz;
+
+   snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
+dev->driver->pci_drv.name,
+ring_name, dev->data->port_id, queue_id);
+
+   mz = rte_memzone_lookup(z_name);
+   if (mz)
+   return mz;
+
+   return rte_memzone_reserve_aligned(z_name, ring_size, socket_id, 0,
+  NFP_MEMZONE_ALIGN);
+}
+
+static void
+nfp_net_rx_queue_release_mbufs(struct nfp_net_rxq *rxq)
+{
+   unsigned i;
+
+   if (rxq->rxbufs == NULL)
+   return;
+
+   for (i = 0; i < rxq->rx_count; i++) {
+   if (rxq->rxbufs[i].mbuf) {
+   rte_pktmbuf_free_seg(rxq->rxbufs[i].mbuf);
+   rxq->rxbufs[i].mbuf = NULL;
+   }
+   }
+}
+
+static void
+nfp_net_rx_queue_release(void *rx_queue)
+{
+   struct nfp_net_rxq *rxq = rx_queue;
+
+   if (rxq) {
+   nfp_net_rx_queue_release_mbufs(rxq);
+   rte_free(rxq->rxbufs);
+   rte_free(rxq);
+   }
+}
+
+static void
+nfp_net_reset_rx_queue(struct nfp_net_rxq *rxq)
+{
+   nfp_net_rx_queue_release_mbufs(rxq);
+   rxq->wr_p = 0;
+   rxq->rd_p = 0;
+   rxq->nb_rx_hold = 0;
+}
+
+static void
+nfp_net_tx_queue_release_mbufs(struct nfp_net_txq *txq)
+{
+   unsigned i;
+
+   if (txq->txbufs == NULL)
+   return;
+
+   for (i = 0; i < txq->tx_count; i++) {
+   if (txq->txbufs[i].mbuf) {
+   rte_pktmbuf_free_seg(txq->txbufs[i].mbuf);
+   txq->txbufs[i].mbuf = NULL;
+   }
+   }
+}
+
+static void
+nfp_net_tx_queue_release(void *tx_queue)
+{
+   struct nfp_net_txq *txq = tx_queue;
+
+   if (txq) {
+   nfp_net_tx_queue_release_mbufs(txq);
+   rte_free(txq->txbufs);
+   rte_free(txq);
+   }
+}
+
+static void
+nfp_net_reset_tx_queue(struct nfp_net_txq *txq)
+{
+   nfp_net_tx_queue_release_mbufs(txq);
+   txq->wr_p = 0;
+   txq->rd_p = 0;
+   txq->tail = 0;
+}
+
 static int
 __nfp_net_reconfig(struct nfp_net_hw *hw, uint32_t update)
 {
@@ -449,6 +543,18 @@ nfp_net_disable_queues(struct rte_eth_dev *dev)
hw->ctrl = new_ctrl;
 }

+static int
+nfp_net_rx_freelist_setup(struct rte_eth_dev *dev)
+{
+   int i;
+
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   if (nfp_net_rx_fill_freelist(dev->data->rx_queues[i]) < 0)
+   return -1;
+   }
+   return 0;
+}
+
 static void
 nfp_net_params_setup(struct nfp_net_hw *hw)
 {
@@ -582,6 +688,821 @@ nfp_net_close(struct rte_eth_dev *dev)
 */
 }

+static uint32_t
+nfp_net_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx)
+{
+   struct nfp_net_rxq *rxq;
+   struct nfp_net_rx_desc *rxds;
+   uint32_t idx;
+   uint32_t count;
+
+   rxq = (struct nfp_net_rxq *)dev->data->rx_queues[queue_idx];
+
+   if (rxq == NULL) {
+   PMD_INIT_LOG(ERR, "Bad queue: %u\n", queue_idx);
+   return 0;
+   }
+
+   idx = rxq->rd_p % rxq->rx_count;
+   rxds = >rxds[idx];
+
+   count = 0;
+
+   /*
+* Other PMDs are just checking the DD bit in intervals of 4
+* descriptors and counting all four if the first has the DD
+* bit on. Of course, this is not accurate but can be good for
+* perfomance. But ideally that should be done in descriptors
+* chunks belonging to the same cache line
+*/
+
+   while (count < rxq->rx_count) {
+   rxds = >rxds[idx];
+   if ((rxds->rxd.meta_len_dd & PCIE_DESC_RX_DD) == 0)
+   break;
+
+   count++;
+   idx++;
+
+   /* Wrapping? */
+   if ((idx) == rxq->rx_count)
+   idx = 0;
+   }
+
+   return count;
+}
+
+static int
+nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
+  uint16_t queue_idx, uint16_t nb_desc,
+  unsigned int socket_id,
+  const struct rte_eth_rxconf 

[dpdk-dev] [PATCH v5 1/9] nfp: basic initialization for netronome´s nfp-6xxx card

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

Signed-off-by: Alejandro.Lucero 
Signed-off-by: Rolf.Neugebauer 
---
 drivers/net/nfp/Makefile   |   88 +
 drivers/net/nfp/nfp_net.c  |  785 
 drivers/net/nfp/nfp_net_ctrl.h |  290 +++
 drivers/net/nfp/nfp_net_logs.h |   75 
 drivers/net/nfp/nfp_net_pmd.h  |  434 ++
 5 files changed, 1672 insertions(+)
 create mode 100644 drivers/net/nfp/Makefile
 create mode 100644 drivers/net/nfp/nfp_net.c
 create mode 100644 drivers/net/nfp/nfp_net_ctrl.h
 create mode 100644 drivers/net/nfp/nfp_net_logs.h
 create mode 100644 drivers/net/nfp/nfp_net_pmd.h

diff --git a/drivers/net/nfp/Makefile b/drivers/net/nfp/Makefile
new file mode 100644
index 000..ef74e27
--- /dev/null
+++ b/drivers/net/nfp/Makefile
@@ -0,0 +1,88 @@
+#   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.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_nfp.a
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+#
+# Add extra flags for base driver files (also known as shared code)
+# to disable warnings
+#
+ifeq ($(CC), icc)
+CFLAGS_BASE_DRIVER = -wd593
+else ifeq ($(CC), clang)
+CFLAGS_BASE_DRIVER += -Wno-sign-compare
+CFLAGS_BASE_DRIVER += -Wno-unused-value
+CFLAGS_BASE_DRIVER += -Wno-unused-parameter
+CFLAGS_BASE_DRIVER += -Wno-strict-aliasing
+CFLAGS_BASE_DRIVER += -Wno-format
+CFLAGS_BASE_DRIVER += -Wno-missing-field-initializers
+CFLAGS_BASE_DRIVER += -Wno-pointer-to-int-cast
+CFLAGS_BASE_DRIVER += -Wno-format-nonliteral
+else
+CFLAGS_BASE_DRIVER  = -Wno-sign-compare
+CFLAGS_BASE_DRIVER += -Wno-unused-value
+CFLAGS_BASE_DRIVER += -Wno-unused-parameter
+CFLAGS_BASE_DRIVER += -Wno-strict-aliasing
+CFLAGS_BASE_DRIVER += -Wno-format
+CFLAGS_BASE_DRIVER += -Wno-missing-field-initializers
+CFLAGS_BASE_DRIVER += -Wno-pointer-to-int-cast
+CFLAGS_BASE_DRIVER += -Wno-format-nonliteral
+CFLAGS_BASE_DRIVER += -Wno-format-security
+
+ifeq ($(shell test $(GCC_VERSION) -ge 44 && echo 1), 1)
+CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
+endif
+
+endif
+OBJS_BASE_DRIVER=$(patsubst %.c,%.o,$(notdir $(wildcard 
$(RTE_SDK)/lib/librte_pmd_nfp/*.c)))
+$(foreach obj, $(OBJS_BASE_DRIVER), $(eval 
CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER)))
+
+VPATH += $(RTE_SDK)/drivers/net/nfp/
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += nfp_net.c
+
+# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += lib/librte_eal lib/librte_ether
+DEPDIRS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += lib/librte_mempool lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += lib/librte_net lib/librte_malloc
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
new file mode 100644
index 000..a33ed37
--- /dev/null
+++ b/drivers/net/nfp/nfp_net.c
@@ -0,0 +1,785 @@
+/*
+ * Copyright (c) 2014, 2015 Netronome Systems, Inc.
+ * All rights reserved.
+ *
+ * Small portions derived from code Copyright(c) 2010-2015 Intel Corporation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ *  this list of conditions and the following disclaimer.
+ *
+ * 2. 

[dpdk-dev] [PATCH v5 0/9] support for netronome nfp-6xxx card

[Alejandro.Lucero]

From: "Alejandro.Lucero" 

This patchset adds a new PMD for Netronome nfp-6xxx cards.
Just PCI Virtual Functions supported.

v5:
 - Submitting code piece by piece as requested

v4:
 - Just submitting PMD

v3:
 - Making all patches independent for applying and building
 - changing commits messages following standard

v2:
 - Code style changes based on checkpatch.pl and DPDK style guide
 - Documentation changes using the right rst format
 - Moving the documentation files to a new patch file
 - Adding info to MAINTAINERS and release files

Alejandro.Lucero (9):
  nfp: basic initialization for netronome?s nfp-6xxx card
  nfp: rx/tx functionality
  nfp: adding rss functionality
  nfp: adding stats functionality
  nfp: adding link functionality
  nfp: adding functionality to pmd
  nfp: integration with dpdk build system
  nfp: adding nic guide
  nfp: adding maintainers and release info

 MAINTAINERS  |5 +
 config/common_linuxapp   |6 +
 doc/guides/nics/index.rst|1 +
 doc/guides/nics/nfp.rst  |  189 +++
 doc/guides/rel_notes/release_2_2.rst |4 +
 drivers/net/Makefile |1 +
 drivers/net/nfp/Makefile |   88 ++
 drivers/net/nfp/nfp_net.c| 2366 ++
 drivers/net/nfp/nfp_net_ctrl.h   |  290 +
 drivers/net/nfp/nfp_net_logs.h   |   75 ++
 drivers/net/nfp/nfp_net_pmd.h|  434 +++
 mk/rte.app.mk|1 +
 12 files changed, 3460 insertions(+)
 create mode 100644 doc/guides/nics/nfp.rst
 create mode 100644 drivers/net/nfp/Makefile
 create mode 100644 drivers/net/nfp/nfp_net.c
 create mode 100644 drivers/net/nfp/nfp_net_ctrl.h
 create mode 100644 drivers/net/nfp/nfp_net_logs.h
 create mode 100644 drivers/net/nfp/nfp_net_pmd.h

-- 
1.7.9.5

[dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine

[Panu Matilainen]

On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> 2015-10-19 08:36, Eric Kinzie:
>>Size of struct rte_eth_bond_8023ad_conf changed.  Increment LIBABIVER
>>and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
>>functions.
> [...]
>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> [...]
>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, 
>> struct rte_eth_bond_8023ad_conf *conf), \
>> +  bond_mode_8023ad_setup_v22);
>
> I'm sorry it doesn't work well when trying to build a combined lib:
>
> ld: libdpdk.so: version node not found for symbol 
> bond_mode_8023ad_setup@@DPDK_2.2
>
> The symbols are OK in the .o file:
> 2340 g F .text  0171 
> bond_mode_8023ad_setup@@DPDK_2.2
> 2260 g F .text  00da bond_mode_8023ad_setup at 
> DPDK_2.0
> 2260 g F .text  00da bond_mode_8023ad_setup_v20
> 2340 g F .text  0171 bond_mode_8023ad_setup_v22
>  *UND*   bond_mode_8023ad_setup
>
> I don't understand the problem and I am considering disabling versioning in
> combined library.
>
> Any idea?
>

The .map additions look incorrect to me:

> diff --git a/drivers/net/bonding/rte_eth_bond_version.map 
> b/drivers/net/bonding/rte_eth_bond_version.map
> index 22bd920..7f78717 100644
> --- a/drivers/net/bonding/rte_eth_bond_version.map
> +++ b/drivers/net/bonding/rte_eth_bond_version.map
> @@ -17,6 +17,9 @@  DPDK_2.0 {
>   rte_eth_bond_slaves_get;
>   rte_eth_bond_xmit_policy_get;
>   rte_eth_bond_xmit_policy_set;
> + rte_eth_bond_8023ad_ext_collect;
> + rte_eth_bond_8023ad_ext_distrib;
> + rte_eth_bond_8023ad_ext_slowtx;

These symbols didn't exist in DPDK 2.0 but are only being added here. So 
why are they being added to the 2.0 section?

>
>   local: *;
>  };
> @@ -27,3 +30,10 @@  DPDK_2.1 {
>   rte_eth_bond_free;
>
>  } DPDK_2.0;
> +
> +DPDK_2.2 {
> + local
> +
> + bond_mode_8023ad_conf_get;
> + bond_mode_8023ad_setup;
> +} DPDK_2.1;

These are marked local, as in, "not exported" which doesn't seem right. 
Also they're lacking the rte_eth_ prefix. AFAICS this is what the symbol 
export map should look like here:

DPDK_2.2 {
 global:

 rte_eth_bond_8023ad_ext_collect;
 rte_eth_bond_8023ad_ext_distrib;
 rte_eth_bond_8023ad_ext_slowtx;
 rte_eth_bond_mode_8023ad_conf_get;
 rte_eth_bond_mode_8023ad_setup;
} DPDK_2.1;

That said, problems with symbol versioning and the combined library were 
predicted from the start, once the individual library versions start 
advancing. For one, the combined library itself is not versioned at all 
it is offending the ABI policy all the time.

Replacing the library with a linker script, as suggested before by Neil 
Horman and Sergio Gonzales Monroy would eliminate these problems.

- Panu -

[dpdk-dev] [PATCH v3 1/6] eal/arm: add 64-bit armv8 version of rte_memcpy.h

[Hunt, David]

On 02/11/2015 04:57, Jerin Jacob wrote:
> On Fri, Oct 30, 2015 at 01:49:14PM +, David Hunt wrote:
>> Signed-off-by: David Hunt 
--snip--
>> +#ifndef _RTE_MEMCPY_ARM_64_H_
>> +#define _RTE_MEMCPY_ARM_64_H_
>> +
>> +#include 
>> +#include 
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +#include "generic/rte_memcpy.h"
>> +
>> +#ifdef __ARM_NEON_FP
>
> SIMD is not optional in armv8 spec.So every armv8 machine will have
> SIMD instruction unlike armv7.More over LDP/STP instruction is
> not part of SIMD.So this check is not required or it can
> be replaced with a check that select memcpy from either libc or this specific
> implementation

Jerin,
I've just benchmarked the libc version against the hand-coded 
version of the memcpy routines, and the libc wins in most cases. This 
code was just an initial attempt at optimising the memccpy's, so I feel 
that with the current benchmark results, it would better just to remove 
the assembly versions, and use the libc version for the initial release 
on ARMv8.
Then, in the future, the ARMv8 experts are free to submit an optimised 
version as a patch in the future. Does that sound reasonable to you?
Rgds,
Dave.


--snip--

[dpdk-dev] [PATCH 0/3] Add VHOST PMD

[Tetsuya Mukawa]

On 2015/10/31 3:30, Thomas Monjalon wrote:
> 2015-10-27 16:54, Tetsuya Mukawa:
>> Below patch has been submitted as a separate patch.
>>
>> -  [dpdk-dev,1/3] vhost: Fix wrong handling of virtqueue array index
>> (http://dpdk.org/dev/patchwork/patch/8038/)
> Please could you rebase only the two last patches?
> Thanks
>
> PS:
> WARNING:TYPO_SPELLING: 'failuer' may be misspelled - perhaps 'failure'?
> #606: FILE: drivers/net/vhost/rte_eth_vhost.c:272:
> +   RTE_LOG(INFO, PMD, "failuer to find a ethdev\n");
> WARNING:TYPO_SPELLING: 'accesing' may be misspelled - perhaps 'accessing'?
> #612: FILE: drivers/net/vhost/rte_eth_vhost.c:278:
> +   /* Wait until rx/tx_pkt_burst stops accesing vhost device */
>

Hi Thomas,

Thank you so much for checking my patches.
I have fixed a few typos, and rebased on latest tree (with Bernard's patch).
I will submit again soon.

Regards,
Tetsuya

[dpdk-dev] [PATCH 2/3] vhost: Add callback and private data for vhost PMD

[Tetsuya Mukawa]

On 2015/10/31 2:49, Loftus, Ciara wrote:
>> These variables are needed to be able to manage one of virtio devices
>> using both vhost library APIs and vhost PMD.
>> For example, if vhost PMD uses current callback handler and private data
>> provided by vhost library, A DPDK application that links vhost library
>> cannot use some of vhost library APIs. To avoid it, callback and private
>> data for vhost PMD are needed.
>>
>> Signed-off-by: Tetsuya Mukawa 
>> ---
>>  lib/librte_vhost/rte_vhost_version.map|  6 +++
>>  lib/librte_vhost/rte_virtio_net.h |  3 ++
>>  lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +++
>>  lib/librte_vhost/virtio-net.c | 56 
>> +--
>>  lib/librte_vhost/virtio-net.h |  4 +-
>>  5 files changed, 70 insertions(+), 12 deletions(-)
>>
> Hi Tetsuya,
>
> Thanks for implementing this. I haven't had a chance to actually test it, but 
> if these changes allow users of the PMD to implement their own new_ and 
> destroy_ device functions etc, that's good news.
>
> Thanks,
> Ciara

Hi Ciara,

Yes, the patch works like you said.

Thanks,
Tetsuya

[dpdk-dev] [PATCH v2 0/3] Add link status notification support to Mellanox PMDs

[Adrien Mazarguil]

On Sun, Nov 01, 2015 at 11:32:06AM +0100, Thomas Monjalon wrote:
> 2015-10-30 19:57, Adrien Mazarguil:
> > Mellanox PMDs (mlx4 and mlx5) support link status notification with
> > libibverbs through a file descriptor, in a manner reminiscent of UIO/VFIO.
> > 
> > It still requires a new "external" interrupt handler type since contrary
> > to other types, this file descriptor must not be processed by EAL.
> > 
> > Changes in v2:
> > - Only changes caused by rebase on v2 of previous patchsets
> >   ("Mellanox ConnectX-4 PMD (mlx5)" and
> >   "Enhance mlx5 with Mellanox OFED 3.1")
> > 
> > Nelio Laranjeiro (3):
> >   eal: new interrupt handler type
> >   mlx4: handle interrupts
> >   mlx5: handle interrupts
> 
> Applied with previous ack from David on v1 and suggested title change.
> Please take care of addressing comments yourself.
> Thanks

Thanks, sorry for the omission, I was a bit in a hurry. I fully agree with
the title change.

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v3 6/6] test: add checks for cpu flags on armv8

[Jerin Jacob]

On Fri, Oct 30, 2015 at 04:28:25PM +, Hunt, David wrote:
> On 30/10/2015 16:11, Jan Viktorin wrote:
> >Hmm, I see. It's good to fix this in the generated e-mails between 
> >format-patch
> > and send-email calls. I always review those to be sure they meet my
> expectations ;).
> >Anyway, it is not clear, what has changed in the v3. Just the rte_cycles?
> >You should explain that at least in the  patch. Better to keep some 
> >history
> >in each single commit (are there any rules in dpdk for this? Just look how 
> >they do in kernel).
> --snip--
> 
> Sure, I'll keep that in mind for the next time. A list of changes for each
> revision, and also changes in each patch in the patch set. As Thomas says -
> whatever helps the reviewer :)
> 
> For the moment there probably isn't a need to release a new patch set for
> these comments, so I'll just list them here:
> 1. v3 has just the additional comment in one of the patches to say that the
> armv8 header files are in the 'arm' include directory.
> 2. The rte_cycles is unchanged, the CONFIG_ is not needed.
> 
> If there is a need to post another patch set I'll include the change notes.
> Otherwise do we all think that the patch is there (or there abouts)? :)

Hi Jan and Dave,

I have reviewed your patches for arm[64] support. Please check the
review comments.

Cavium would like to contribute on armv8 port and remaining libraries
(ACL, LPM, HASH) implementation for armv8. Currently i am re-basing
our ACL,HASH libraries implementation based on existing patches.
Happy to work with you guys to have full fledged armv8 support for DPDK.

Jerin


other query on rte_cpu_get_flag_enabled for armv8,
I have tried to run the existing patches on armv8-thunderX platform.
But there application start failure due to mismatch in
rte_cpu_get_flag_enabled() encoding.

In my platform rte_cpu_get_flag_enabled() works based on
AT_HWCAP with following values[1] which different from
existing lib/librte_eal/common/include/arch/arm/rte_cpuflags.h

[1]http://lxr.free-electrons.com/source/arch/arm64/include/uapi/asm/hwcap.h

In order to debug this, Could provide the following 
values in tested armv8 platform. Look like its running 32bit compatible 
mode in your environment


root at arm64:/export/dpdk-arm64# LD_SHOW_AUXV=1 sleep 1000
AT_SYSINFO_EHDR: 0x3ff859f
AT_??? (0x26): 0x430f0a10
AT_HWCAP:fb
AT_PAGESZ:   65536
AT_CLKTCK:   100
AT_PHDR: 0x400040
AT_PHENT:56
AT_PHNUM:7
AT_BASE: 0x3ff85a0
AT_FLAGS:0x0
AT_ENTRY:0x401900
AT_UID:  0
AT_EUID: 0
AT_GID:  0
AT_EGID: 0
AT_SECURE:   0
AT_RANDOM:   0x3ffef1c7988
AT_EXECFN:   /bin/sleep
AT_PLATFORM: aarch64

root at arm64:/export/dpdk-arm64# zcat /proc/config.gz  | grep CONFIG_COMPAT
# CONFIG_COMPAT_BRK is not set
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_COMPAT=y
CONFIG_COMPAT_NETLINK_MESSAGES=y


root at arm64:/export/dpdk-arm64# cat /proc/cpuinfo
Processor   : AArch64 Processor rev 0 (aarch64)
processor   : 0
processor   : 1
processor   : 2
processor   : 3
processor   : 4
processor   : 5
processor   : 6
processor   : 7
processor   : 8
processor   : 9
processor   : 10
processor   : 11
processor   : 12
processor   : 13
processor   : 14
processor   : 15
processor   : 16
processor   : 17
processor   : 18
processor   : 19
processor   : 20
processor   : 21
processor   : 22
processor   : 23
processor   : 24
processor   : 25
processor   : 26
processor   : 27
processor   : 28
processor   : 29
processor   : 30
processor   : 31
processor   : 32
processor   : 33
processor   : 34
processor   : 35
processor   : 36
processor   : 37
processor   : 38
processor   : 39
processor   : 40
processor   : 41
processor   : 42
processor   : 43
processor   : 44
processor   : 45
processor   : 46
processor   : 47
Features: fp asimd aes pmull sha1 sha2 crc32
CPU implementer : 0x43
CPU architecture: AArch64
CPU variant : 0x0
CPU part: 0x0a1
CPU revision: 0




> 
> Regards,
> Dave.
> 

[dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine

[Eric Kinzie]

On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> >2015-10-19 08:36, Eric Kinzie:
> >>   Size of struct rte_eth_bond_8023ad_conf changed.  Increment LIBABIVER
> >>   and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
> >>   functions.
> >[...]
> >>+VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> >[...]
> >>+BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>+MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, 
> >>struct rte_eth_bond_8023ad_conf *conf), \
> >>+ bond_mode_8023ad_setup_v22);
> >
> >I'm sorry it doesn't work well when trying to build a combined lib:
> >
> >ld: libdpdk.so: version node not found for symbol 
> >bond_mode_8023ad_setup@@DPDK_2.2
> >
> >The symbols are OK in the .o file:
> >2340 g F .text  0171 
> >bond_mode_8023ad_setup@@DPDK_2.2
> >2260 g F .text  00da bond_mode_8023ad_setup at 
> >DPDK_2.0
> >2260 g F .text  00da bond_mode_8023ad_setup_v20
> >2340 g F .text  0171 bond_mode_8023ad_setup_v22
> > *UND*   bond_mode_8023ad_setup
> >
> >I don't understand the problem and I am considering disabling versioning in
> >combined library.
> >
> >Any idea?
> >
> 
> The .map additions look incorrect to me:
> 
> >diff --git a/drivers/net/bonding/rte_eth_bond_version.map 
> >b/drivers/net/bonding/rte_eth_bond_version.map
> >index 22bd920..7f78717 100644
> >--- a/drivers/net/bonding/rte_eth_bond_version.map
> >+++ b/drivers/net/bonding/rte_eth_bond_version.map
> >@@ -17,6 +17,9 @@  DPDK_2.0 {
> > rte_eth_bond_slaves_get;
> > rte_eth_bond_xmit_policy_get;
> > rte_eth_bond_xmit_policy_set;
> >+rte_eth_bond_8023ad_ext_collect;
> >+rte_eth_bond_8023ad_ext_distrib;
> >+rte_eth_bond_8023ad_ext_slowtx;
> 
> These symbols didn't exist in DPDK 2.0 but are only being added
> here. So why are they being added to the 2.0 section?

Yes, I think these should probably be moved.


> >
> > local: *;
> > };
> >@@ -27,3 +30,10 @@  DPDK_2.1 {
> > rte_eth_bond_free;
> >
> > } DPDK_2.0;
> >+
> >+DPDK_2.2 {
> >+local
> >+
> >+bond_mode_8023ad_conf_get;
> >+bond_mode_8023ad_setup;
> >+} DPDK_2.1;
> 
> These are marked local, as in, "not exported" which doesn't seem
> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
> the symbol export map should look like here:


These were not exported to begin with.  But after versioning these
functions, they are exported unless explicitly declared to be local here.


> DPDK_2.2 {
> global:
> 
> rte_eth_bond_8023ad_ext_collect;
> rte_eth_bond_8023ad_ext_distrib;
> rte_eth_bond_8023ad_ext_slowtx;
> rte_eth_bond_mode_8023ad_conf_get;
> rte_eth_bond_mode_8023ad_setup;
> } DPDK_2.1;
> 
> That said, problems with symbol versioning and the combined library
> were predicted from the start, once the individual library versions
> start advancing. For one, the combined library itself is not
> versioned at all it is offending the ABI policy all the time.
> 
> Replacing the library with a linker script, as suggested before by
> Neil Horman and Sergio Gonzales Monroy would eliminate these
> problems.
> 
>   - Panu -
> 
> 

[dpdk-dev] [PATCH v5 01/15] eal/arm: atomic operations for ARM

[Jerin Jacob]

On Fri, Oct 30, 2015 at 01:25:28AM +0100, Jan Viktorin wrote:
> From: Vlastimil Kosar 
>
> This patch adds architecture specific atomic operation file
> for ARM architecture. It utilizes compiler intrinsics only.
>
> Signed-off-by: Vlastimil Kosar 
> Signed-off-by: Jan Viktorin 
> ---
> v1 -> v2:
> * improve rte_wmb()
> * use __atomic_* or __sync_*? (may affect the required GCC version)
>
> v4:
> * checkpatch complaints about volatile keyword (but seems to be OK to me)
> * checkpatch complaints about do { ... } while (0) for single statement
>   with asm volatile (but I didn't find a way how to write it without
>   the checkpatch complaints)
> * checkpatch is now happy with whitespaces
> ---
>  .../common/include/arch/arm/rte_atomic.h   | 256 
> +
>  1 file changed, 256 insertions(+)
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_atomic.h
>
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic.h 
> b/lib/librte_eal/common/include/arch/arm/rte_atomic.h
> new file mode 100644
> index 000..ea1e485
> --- /dev/null
> +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic.h
> @@ -0,0 +1,256 @@
> +/*-
> + *   BSD LICENSE
> + *
> + *   Copyright(c) 2015 RehiveTech. 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 RehiveTech 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.
> + */
> +
> +#ifndef _RTE_ATOMIC_ARM_H_
> +#define _RTE_ATOMIC_ARM_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include "generic/rte_atomic.h"
> +
> +/**
> + * General memory barrier.
> + *
> + * Guarantees that the LOAD and STORE operations generated before the
> + * barrier occur before the LOAD and STORE operations generated after.
> + */
> +#define  rte_mb()  __sync_synchronize()
> +
> +/**
> + * Write memory barrier.
> + *
> + * Guarantees that the STORE operations generated before the barrier
> + * occur before the STORE operations generated after.
> + */
> +#define  rte_wmb() do { asm volatile ("dmb st" : : : "memory"); } while 
> (0)
> +
> +/**
> + * Read memory barrier.
> + *
> + * Guarantees that the LOAD operations generated before the barrier
> + * occur before the LOAD operations generated after.
> + */
> +#define  rte_rmb() __sync_synchronize()
> +

#define dmb(opt)asm volatile("dmb " #opt : : : "memory")

static inline void rte_mb(void)
{
dmb(ish);
}

static inline void rte_wmb(void)
{
dmb(ishst);
}

static inline void rte_rmb(void)
{
dmb(ishld);
}

For armv8, it make sense to have above definition for rte_*mb(). If does
n't make sense for armv7 then we need split this file rte_atomic_32/64.h



> +/*- 16 bit atomic operations 
> -*/
> +
> +#ifndef RTE_FORCE_INTRINSICS
> +static inline int
> +rte_atomic16_cmpset(volatile uint16_t *dst, uint16_t exp, uint16_t src)
> +{
> + return __atomic_compare_exchange(dst, , , 0, __ATOMIC_ACQUIRE,
> + __ATOMIC_ACQUIRE) ? 1 : 0;
> +}

IMO, it should be __ATOMIC_SEQ_CST be instead of __ATOMIC_ACQUIRE.
__ATOMIC_ACQUIRE works in conjunction with __ATOMIC_RELEASE.
AFAIK, DPDK atomic api expects full barrier. C11 memory model not yet
used. So why can't we use RTE_FORCE_INTRINSICS based generic
implementation. Same holds true for spinlock implementation too(i.e using
RTE_FORCE_INTRINSICS). Am I missing something here ?



> +
> +static inline int rte_atomic16_test_and_set(rte_atomic16_t *v)
> 

[dpdk-dev] [PATCH] ixgbe: remove mac fault counts from rx errors

[Harry van Haaren]

This patch removes the mac local fault count and
mac remote fault count from rx errors. The mac
fault count registers count faults, not packets,
and hence should not be added to packet counters.

Signed-off-by: Harry van Haaren 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4373661..395fa7a 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2214,8 +2214,6 @@ ixgbe_dev_stats_get(struct rte_eth_dev *dev, struct 
rte_eth_stats *stats)
  hw_stats->illerrc +
  hw_stats->errbc +
  hw_stats->xec +
- hw_stats->mlfc +
- hw_stats->mrfc +
  hw_stats->rfc +
  hw_stats->fccrc +
  hw_stats->fclast;
-- 
1.9.1

[dpdk-dev] [PATCH v3 6/6] test: add checks for cpu flags on armv8

[Hunt, David]

On 02/11/2015 06:32, Jerin Jacob wrote:
> On Fri, Oct 30, 2015 at 04:28:25PM +, Hunt, David wrote:

--snip--

>
> Hi Jan and Dave,
>
> I have reviewed your patches for arm[64] support. Please check the
> review comments.

Hi Jerin,

I'm looking at the comments now, and working on getting the suggested 
changes merged into the patch-set.

> Cavium would like to contribute on armv8 port and remaining libraries
> (ACL, LPM, HASH) implementation for armv8. Currently i am re-basing
> our ACL,HASH libraries implementation based on existing patches.
> Happy to work with you guys to have full fledged armv8 support for DPDK.
>
> Jerin

Thanks for that, it's good news indeed.

> other query on rte_cpu_get_flag_enabled for armv8,
> I have tried to run the existing patches on armv8-thunderX platform.
> But there application start failure due to mismatch in
> rte_cpu_get_flag_enabled() encoding.
>
> In my platform rte_cpu_get_flag_enabled() works based on
> AT_HWCAP with following values[1] which different from
> existing lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
>
> [1]http://lxr.free-electrons.com/source/arch/arm64/include/uapi/asm/hwcap.h
>
> In order to debug this, Could provide the following
> values in tested armv8 platform. Look like its running 32bit compatible
> mode in your environment

I'm using a Gigabyte MP30AR0 motherboard with an 8-core X-Gene, Running 
a 4.3.0-rc6 kernel.
Here's the information on the cpu_flags issue you requested:

> AT_SYSINFO_EHDR: 0x3ff859f
> AT_??? (0x26): 0x430f0a10
> AT_HWCAP:fb
> AT_PAGESZ:   65536
> AT_CLKTCK:   100
> AT_PHDR: 0x400040
> AT_PHENT:56
> AT_PHNUM:7
> AT_BASE: 0x3ff85a0
> AT_FLAGS:0x0
> AT_ENTRY:0x401900
> AT_UID:  0
> AT_EUID: 0
> AT_GID:  0
> AT_EGID: 0
> AT_SECURE:   0
> AT_RANDOM:   0x3ffef1c7988
> AT_EXECFN:   /bin/sleep
> AT_PLATFORM: aarch64

root at mp30ar0:~# LD_SHOW_AUXV=1 sleep 1000
AT_SYSINFO_EHDR: 0x7f7956d000
AT_HWCAP:7
AT_PAGESZ:   4096
AT_CLKTCK:   100
AT_PHDR: 0x400040
AT_PHENT:56
AT_PHNUM:7
AT_BASE: 0x7f79543000
AT_FLAGS:0x0
AT_ENTRY:0x401900
AT_UID:  0
AT_EUID: 0
AT_GID:  0
AT_EGID: 0
AT_SECURE:   0
AT_RANDOM:   0x7ffcaf2e48
AT_EXECFN:   /bin/sleep
AT_PLATFORM: aarch64

> root at arm64:/export/dpdk-arm64# zcat /proc/config.gz  | grep CONFIG_COMPAT
> # CONFIG_COMPAT_BRK is not set
> CONFIG_COMPAT_BINFMT_ELF=y
> CONFIG_COMPAT=y
> CONFIG_COMPAT_NETLINK_MESSAGES=y

root at mp30ar0:~# zcat /proc/config.gz  | grep CONFIG_COMPAT
# CONFIG_COMPAT_BRK is not set
CONFIG_COMPAT_OLD_SIGACTION=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_COMPAT=y


> root at arm64:/export/dpdk-arm64# cat /proc/cpuinfo
> Processor   : AArch64 Processor rev 0 (aarch64)
> processor   : 0
> processor   : 1
--snip--
> processor   : 46
> processor   : 47
> Features: fp asimd aes pmull sha1 sha2 crc32
> CPU implementer : 0x43
> CPU architecture: AArch64
> CPU variant : 0x0
> CPU part: 0x0a1
> CPU revision: 0

root at mp30ar0:~# cat /proc/cpuinfo
processor   : 0
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

processor   : 1
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

processor   : 2
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

processor   : 3
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

processor   : 4
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

processor   : 5
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

processor   : 6
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

processor   : 7
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

root at mp30ar0:~#

Hope this helps.

Regards,
Dave.

[dpdk-dev] [PATCH v3 3/6] eal/arm: add 64-bit armv8 version of rte_cycles.h

[Jerin Jacob]

On Fri, Oct 30, 2015 at 01:49:16PM +, David Hunt wrote:
> Signed-off-by: David Hunt 
> ---
>  .../common/include/arch/arm/rte_cycles.h   |  4 ++
>  .../common/include/arch/arm/rte_cycles_64.h| 77 
> ++
>  2 files changed, 81 insertions(+)
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cycles_64.h
> 
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles.h 
> b/lib/librte_eal/common/include/arch/arm/rte_cycles.h
> index b2372fa..a8009a0 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_cycles.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_cycles.h
> @@ -33,6 +33,10 @@
>  #ifndef _RTE_CYCLES_ARM_H_
>  #define _RTE_CYCLES_ARM_H_
>  
> +#ifdef RTE_ARCH_64
> +#include 
> +#else
>  #include 
> +#endif
>  
>  #endif /* _RTE_CYCLES_ARM_H_ */
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles_64.h 
> b/lib/librte_eal/common/include/arch/arm/rte_cycles_64.h
> new file mode 100644
> index 000..148b9f4
> --- /dev/null
> +++ b/lib/librte_eal/common/include/arch/arm/rte_cycles_64.h
> @@ -0,0 +1,77 @@
> +/*
> + *   BSD LICENSE
> + *
> + *   Copyright (C) IBM Corporation 2014.
> + *
> + *   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 IBM 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.
> +*/
> +
> +#ifndef _RTE_CYCLES_ARM64_H_
> +#define _RTE_CYCLES_ARM64_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include "generic/rte_cycles.h"
> +
> +/**
> + * Read the time base register.
> + *
> + * @return
> + *   The time base for this lcore.
> + */
> +static inline uint64_t
> +rte_rdtsc(void)
> +{
> + uint64_t tsc;
> +
> + asm volatile("mrs %0, CNTVCT_EL0" : "=r" (tsc));
> +
> +#ifdef RTE_TIMER_MULTIPLIER
> + return tsc * RTE_TIMER_MULTIPLIER;
> +#else
> + return tsc;
> +#endif
> +
> +}
> +
> +static inline uint64_t
> +rte_rdtsc_precise(void)
> +{
> + asm volatile("isb sy" :::);

IMO, it should be asm volatile("dmb ish" : : : "memory")
to represent the data memory barrier(rte_mb()).

> + return rte_rdtsc();
> +}
> +
> +static inline uint64_t
> +rte_get_tsc_cycles(void) { return rte_rdtsc(); }
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_CYCLES_ARM64_H_ */
> -- 
> 1.9.1
> 

[dpdk-dev] [PATCH v2 09/13] mlx5: add link update device operation

[Stephen Hemminger]

On Mon, 2 Nov 2015 19:27:40 +0100
Adrien Mazarguil  wrote:

> Thanks for pointing this out, I'm used to avoiding C extensions whenever
> possible but will stick to DPDK style next time.
> 
> Still, it would be nice if we could steer DPDK away from such extensions as
> much as possible. As a library, we should allow user applications to compile
> with flags we can't control (such as -pedantic -std=c99, and various
> -Wsomething)

No. The extensions are very useful, catch errors, and generate more readable 
code.
For example the extension to check printf formats.

[dpdk-dev] Status of bnx2x pmd?

[Mussar, Gary]

> -Original Message-
> From: Harish Patil [mailto:harish.patil at qlogic.com]
> Sent: Monday, November 02, 2015 01:51
> To: Mussar, Gary; dev at dpdk.org
> Subject: Re: [dpdk-dev] Status of bnx2x pmd?
> 
> >
> >I have been attempting to build testpmd with the bnx2x pmd enabled to try
> >and talk through a bcm57810 10G NIC card. I have tried using SR-IOV VFs
> >and I have tried using the PFs. Neither seem to be able to be properly
> >initialized in testpmd and/or testpmd aborts.
> >
> >Is this PMD actually usable or is it trash?
> >
> >Gary
> >
> 
> Could you please explain the SR-IOV configuration that you are trying out?
> Please provide all the details.
> 
> Thanks,


I ultimately want to run dpdk in a VM with PCI pass through on SR-IOV ports. I 
have had no luck there so I thought I would start with DPDK on bare metal using 
the PFs.

I am using Ubuntu 14.04.3 with the Ubuntu 3.19.0-31 kernel and dpdk from the 
dpdk.org master branch (d739ba4c6abf00eeeb680ab4e9540899182ea74d).

# ./tools/dpdk_nic_bind.py --status

Network devices using DPDK-compatible driver

:04:00.0 'NetXtreme II BCM57810 10 Gigabit Ethernet' drv=igb_uio unused=
:04:00.1 'NetXtreme II BCM57810 10 Gigabit Ethernet' drv=igb_uio unused=

Network devices using kernel driver
===
:05:00.0 'I350 Gigabit Network Connection' if=eth0 drv=igb unused=igb_uio 
*Active*
:05:00.1 'I350 Gigabit Network Connection' if=eth1 drv=igb unused=igb_uio

Other network devices
=


Running testpmd:

./app/testpmd -c 7 -n 4 --socket-mem 900 -- -i --burst=64 --txqflags=0xf00 
--nb-cores=2 --nb-ports=2 --portmask=0x3
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 6 on socket 0
EAL: Detected lcore 7 as core 7 on socket 0
EAL: Detected lcore 8 as core 0 on socket 0
EAL: Detected lcore 9 as core 1 on socket 0
EAL: Detected lcore 10 as core 2 on socket 0
EAL: Detected lcore 11 as core 3 on socket 0
EAL: Detected lcore 12 as core 4 on socket 0
EAL: Detected lcore 13 as core 5 on socket 0
EAL: Detected lcore 14 as core 6 on socket 0
EAL: Detected lcore 15 as core 7 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 16 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7420 (size = 0x20)
EAL: Ask a virtual area of 0x14a0 bytes
EAL: Virtual area found at 0x7fffdf60 (size = 0x14a0)
EAL: Ask a virtual area of 0x5680 bytes
EAL: Virtual area found at 0x7fff88c0 (size = 0x5680)
EAL: Ask a virtual area of 0x400 bytes
EAL: Virtual area found at 0x7fff84a0 (size = 0x400)
EAL: Ask a virtual area of 0x5420 bytes
EAL: Virtual area found at 0x7fff3060 (size = 0x5420)
EAL: Ask a virtual area of 0x14c0 bytes
EAL: Virtual area found at 0x7fff1b80 (size = 0x14c0)
EAL: Ask a virtual area of 0x12540 bytes
EAL: Virtual area found at 0x7ffdf620 (size = 0x12540)
EAL: Ask a virtual area of 0x1b00 bytes
EAL: Virtual area found at 0x7ffddb00 (size = 0x1b00)
EAL: Ask a virtual area of 0x1860 bytes
EAL: Virtual area found at 0x7ffdc280 (size = 0x1860)
EAL: Ask a virtual area of 0xf860 bytes
EAL: Virtual area found at 0x7ffcca00 (size = 0xf860)
EAL: Ask a virtual area of 0x3940 bytes
EAL: Virtual area found at 0x7ffc90a0 (size = 0x3940)
EAL: Ask a virtual area of 0x1fc0 bytes
EAL: Virtual area found at 0x7ffc70c0 (size = 0x1fc0)
EAL: Ask a virtual area of 0x74c0 bytes
EAL: Virtual area found at 0x7ffbfbe0 (size = 0x74c0)
EAL: Ask a virtual area of 0x900 bytes
EAL: Virtual area found at 0x7ffbf2c0 (size = 0x900)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7ffbf280 (size = 0x20)
EAL: Requesting 450 pages of size 2MB from socket 0
EAL: TSC frequency is ~1995380 KHz
EAL: Master lcore 0 is ready (tid=f7fe4940;cpuset=[0])
PMD: rte_bnx2x_pmd_init():  >>
PMD: rte_bnx2xvf_pmd_init():  >>
EAL: lcore 2 is ready (tid=f5ec9700;cpuset=[2])
EAL: lcore 1 is ready (tid=f66ca700;cpuset=[1])
EAL: PCI device :04:00.0 on NUMA socket 0
EAL:   probe driver: 14e4:168e rte_bnx2x_pmd
EAL:   PCI memory mapped at 0x7440
EAL:   PCI memory mapped at 0x74c0
EAL:   PCI memory mapped at 0x7540
PMD: eth_bnx2x_dev_init():  >>
PMD: bnx2x_common_dev_init():  >>
PMD: bnx2x_probe_pci_caps():  >>
PMD: bnx2x_get_shmem_info():  >>
PMD: bnx2x_acquire_hw_lock():  >>
PMD: bnx2x_release_hw_lock():  >>
PMD: bnx2x_get_phy_info():  >>
PMD: bnx2x_reset_common():  >>
EAL: PCI device :04:00.1 

[dpdk-dev] [PATCH v7 02/28] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data

[Iremonger, Bernard]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Sunday, November 1, 2015 9:12 PM
> To: Iremonger, Bernard 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 02/28] librte_ether: add fields from
> rte_pci_driver to rte_eth_dev_data
> 
> 2015-10-30 15:08, Bernard Iremonger:
> > add dev_flags to rte_eth_dev_data, add macros for dev_flags.
> > add kdrv to rte_eth_dev_data.
> > add numa_node to rte_eth_dev_data.
> > add drv_name to rte_eth_dev_data.
> 
> A commit message should explain why things are done.
> 
> > +   uint32_t dev_flags; /**< Flags controlling handling of device. */
> 
> Where are defined this flags? What is the scope?

These flags are defined in the following file:

lib/librte_ether/rte_ethdev.h

These flags are visible to all the vdevs and pdevs.

Regards,

Bernard.

[dpdk-dev] [PATCH 1/2] scripts: add checkpatch wrapper

[Bruce Richardson]

On Mon, Nov 02, 2015 at 10:28:35AM +, Van Haaren, Harry wrote:
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Subject: Re: [dpdk-dev] [PATCH 1/2] scripts: add checkpatch wrapper
> > 
> > 2015-10-30 16:16, Bruce Richardson:
> > > Another request, can you perhaps also fix the script for situations where
> > > checkpatch.pl is not in the kernel tree.
> > > 
> 
> > OK
> > I prefer using it in the Linux tree because it is updated with "git pull".
> 
> I would like to suggest including the checkpatch.pl script itself in the dpdk 
> tree, as this would ensure that we are all running the exact same version of 
> checkpatch.
> 
> My previous patchset had errors that I had not detected because I ran an 
> older checkpatch.pl, and I think there are others who have similar issues 
> that the checkpatch version provides more/less errors.
> 
> If included in the repo, we would all automatically upgrade when the next 
> checkpatch.pl is merged - providing consistency.
> 
> -Harry

+1 

/Bruce

[dpdk-dev] [PATCH v7 02/28] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data

[Iremonger, Bernard]

Hi Thomas,



> Subject: Re: [dpdk-dev] [PATCH v7 02/28] librte_ether: add fields from
> rte_pci_driver to rte_eth_dev_data
> 
> 2015-10-30 15:08, Bernard Iremonger:
> > +/** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO)
> */
> > +#define RTE_ETH_DEV_DRV_NEED_MAPPING
> RTE_PCI_DRV_NEED_MAPPING
> > +/** Device needs to be unbound even if no module is provided */
> > +#define RTE_ETH_DEV_DRV_FORCE_UNBIND
> RTE_PCI_DRV_FORCE_UNBIND
> > +/** Device supports link state interrupt */
> > +#define RTE_ETH_DEV_INTR_LSC   RTE_PCI_DRV_INTR_LSC
> > +/** Device  supports detaching capability */ #define
> > +RTE_ETH_DEV_DETACHABLE RTE_PCI_DRV_DETACHABLE
> 
> Please, use an enum which has a name and can be referenced in the API, e.g.
> the variable X contains some X_flags.
> You should not try to re-use the same values as the PCI layer since it will 
> not
> be possible to map it forever when new buses will enter in the game.

I will use an enum  instead.


> > +/** Device  is a bonded device */
> > +#define RTE_ETH_DEV_BONDED 0x0020
> 
> Why not having RTE_ETH_DEV_PCAPED? ;)
> Please try to remove this flag.

I will remove this flag.

Regards,

Bernard.

[dpdk-dev] [PATCHv7 7/9] vmxnet3: add HW specific desc_lim data into dev_info

[Ananyev, Konstantin]

Hi

> -Original Message-
> From: Yong Wang [mailto:yongwang at vmware.com]
> Sent: Saturday, October 31, 2015 8:55 AM
> To: Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCHv7 7/9] vmxnet3: add HW specific desc_lim data 
> into dev_info
> 
> On 10/27/15, 5:51 AM, "Konstantin Ananyev"  
> wrote:
> 
> 
> >Signed-off-by: Konstantin Ananyev 
> >---
> 
> Acked-by: Yong Wang 
> 
> Do you plan to implement rxq_info_get and txq_info_get for vmxnet3 in 
> subsequent patches?

I might, though my hope is that engineers who are familiar with particular PMDs 
will
pick it up and add support for (rxq|txq)_get_info() remaining PMDs.
So if you feel like that, please don't hesitate :)
Thanks
Konstantin 

> 
> > drivers/net/vmxnet3/vmxnet3_ethdev.c | 12 
> > 1 file changed, 12 insertions(+)
> >
> >diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
> >b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> >index a70be5c..3745b7d 100644
> >--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
> >+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> >@@ -677,6 +677,18 @@ vmxnet3_dev_info_get(__attribute__((unused))struct 
> >rte_eth_dev *dev, struct rte_
> > dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> > ETH_TXQ_FLAGS_NOOFFLOADS;
> > dev_info->flow_type_rss_offloads = VMXNET3_RSS_OFFLOAD_ALL;
> >+
> >+dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
> >+.nb_max = VMXNET3_RX_RING_MAX_SIZE,
> >+.nb_min = VMXNET3_DEF_RX_RING_SIZE,
> >+.nb_align = 1,
> >+};
> >+
> >+dev_info->tx_desc_lim = (struct rte_eth_desc_lim) {
> >+.nb_max = VMXNET3_TX_RING_MAX_SIZE,
> >+.nb_min = VMXNET3_DEF_TX_RING_SIZE,
> >+.nb_align = 1,
> >+};
> > }
> >
> > /* return 0 means link status changed, -1 means not changed */
> >--
> >1.8.5.3
> >