from:"Harish Patil"

[dpdk-dev] [PATCH 7/7] net/qede: restrict maximum queues for PF/VF

2016-12-02 Thread Harish Patil

Fix to adverstise max_rx_queues by taking into account the number
of PF connections instead of returning max_queues supported by the
HW.

Fixes: 2ea6f76a ("qede: add core driver")

Signed-off-by: Harish Patil <harish.pa...@qlogic.com>
---
 drivers/net/qede/qede_ethdev.c | 13 ++---
 drivers/net/qede/qede_ethdev.h |  3 +++
 drivers/net/qede/qede_main.c   |  5 -
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 10abb8b..9c2a5ea 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -973,8 +973,15 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev)
dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
dev_info->rx_desc_lim = qede_rx_desc_lim;
dev_info->tx_desc_lim = qede_tx_desc_lim;
-   dev_info->max_rx_queues = (uint16_t)QEDE_MAX_RSS_CNT(qdev);
+
+   if (IS_PF(edev))
+   dev_info->max_rx_queues = (uint16_t)RTE_MIN(
+   QEDE_MAX_RSS_CNT(qdev), QEDE_PF_NUM_CONNS / 2);
+   else
+   dev_info->max_rx_queues = (uint16_t)RTE_MIN(
+   QEDE_MAX_RSS_CNT(qdev), ECORE_MAX_VF_CHAINS_PER_PF);
dev_info->max_tx_queues = dev_info->max_rx_queues;
+
dev_info->max_mac_addrs = qdev->dev_info.num_mac_addrs;
dev_info->max_vfs = 0;
dev_info->reta_size = ECORE_RSS_IND_TABLE_SIZE;
@@ -2015,9 +2022,9 @@ int qede_dev_filter_ctrl(struct rte_eth_dev *eth_dev,
 static void qede_update_pf_params(struct ecore_dev *edev)
 {
struct ecore_pf_params pf_params;
-   /* 32 rx + 32 tx */
+
memset(_params, 0, sizeof(struct ecore_pf_params));
-   pf_params.eth_pf_params.num_cons = 64;
+   pf_params.eth_pf_params.num_cons = QEDE_PF_NUM_CONNS;
qed_ops->common->update_pf_params(edev, _params);
 }
 
diff --git a/drivers/net/qede/qede_ethdev.h b/drivers/net/qede/qede_ethdev.h
index bd85ba3..95e06ef 100644
--- a/drivers/net/qede/qede_ethdev.h
+++ b/drivers/net/qede/qede_ethdev.h
@@ -115,6 +115,9 @@
 
 extern char fw_file[];
 
+/* Number of PF connections - 32 RX + 32 TX */
+#define QEDE_PF_NUM_CONNS  (64)
+
 /* Port/function states */
 enum qede_dev_state {
QEDE_DEV_INIT, /* Init the chip and Slowpath */
diff --git a/drivers/net/qede/qede_main.c b/drivers/net/qede/qede_main.c
index b7202c8..2c88329 100644
--- a/drivers/net/qede/qede_main.c
+++ b/drivers/net/qede/qede_main.c
@@ -399,11 +399,6 @@ static int qed_slowpath_start(struct ecore_dev *edev,
if (edev->num_hwfns > 1) {
ecore_vf_get_num_rxqs(>hwfns[1], );
info->num_queues += queues;
-   /* Restrict 100G VF to advertise 16 queues till the
-* required support is available to go beyond 16.
-*/
-   info->num_queues = RTE_MIN(info->num_queues,
-  ECORE_MAX_VF_CHAINS_PER_PF);
}
 
ecore_vf_get_num_vlan_filters(>hwfns[0],
-- 
1.8.3.1

[dpdk-dev] [PATCH 6/7] net/qede: fix maximum VF count to 0

2016-12-02 Thread Harish Patil

Set max_vfs to 0 since it is relevant only to SR-IOV PF
which is not supported yet.

Fixes: 2ea6f76a ("qede: add core driver")

Signed-off-by: Harish Patil <harish.pa...@qlogic.com>
---
 drivers/net/qede/qede_ethdev.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index ee8fb43..10abb8b 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -976,10 +976,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev)
dev_info->max_rx_queues = (uint16_t)QEDE_MAX_RSS_CNT(qdev);
dev_info->max_tx_queues = dev_info->max_rx_queues;
dev_info->max_mac_addrs = qdev->dev_info.num_mac_addrs;
-   if (IS_VF(edev))
-   dev_info->max_vfs = 0;
-   else
-   dev_info->max_vfs = (uint16_t)NUM_OF_VFS(>edev);
+   dev_info->max_vfs = 0;
dev_info->reta_size = ECORE_RSS_IND_TABLE_SIZE;
dev_info->hash_key_size = ECORE_RSS_KEY_SIZE * sizeof(uint32_t);
dev_info->flow_type_rss_offloads = (uint64_t)QEDE_RSS_OFFLOAD_ALL;
-- 
1.8.3.1

[dpdk-dev] [PATCH 5/7] net/qede: fix RSS related issue

2016-12-02 Thread Harish Patil

This patch includes the following:

- Fix missing hash_key_size advertisement
- Fix RSS hash query function
- Update RSS offload flag
- Accept user provided RSS configuration params via rx_adv_conf
  in dev_configure()
- Decouple RSS configuration from common qed_update_vport() and
  instead make use of existing RSS APIs for default RSS configuration

Fixes: 6d9e26c4 ("net/qede: get RSS hash configuration")
Fixes: 9c5d0a66 ("net/qede: fix RSS")

Signed-off-by: Harish Patil <harish.pa...@qlogic.com>
---
 drivers/net/qede/qede_eth_if.c |  79 +
 drivers/net/qede/qede_eth_if.h |   9 +-
 drivers/net/qede/qede_ethdev.c | 254 ++---
 drivers/net/qede/qede_ethdev.h |   9 +-
 drivers/net/qede/qede_rxtx.c   |  90 +--
 drivers/net/qede/qede_rxtx.h   |  10 +-
 6 files changed, 239 insertions(+), 212 deletions(-)

diff --git a/drivers/net/qede/qede_eth_if.c b/drivers/net/qede/qede_eth_if.c
index 30fded0..7d21200 100644
--- a/drivers/net/qede/qede_eth_if.c
+++ b/drivers/net/qede/qede_eth_if.c
@@ -68,6 +68,33 @@ static int qed_stop_vport(struct ecore_dev *edev, uint8_t 
vport_id)
return 0;
 }
 
+bool qed_update_rss_parm_cmt(struct ecore_dev *edev, uint16_t *p_tbl)
+{
+   uint16_t max = 0, k;
+   bool rss_mode = 0; /* disable */
+   int divisor;
+
+   /* Find largest entry, since it's possible RSS needs to
+* be disabled [in case only 1 queue per-hwfn]
+*/
+   for (k = 0; k < ECORE_RSS_IND_TABLE_SIZE; k++)
+   max = (max > p_tbl[k]) ?  max : p_tbl[k];
+
+   /* Either fix RSS values or disable RSS */
+   if (edev->num_hwfns < max + 1) {
+   divisor = (max + edev->num_hwfns - 1) / edev->num_hwfns;
+   DP_VERBOSE(edev, ECORE_MSG_SPQ,
+  "CMT - fixing RSS values (modulo %02x)\n",
+  divisor);
+   for (k = 0; k < ECORE_RSS_IND_TABLE_SIZE; k++)
+   p_tbl[k] = p_tbl[k] % divisor;
+
+   rss_mode = 1;
+   }
+
+   return rss_mode;
+}
+
 static int
 qed_update_vport(struct ecore_dev *edev, struct qed_update_vport_params 
*params)
 {
@@ -94,58 +121,6 @@ static int qed_stop_vport(struct ecore_dev *edev, uint8_t 
vport_id)
params->update_accept_any_vlan_flg;
sp_params.mtu = params->mtu;
 
-   /* RSS - is a bit tricky, since upper-layer isn't familiar with hwfns.
-* We need to re-fix the rss values per engine for CMT.
-*/
-
-   if (edev->num_hwfns > 1 && params->update_rss_flg) {
-   struct qed_update_vport_rss_params *rss = >rss_params;
-   int k, max = 0;
-
-   /* Find largest entry, since it's possible RSS needs to
-* be disabled [in case only 1 queue per-hwfn]
-*/
-   for (k = 0; k < ECORE_RSS_IND_TABLE_SIZE; k++)
-   max = (max > rss->rss_ind_table[k]) ?
-   max : rss->rss_ind_table[k];
-
-   /* Either fix RSS values or disable RSS */
-   if (edev->num_hwfns < max + 1) {
-   int divisor = (max + edev->num_hwfns - 1) /
-   edev->num_hwfns;
-
-   DP_VERBOSE(edev, ECORE_MSG_SPQ,
-  "CMT - fixing RSS values (modulo %02x)\n",
-  divisor);
-
-   for (k = 0; k < ECORE_RSS_IND_TABLE_SIZE; k++)
-   rss->rss_ind_table[k] =
-   rss->rss_ind_table[k] % divisor;
-   } else {
-   DP_VERBOSE(edev, ECORE_MSG_SPQ,
-  "CMT - 1 queue per-hwfn; Disabling RSS\n");
-   params->update_rss_flg = 0;
-   }
-   }
-
-   /* Now, update the RSS configuration for actual configuration */
-   if (params->update_rss_flg) {
-   sp_rss_params.update_rss_config = 1;
-   sp_rss_params.rss_enable = 1;
-   sp_rss_params.update_rss_capabilities = 1;
-   sp_rss_params.update_rss_ind_table = 1;
-   sp_rss_params.update_rss_key = 1;
-   sp_rss_params.rss_caps = ECORE_RSS_IPV4 | ECORE_RSS_IPV6 |
-   ECORE_RSS_IPV4_TCP | ECORE_RSS_IPV6_TCP;
-   sp_rss_params.rss_table_size_log = 7;   /* 2^7 = 128 */
-   rte_memcpy(sp_rss_params.rss_ind_table,
-  params->rss_params.rss_ind_table,
-  ECORE_RSS_IND_TABLE_SIZE * sizeof(uint16_t));
-   rte_memcpy(sp_rss_params.rss_key, params->rss_params.rss_key,
-  ECORE_RSS_KEY_SIZE * sizeof(uint32_t));
-   sp_params.rss_params = _rss_params;
-   }
-

[dpdk-dev] [PATCH 4/7] net/qede: add fastpath support for VXLAN tunneling

2016-12-02 Thread Harish Patil

- Support HW checksum and RSS offload for VXLAN traffic
- Identify inner/outer packet_types using lookup table
- Update documentation

Signed-off-by: Harish Patil <harish.pa...@qlogic.com>
---
 doc/guides/nics/features/qede.ini |   3 +
 doc/guides/nics/qede.rst  |   3 +-
 drivers/net/qede/qede_eth_if.h|   3 +
 drivers/net/qede/qede_ethdev.c|  18 +--
 drivers/net/qede/qede_ethdev.h|   3 +
 drivers/net/qede/qede_main.c  |   2 +
 drivers/net/qede/qede_rxtx.c  | 280 +++---
 drivers/net/qede/qede_rxtx.h  |  46 +++
 8 files changed, 269 insertions(+), 89 deletions(-)

diff --git a/doc/guides/nics/features/qede.ini 
b/doc/guides/nics/features/qede.ini
index 7d75030..8858e5d 100644
--- a/doc/guides/nics/features/qede.ini
+++ b/doc/guides/nics/features/qede.ini
@@ -23,6 +23,9 @@ CRC offload  = Y
 VLAN offload = Y
 L3 checksum offload  = Y
 L4 checksum offload  = Y
+Tunnel filter= Y
+Inner L3 checksum= Y
+Inner L4 checksum= Y
 Packet type parsing  = Y
 Basic stats  = Y
 Extended stats   = Y
diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index ddf4248..e7332dc 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -59,12 +59,13 @@ Supported Features
 - MTU change
 - Multiprocess aware
 - Scatter-Gather
+- VXLAN tunneling offload
 
 Non-supported Features
 --
 
 - SR-IOV PF
-- Tunneling offloads
+- GENEVE and NVGRE Tunneling offloads
 - LRO/TSO
 - NPAR
 
diff --git a/drivers/net/qede/qede_eth_if.h b/drivers/net/qede/qede_eth_if.h
index 9c0db87..d67b312 100644
--- a/drivers/net/qede/qede_eth_if.h
+++ b/drivers/net/qede/qede_eth_if.h
@@ -42,6 +42,9 @@ struct qed_dev_eth_info {
struct ether_addr port_mac;
uint16_t num_vlan_filters;
uint32_t num_mac_addrs;
+
+   /* Legacy VF - this affects the datapath */
+   bool is_legacy;
 };
 
 struct qed_update_vport_rss_params {
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index bd728c8..e8d4157 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -919,14 +919,16 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev)
.txq_flags = QEDE_TXQ_FLAGS,
};
 
-   dev_info->rx_offload_capa = (DEV_RX_OFFLOAD_VLAN_STRIP |
-DEV_RX_OFFLOAD_IPV4_CKSUM |
-DEV_RX_OFFLOAD_UDP_CKSUM |
-DEV_RX_OFFLOAD_TCP_CKSUM);
-   dev_info->tx_offload_capa = (DEV_TX_OFFLOAD_VLAN_INSERT |
-DEV_TX_OFFLOAD_IPV4_CKSUM |
-DEV_TX_OFFLOAD_UDP_CKSUM |
-DEV_TX_OFFLOAD_TCP_CKSUM);
+   dev_info->rx_offload_capa = (DEV_RX_OFFLOAD_VLAN_STRIP  |
+DEV_RX_OFFLOAD_IPV4_CKSUM  |
+DEV_RX_OFFLOAD_UDP_CKSUM   |
+DEV_RX_OFFLOAD_TCP_CKSUM   |
+DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM);
+   dev_info->tx_offload_capa = (DEV_TX_OFFLOAD_VLAN_INSERT |
+DEV_TX_OFFLOAD_IPV4_CKSUM  |
+DEV_TX_OFFLOAD_UDP_CKSUM   |
+DEV_TX_OFFLOAD_TCP_CKSUM   |
+DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM);
 
memset(, 0, sizeof(struct qed_link_output));
qdev->ops->common->get_link(edev, );
diff --git a/drivers/net/qede/qede_ethdev.h b/drivers/net/qede/qede_ethdev.h
index 6d0616e..d736246 100644
--- a/drivers/net/qede/qede_ethdev.h
+++ b/drivers/net/qede/qede_ethdev.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* ecore includes */
 #include "base/bcm_osal.h"
@@ -184,6 +185,8 @@ static int qede_rss_reta_update(struct rte_eth_dev *eth_dev,
struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size);
 
+static inline uint32_t qede_rx_cqe_to_pkt_type(uint16_t flags);
+
 /* Non-static functions */
 void qede_init_rss_caps(uint8_t *rss_caps, uint64_t hf);
 
diff --git a/drivers/net/qede/qede_main.c b/drivers/net/qede/qede_main.c
index 03058cb..b7202c8 100644
--- a/drivers/net/qede/qede_main.c
+++ b/drivers/net/qede/qede_main.c
@@ -411,6 +411,8 @@ static int qed_slowpath_start(struct ecore_dev *edev,
 
ecore_vf_get_port_mac(>hwfns[0],
  (uint8_t *)>port_mac);
+
+   info->is_legacy = ecore_vf_get_pre_fp_hsi(>hwfns[0]);
}
 
qed_fill_dev_info(edev, >common);
diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
index 2e181c8..6daf193 100644
--- a/drivers/net/qede/qede_rxtx.c
+++ b/drivers/net/qede/qede_rxtx.c
@@ -701,79 +701,64 @@ static int

[dpdk-dev] [PATCH 1/7] net/qede: reduce noise in debug logs

2016-12-02 Thread Harish Patil

From: Rasesh Mody <rasesh.m...@cavium.com>

Replace CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER with
CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL which is a 32-bit bitmapped value
where each bit represent a particular submodule to debug. Also move
notice messages under CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO.

Signed-off-by: Harish Patil <harish.pa...@qlogic.com>
Signed-off-by: Rasesh Mody <rasesh.m...@cavium.com>
---
 config/common_base |  2 +-
 doc/guides/nics/qede.rst   |  4 ++--
 drivers/net/qede/qede_ethdev.c |  4 ++--
 drivers/net/qede/qede_logs.h   | 21 +
 4 files changed, 10 insertions(+), 21 deletions(-)

diff --git a/config/common_base b/config/common_base
index 4bff83a..2ffd557 100644
--- a/config/common_base
+++ b/config/common_base
@@ -320,7 +320,7 @@ CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
 CONFIG_RTE_LIBRTE_QEDE_PMD=y
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
-CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL=0
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
 #Provides abs path/name of the firmware file.
diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index d22ecdd..ddf4248 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -103,9 +103,9 @@ enabling debugging options may affect system performance.
 
   Toggle display of generic debugging messages.
 
-- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER`` (default **n**)
+- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL`` (default **0**)
 
-  Toggle display of ecore related messages.
+  Control driver debug verbosity using 32-bit bitmap flags.
 
 - ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX`` (default **n**)
 
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 2c600c1..69cedd8 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1393,8 +1393,8 @@ static int qede_common_dev_init(struct rte_eth_dev 
*eth_dev, bool is_vf)
uint8_t is_mac_forced;
bool is_mac_exist;
/* Fix up ecore debug level */
-   uint32_t dp_module = ~0 & ~ECORE_MSG_HW;
-   uint8_t dp_level = ECORE_LEVEL_VERBOSE;
+   uint32_t dp_module = RTE_LIBRTE_QEDE_DEBUG_VAL;
+   uint8_t dp_level = ECORE_LEVEL_NOTICE;
uint32_t max_mac_addrs;
int rc;
 
diff --git a/drivers/net/qede/qede_logs.h b/drivers/net/qede/qede_logs.h
index 45c4af0..08fdf04 100644
--- a/drivers/net/qede/qede_logs.h
+++ b/drivers/net/qede/qede_logs.h
@@ -16,15 +16,18 @@
(p_dev)->name ? (p_dev)->name : "", \
##__VA_ARGS__)
 
+#ifdef RTE_LIBRTE_QEDE_DEBUG_INFO
 #define DP_NOTICE(p_dev, is_assert, fmt, ...) \
rte_log(RTE_LOG_NOTICE, RTE_LOGTYPE_PMD,\
"[QEDE PMD: (%s)]%s:" fmt, \
(p_dev)->name ? (p_dev)->name : "", \
 __func__, \
##__VA_ARGS__)
+#else
+#define DP_NOTICE(p_dev, fmt, ...) do { } while (0)
+#endif
 
 #ifdef RTE_LIBRTE_QEDE_DEBUG_INFO
-
 #define DP_INFO(p_dev, fmt, ...) \
rte_log(RTE_LOG_INFO, RTE_LOGTYPE_PMD, \
"[%s:%d(%s)]" fmt, \
@@ -33,10 +36,8 @@
##__VA_ARGS__)
 #else
 #define DP_INFO(p_dev, fmt, ...) do { } while (0)
-
 #endif
 
-#ifdef RTE_LIBRTE_QEDE_DEBUG_DRIVER
 #define DP_VERBOSE(p_dev, module, fmt, ...) \
 do { \
if ((p_dev)->dp_module & module) \
@@ -46,9 +47,7 @@
  (p_dev)->name ? (p_dev)->name : "", \
  ##__VA_ARGS__); \
 } while (0)
-#else
-#define DP_VERBOSE(p_dev, fmt, ...) do { } while (0)
-#endif
+
 
 #define PMD_INIT_LOG(level, edev, fmt, args...)\
rte_log(RTE_LOG_ ## level, RTE_LOGTYPE_PMD, \
@@ -77,14 +76,4 @@
 #define PMD_RX_LOG(level, q, fmt, args...) do { } while (0)
 #endif
 
-#ifdef RTE_LIBRTE_QEDE_DEBUG_DRIVER
-#define PMD_DRV_LOG_RAW(level, fmt, args...) \
-   RTE_LOG(level, PMD, "%s(): " fmt, __func__, ## args)
-#else
-#define PMD_DRV_LOG_RAW(level, fmt, args...) do { } while (0)
-#endif
-
-#define PMD_DRV_LOG(level, fmt, args...) \
-   PMD_DRV_LOG_RAW(level, fmt "\n", ## args)
-
 #endif /* _QEDE_LOGS_H_ */
-- 
1.8.3.1

[dpdk-dev] [PATCH 2/7] net/qede: refactor filtering code

2016-12-02 Thread Harish Patil

The filter_config in qed_eth_ops_pass is a wrapper call driving all the
filtering configuration. This requires defining multiple structures and
passing different function arguments for each filter type which is
unnecessary. So as part of this refactoring we remove filter_config from
qed_eth_ops_pass and invoke base apis directly. Another change is to
use a singly list for unicast/multicast macs and thereby prevent duplicate
entries.

This change is primarily intended to support future tunneling support
which makes use of existing L2 filtering/classifications.

Fixes: 2ea6f76a ("qede: add core driver")

Signed-off-by: Harish Patil <harish.pa...@qlogic.com>
---
 drivers/net/qede/qede_eth_if.c | 101 +-
 drivers/net/qede/qede_eth_if.h |  36 +
 drivers/net/qede/qede_ethdev.c | 303 -
 drivers/net/qede/qede_ethdev.h |  15 ++
 4 files changed, 230 insertions(+), 225 deletions(-)

diff --git a/drivers/net/qede/qede_eth_if.c b/drivers/net/qede/qede_eth_if.c
index 1ae6127..30fded0 100644
--- a/drivers/net/qede/qede_eth_if.c
+++ b/drivers/net/qede/qede_eth_if.c
@@ -310,86 +310,11 @@ static void qed_fastpath_start(struct ecore_dev *edev)
ecore_get_vport_stats(edev, stats);
 }
 
-static int
-qed_configure_filter_ucast(struct ecore_dev *edev,
-  struct qed_filter_ucast_params *params)
-{
-   struct ecore_filter_ucast ucast;
-
-   if (!params->vlan_valid && !params->mac_valid) {
-   DP_NOTICE(edev, true,
- "Tried configuring a unicast filter,"
- "but both MAC and VLAN are not set\n");
-   return -EINVAL;
-   }
-
-   memset(, 0, sizeof(ucast));
-   switch (params->type) {
-   case QED_FILTER_XCAST_TYPE_ADD:
-   ucast.opcode = ECORE_FILTER_ADD;
-   break;
-   case QED_FILTER_XCAST_TYPE_DEL:
-   ucast.opcode = ECORE_FILTER_REMOVE;
-   break;
-   case QED_FILTER_XCAST_TYPE_REPLACE:
-   ucast.opcode = ECORE_FILTER_REPLACE;
-   break;
-   default:
-   DP_NOTICE(edev, true, "Unknown unicast filter type %d\n",
- params->type);
-   }
-
-   if (params->vlan_valid && params->mac_valid) {
-   ucast.type = ECORE_FILTER_MAC_VLAN;
-   ether_addr_copy((struct ether_addr *)>mac,
-   (struct ether_addr *));
-   ucast.vlan = params->vlan;
-   } else if (params->mac_valid) {
-   ucast.type = ECORE_FILTER_MAC;
-   ether_addr_copy((struct ether_addr *)>mac,
-   (struct ether_addr *));
-   } else {
-   ucast.type = ECORE_FILTER_VLAN;
-   ucast.vlan = params->vlan;
-   }
-
-   ucast.is_rx_filter = true;
-   ucast.is_tx_filter = true;
-
-   return ecore_filter_ucast_cmd(edev, , ECORE_SPQ_MODE_CB, NULL);
-}
-
-static int
-qed_configure_filter_mcast(struct ecore_dev *edev,
-  struct qed_filter_mcast_params *params)
-{
-   struct ecore_filter_mcast mcast;
-   int i;
-
-   memset(, 0, sizeof(mcast));
-   switch (params->type) {
-   case QED_FILTER_XCAST_TYPE_ADD:
-   mcast.opcode = ECORE_FILTER_ADD;
-   break;
-   case QED_FILTER_XCAST_TYPE_DEL:
-   mcast.opcode = ECORE_FILTER_REMOVE;
-   break;
-   default:
-   DP_NOTICE(edev, true, "Unknown multicast filter type %d\n",
- params->type);
-   }
-
-   mcast.num_mc_addrs = params->num;
-   for (i = 0; i < mcast.num_mc_addrs; i++)
-   ether_addr_copy((struct ether_addr *)>mac[i],
-   (struct ether_addr *)[i]);
-
-   return ecore_filter_mcast_cmd(edev, , ECORE_SPQ_MODE_CB, NULL);
-}
-
-int qed_configure_filter_rx_mode(struct ecore_dev *edev,
+int qed_configure_filter_rx_mode(struct rte_eth_dev *eth_dev,
 enum qed_filter_rx_mode_type type)
 {
+   struct qede_dev *qdev = QEDE_INIT_QDEV(eth_dev);
+   struct ecore_dev *edev = QEDE_INIT_EDEV(qdev);
struct ecore_filter_accept_flags flags;
 
memset(, 0, sizeof(flags));
@@ -422,25 +347,6 @@ int qed_configure_filter_rx_mode(struct ecore_dev *edev,
   ECORE_SPQ_MODE_CB, NULL);
 }
 
-static int
-qed_configure_filter(struct ecore_dev *edev, struct qed_filter_params *params)
-{
-   switch (params->type) {
-   case QED_FILTER_TYPE_UCAST:
-   return qed_configure_filter_ucast(edev, >filter.ucast);
-   case QED_FILTER_TYPE_MCAST:
-   return qed_configure_filter_mcast(edev, >filter.mcast);
-   case QED_FILTER_TYPE_RX_M

[dpdk-dev] [PATCH 3/7] net/qede: add slowpath support for VXLAN tunneling

2016-12-02 Thread Harish Patil

- Enable/disable VXLAN tunneling
- Add/remove VXLAN classification rules
- Destination UDP port configuration

Signed-off-by: Harish Patil <harish.pa...@qlogic.com>
---
 drivers/net/qede/base/ecore_l2.c |   3 +
 drivers/net/qede/base/ecore_l2_api.h |   1 +
 drivers/net/qede/qede_ethdev.c   | 400 ++-
 drivers/net/qede/qede_ethdev.h   |   7 +
 drivers/net/qede/qede_main.c |  14 --
 drivers/net/qede/qede_rxtx.h |   2 +-
 6 files changed, 411 insertions(+), 16 deletions(-)

diff --git a/drivers/net/qede/base/ecore_l2.c b/drivers/net/qede/base/ecore_l2.c
index 74f61b0..a893cb9 100644
--- a/drivers/net/qede/base/ecore_l2.c
+++ b/drivers/net/qede/base/ecore_l2.c
@@ -1093,6 +1093,9 @@ static void ecore_set_fw_mac_addr(__le16 *fw_msb,
case ECORE_FILTER_VNI:
p_first_filter->type = ETH_FILTER_TYPE_VNI;
break;
+   case ECORE_FILTER_UNUSED: /* @DPDK */
+   p_first_filter->type = MAX_ETH_FILTER_TYPE;
+   break;
}
 
if ((p_first_filter->type == ETH_FILTER_TYPE_MAC) ||
diff --git a/drivers/net/qede/base/ecore_l2_api.h 
b/drivers/net/qede/base/ecore_l2_api.h
index 326fa45..c338f5d 100644
--- a/drivers/net/qede/base/ecore_l2_api.h
+++ b/drivers/net/qede/base/ecore_l2_api.h
@@ -89,6 +89,7 @@ enum ecore_filter_ucast_type {
ECORE_FILTER_INNER_MAC_VNI_PAIR,
ECORE_FILTER_MAC_VNI_PAIR,
ECORE_FILTER_VNI,
+   ECORE_FILTER_UNUSED, /* @DPDK */
 };
 
 struct ecore_filter_ucast {
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 1e21cb2..bd728c8 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -14,6 +14,111 @@
 static const struct qed_eth_ops *qed_ops;
 static int64_t timer_period = 1;
 
+/* VXLAN tunnel classification mapping */
+const struct _qede_vxlan_tunn_types {
+   uint16_t rte_filter_type;
+   enum ecore_filter_ucast_type qede_type;
+   enum ecore_tunn_clss qede_tunn_clss;
+   const char *string;
+} qede_tunn_types[] = {
+   {
+   ETH_TUNNEL_FILTER_OMAC,
+   ECORE_FILTER_MAC,
+   ECORE_TUNN_CLSS_MAC_VLAN,
+   "outer-mac"
+   },
+   {
+   ETH_TUNNEL_FILTER_TENID,
+   ECORE_FILTER_VNI,
+   ECORE_TUNN_CLSS_MAC_VNI,
+   "vni"
+   },
+   {
+   ETH_TUNNEL_FILTER_IMAC,
+   ECORE_FILTER_INNER_MAC,
+   ECORE_TUNN_CLSS_INNER_MAC_VLAN,
+   "inner-mac"
+   },
+   {
+   ETH_TUNNEL_FILTER_IVLAN,
+   ECORE_FILTER_INNER_VLAN,
+   ECORE_TUNN_CLSS_INNER_MAC_VLAN,
+   "inner-vlan"
+   },
+   {
+   ETH_TUNNEL_FILTER_OMAC | ETH_TUNNEL_FILTER_TENID,
+   ECORE_FILTER_MAC_VNI_PAIR,
+   ECORE_TUNN_CLSS_MAC_VNI,
+   "outer-mac and vni"
+   },
+   {
+   ETH_TUNNEL_FILTER_OMAC | ETH_TUNNEL_FILTER_IMAC,
+   ECORE_FILTER_UNUSED,
+   MAX_ECORE_TUNN_CLSS,
+   "outer-mac and inner-mac"
+   },
+   {
+   ETH_TUNNEL_FILTER_OMAC | ETH_TUNNEL_FILTER_IVLAN,
+   ECORE_FILTER_UNUSED,
+   MAX_ECORE_TUNN_CLSS,
+   "outer-mac and inner-vlan"
+   },
+   {
+   ETH_TUNNEL_FILTER_TENID | ETH_TUNNEL_FILTER_IMAC,
+   ECORE_FILTER_INNER_MAC_VNI_PAIR,
+   ECORE_TUNN_CLSS_INNER_MAC_VNI,
+   "vni and inner-mac",
+   },
+   {
+   ETH_TUNNEL_FILTER_TENID | ETH_TUNNEL_FILTER_IVLAN,
+   ECORE_FILTER_UNUSED,
+   MAX_ECORE_TUNN_CLSS,
+   "vni and inner-vlan",
+   },
+   {
+   ETH_TUNNEL_FILTER_IMAC | ETH_TUNNEL_FILTER_IVLAN,
+   ECORE_FILTER_INNER_PAIR,
+   ECORE_TUNN_CLSS_INNER_MAC_VLAN,
+   "inner-mac and inner-vlan",
+   },
+   {
+   ETH_TUNNEL_FILTER_OIP,
+   ECORE_FILTER_UNUSED,
+   MAX_ECORE_TUNN_CLSS,
+   "outer-IP"
+   },
+   {
+   ETH_TUNNEL_FILTER_IIP,
+   ECORE_FILTER_UNUSED,
+   MAX_ECORE_TUNN_CLSS,
+   "inner-IP"
+   },
+   {
+   RTE_TUNNEL_FILTER_IMAC_IVLAN,
+   ECORE_FILTER_UNUSED,
+   MAX_ECORE_TUNN_CLSS,
+   "IMAC_IVLAN"
+   },
+   {
+   RTE_TUNNEL_FILTER_IMAC_IVLAN_TENID,
+   ECORE_FILTER_UNUSED,
+   MAX_ECORE_TUNN_CLSS,
+   "IMAC_IVLAN_TENID"
+   },
+   {
+   RTE_TUNNEL_FILTER_IMAC_TENID,
+   ECORE_FILTER_UNUSED,
+   MAX_ECORE_TUNN_CLSS,
+   &q

[dpdk-dev] [PATCH v12 0/6] add Tx preparation

2016-11-30 Thread Harish Patil

>
>
>
>Hi Harish,
>> 
>> 
>> >We need attention of every PMD developers on this thread.
>> >
>> >Reminder of what Konstantin suggested:
>> >"
>> >- if the PMD supports TX offloads AND
>> >- if to be able use any of these offloads the upper layer SW would have
>> >to:
>> >* modify the contents of the packet OR
>> >* obey HW specific restrictions
>> >then it is a PMD developer responsibility to provide tx_prep() that
>>would
>> >implement
>> >expected modifications of the packet contents and restriction checks.
>> >Otherwise, tx_prep() implementation is not required and can be safely
>>set
>> >to NULL.
>> >"
>> >
>> >I copy/paste also my previous conclusion:
>> >
>> >Before txprep, there is only one API: the application must prepare the
>> >packets checksum itself (get_psd_sum in testpmd).
>> >With txprep, the application have 2 choices: keep doing the job itself
>> >or call txprep which calls a PMD-specific function.
>> >The question is: does non-Intel drivers need a checksum preparation for
>> >TSO?
>> >Will it behave well if txprep does nothing in these drivers?
>> >
>> >When looking at the code, most of drivers handle the TSO flags.
>> >But it is hard to know whether they rely on the pseudo checksum or not.
>> >
>> >git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG'
>> >drivers/net/
>> >
>> >drivers/net/bnxt/bnxt_txr.c
>> >drivers/net/cxgbe/sge.c
>> >drivers/net/e1000/em_rxtx.c
>> >drivers/net/e1000/igb_rxtx.c
>> >drivers/net/ena/ena_ethdev.c
>> >drivers/net/enic/enic_rxtx.c
>> >drivers/net/fm10k/fm10k_rxtx.c
>> >drivers/net/i40e/i40e_rxtx.c
>> >drivers/net/ixgbe/ixgbe_rxtx.c
>> >drivers/net/mlx4/mlx4.c
>> >drivers/net/mlx5/mlx5_rxtx.c
>> >drivers/net/nfp/nfp_net.c
>> >drivers/net/qede/qede_rxtx.c
>> >drivers/net/thunderx/nicvf_rxtx.c
>> >drivers/net/virtio/virtio_rxtx.c
>> >drivers/net/vmxnet3/vmxnet3_rxtx.c
>> >
>> >Please, we need a comment for each driver saying
>> >"it is OK, we do not need any checksum preparation for TSO"
>> >or
>> >"yes we have to implement tx_prepare or TSO will not work in this mode"
>> >
>> 
>> qede PMD doesn?t currently support TSO yet, it only supports Tx
>>TCP/UDP/IP
>> csum offloads.
>> So Tx preparation isn?t applicable. So as of now -
>> "it is OK, we do not need any checksum preparation for TSO"
>
>Thanks for the answer.
>Though please note that it not only for TSO.

Okay. I initially thought so. But was not sure, so I explicitly indicated
that there is no TSO support.

>This is for any TX offload for which the upper layer SW would have
>to modify the contents of the packet.
>Though as I can see for qede neither PKT_TX_IP_CKSUM or PKT_TX_TCP_CKSUM
>exhibits any extra requirements for the user.
>Is that correct?

That?s right.

>
>Konstantin   
>
>
>> 
>> 
>> Thanks,
>> Harish
>
>

[dpdk-dev] [PATCH v12 0/6] add Tx preparation

2016-11-30 Thread Harish Patil



>We need attention of every PMD developers on this thread.
>
>Reminder of what Konstantin suggested:
>"
>- if the PMD supports TX offloads AND
>- if to be able use any of these offloads the upper layer SW would have
>to:
>* modify the contents of the packet OR
>* obey HW specific restrictions
>then it is a PMD developer responsibility to provide tx_prep() that would
>implement
>expected modifications of the packet contents and restriction checks.
>Otherwise, tx_prep() implementation is not required and can be safely set
>to NULL.  
>"
>
>I copy/paste also my previous conclusion:
>
>Before txprep, there is only one API: the application must prepare the
>packets checksum itself (get_psd_sum in testpmd).
>With txprep, the application have 2 choices: keep doing the job itself
>or call txprep which calls a PMD-specific function.
>The question is: does non-Intel drivers need a checksum preparation for
>TSO?
>Will it behave well if txprep does nothing in these drivers?
>
>When looking at the code, most of drivers handle the TSO flags.
>But it is hard to know whether they rely on the pseudo checksum or not.
>
>git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG'
>drivers/net/
>
>drivers/net/bnxt/bnxt_txr.c
>drivers/net/cxgbe/sge.c
>drivers/net/e1000/em_rxtx.c
>drivers/net/e1000/igb_rxtx.c
>drivers/net/ena/ena_ethdev.c
>drivers/net/enic/enic_rxtx.c
>drivers/net/fm10k/fm10k_rxtx.c
>drivers/net/i40e/i40e_rxtx.c
>drivers/net/ixgbe/ixgbe_rxtx.c
>drivers/net/mlx4/mlx4.c
>drivers/net/mlx5/mlx5_rxtx.c
>drivers/net/nfp/nfp_net.c
>drivers/net/qede/qede_rxtx.c
>drivers/net/thunderx/nicvf_rxtx.c
>drivers/net/virtio/virtio_rxtx.c
>drivers/net/vmxnet3/vmxnet3_rxtx.c
>
>Please, we need a comment for each driver saying
>"it is OK, we do not need any checksum preparation for TSO"
>or
>"yes we have to implement tx_prepare or TSO will not work in this mode"
>

qede PMD doesn?t currently support TSO yet, it only supports Tx TCP/UDP/IP
csum offloads.
So Tx preparation isn?t applicable. So as of now -
"it is OK, we do not need any checksum preparation for TSO"


Thanks,
Harish

[dpdk-dev] [PATCH v2] net/qede: fix unknown speed errmsg for 25G link

2016-11-11 Thread Harish Patil

- Fix to use bitmapped values in NVM configuration for speed capability
  advertisement. This issue is specific to 25G NIC since it is capable
  of 25G and 10G speeds.

- Update feature list.

Fixes: 64c239b7f8b7 ("net/qede: fix advertising link speed capability")

Signed-off-by: Harish Patil 
---
 config/common_base   |  2 +-
 doc/guides/nics/features/qede.ini|  1 +
 doc/guides/nics/features/qede_vf.ini |  1 +
 doc/guides/nics/qede.rst |  2 +-
 drivers/net/qede/qede_ethdev.c   | 15 ++-
 drivers/net/qede/qede_if.h   |  2 +-
 drivers/net/qede/qede_main.c | 25 ++---
 7 files changed, 21 insertions(+), 27 deletions(-)

diff --git a/config/common_base b/config/common_base
index 21d18f8..4bff83a 100644
--- a/config/common_base
+++ b/config/common_base
@@ -315,7 +315,7 @@ CONFIG_RTE_LIBRTE_PMD_BOND=y
 CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
 CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n

-# QLogic 25G/40G/100G PMD
+# QLogic 10G/25G/40G/100G PMD
 #
 CONFIG_RTE_LIBRTE_QEDE_PMD=y
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
diff --git a/doc/guides/nics/features/qede.ini 
b/doc/guides/nics/features/qede.ini
index 1f3c3f6..7d75030 100644
--- a/doc/guides/nics/features/qede.ini
+++ b/doc/guides/nics/features/qede.ini
@@ -4,6 +4,7 @@
 ; Refer to default.ini for the full list of available PMD features.
 ;
 [Features]
+Speed capabilities   = Y
 Link status  = Y
 Link status event= Y
 MTU update   = Y
diff --git a/doc/guides/nics/features/qede_vf.ini 
b/doc/guides/nics/features/qede_vf.ini
index 1c0f228..acb1b99 100644
--- a/doc/guides/nics/features/qede_vf.ini
+++ b/doc/guides/nics/features/qede_vf.ini
@@ -4,6 +4,7 @@
 ; Refer to default.ini for the full list of available PMD features.
 ;
 [Features]
+Speed capabilities   = Y
 Link status  = Y
 Link status event= Y
 MTU update   = Y
diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index b6f54fd..d22ecdd 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -71,7 +71,7 @@ Non-supported Features
 Supported QLogic Adapters
 -

-- QLogic FastLinQ QL4 25G/40G/100G CNAs.
+- QLogic FastLinQ QL4 10G/25G/40G/100G CNAs.

 Prerequisites
 -
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 59129f2..d106dd0 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -647,6 +647,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
struct qede_dev *qdev = eth_dev->data->dev_private;
struct ecore_dev *edev = >edev;
struct qed_link_output link;
+   uint32_t speed_cap = 0;

PMD_INIT_FUNC_TRACE(edev);

@@ -681,7 +682,19 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,

memset(, 0, sizeof(struct qed_link_output));
qdev->ops->common->get_link(edev, );
-   dev_info->speed_capa = rte_eth_speed_bitflag(link.adv_speed, 0);
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G)
+   speed_cap |= ETH_LINK_SPEED_1G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G)
+   speed_cap |= ETH_LINK_SPEED_10G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G)
+   speed_cap |= ETH_LINK_SPEED_25G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G)
+   speed_cap |= ETH_LINK_SPEED_40G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G)
+   speed_cap |= ETH_LINK_SPEED_50G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_BB_100G)
+   speed_cap |= ETH_LINK_SPEED_100G;
+   dev_info->speed_capa = speed_cap;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/qede/qede_if.h b/drivers/net/qede/qede_if.h
index 4936349..2131fe2 100644
--- a/drivers/net/qede/qede_if.h
+++ b/drivers/net/qede/qede_if.h
@@ -70,7 +70,7 @@ struct qed_link_output {
uint32_t advertised_caps;   /* In ADVERTISED defs */
uint32_t lp_caps;   /* In ADVERTISED defs */
uint32_t speed; /* In Mb/s */
-   uint32_t adv_speed; /* In Mb/s */
+   uint32_t adv_speed; /* Speed mask */
uint8_t duplex; /* In DUPLEX defs */
uint8_t port;   /* In PORT defs */
bool autoneg;
diff --git a/drivers/net/qede/qede_main.c b/drivers/net/qede/qede_main.c
index d2e476c..ab22409 100644
--- a/drivers/net/qede/qede_main.c
+++ b/drivers/net/qede/qede_main.c
@@ -488,7 +488,6 @@ static void qed_fill_link(struct ecore_hwfn *hwfn,
struct ecore_mcp_link_state link;
struct ecore_mcp_link_capabilities link_caps;
uint32_t media_type;
-   uint32_t adv_speed;
uint8_t change = 0;

memset(if_link, 0, sizeof(*if_link));
@@ -516,28 +515,8 @@ static void qed_f

[dpdk-dev] [PATCH v3] net/qede: fix advertising link speed capability

2016-11-10 Thread Harish Patil

>
>2016-10-31 11:35, Rasesh Mody:
>> From: Harish Patil 
>> 
>> Fix to advertise device's link speed capability based on NVM
>> port configuration instead of returning driver supported speeds.
>> 
>> Fixes: 95e67b479506 ("net/qede: add 100G link speed capability")
>> 
>> Signed-off-by: Harish Patil 
>[...]
>> +/* Fill up the native advertised speed */
>> +switch (params.speed.advertised_speeds) {
>> +case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G:
>> +adv_speed = 1;
>> +break;
>> +case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G:
>> +adv_speed = 25000;
>> +break;
>> +case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G:
>> +adv_speed = 4;
>> +break;
>> +case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G:
>> +adv_speed = 5;
>> +break;
>> +case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_BB_100G:
>> +adv_speed = 10;
>> +break;
>> +default:
>> +DP_NOTICE(hwfn, false, "Unknown speed\n");
>> +adv_speed = 0;
>> +}
>> +if_link->adv_speed = adv_speed;
>
>The qede devices support only one speed?
>I guess it is wrong but it is a step in right direction so it
>will be enough for 16.11.
>
>Applied
>
qede device is capable of 10, 25, 40, 50, 100Gb speeds.
It's configured at factory to have 100Gb, 50Gb, 40Gb or 25Gb speeds.
A unique PCI ID gets assigned to the device based on the speed configured.
25G device can auto-negotiate down to 10G speeds when connected to a 10G
switch.

So only for 25G case the above logic does not work correctly, for which I
have a submitted a minor fix today:
("[PATCH] net/qede: fix unknown speed errmsg for 25G link?). Pls include
it in 16.11.

Thanks,
Harish

[dpdk-dev] [PATCH] scripts: remove zlib dependency to test qede build

2016-11-06 Thread Harish Patil

>
>The driver qede does not depend on zlib anymore.
>
>Fixes: 7d178e9ef614 ("net/qede: remove zlib dependency and enable PMD")
>
>Signed-off-by: Thomas Monjalon 
>---
> scripts/test-build.sh | 2 --
> 1 file changed, 2 deletions(-)
>
>diff --git a/scripts/test-build.sh b/scripts/test-build.sh
>index e0163ed..a979309 100755
>--- a/scripts/test-build.sh
>+++ b/scripts/test-build.sh
>@@ -171,8 +171,6 @@ config () #   
>   sed -ri   's,(PMD_SZEDATA2=)n,\1y,' $1/.config
>   test "$DPDK_DEP_ZLIB" != y || \
>   sed -ri  's,(BNX2X_PMD=)n,\1y,' $1/.config
>-  test "$DPDK_DEP_ZLIB" != y || \
>-  sed -ri   's,(QEDE_PMD=)n,\1y,' $1/.config
>   sed -ri's,(NFP_PMD=)n,\1y,' $1/.config
>   test "$DPDK_DEP_PCAP" != y || \
>   sed -ri   's,(PCAP=)n,\1y,' $1/.config
>-- 
>2.7.0
>
>

Acked-by: Harish Patil

[dpdk-dev] [PATCH] net/qede: fix advertising link speed capability

2016-10-29 Thread Harish Patil


>2016-10-27 23:42, Rasesh Mody:
>> From: Harish Patil 
>> 
>> Fix to advertise device's link speed capability based on current
>> link speed rather than returning driver supported speeds.
>[...]
>> -dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G |
>> -   ETH_LINK_SPEED_100G;
>> +memset(, 0, sizeof(struct qed_link_output));
>> +qdev->ops->common->get_link(edev, );
>> +dev_info->speed_capa = rte_eth_speed_bitflag(link.speed, 0);
>>  }
>
>No, that's wrong.
>You must advertise a capability!
Got it. It was not very clear to me. Let me send out v2 patch that would
advertise native link speed based on the NIC personality configured (and
not based on current/negotiated link speed).

>So what the device supports?
10, 25, 40, 50, 100G speeds
>Are every qede devices support ETH_LINK_SPEED_100G?
No

[dpdk-dev] [PATCH v4 18/32] net/qede: add missing 100G link speed capability

2016-10-26 Thread Harish Patil


>2016-10-18 21:11, Rasesh Mody:
>> From: Harish Patil 
>> 
>> This patch fixes the missing 100G link speed advertisement
>> when the 100G support was initially added.
>> 
>> Fixes: 2af14ca79c0a ("net/qede: support 100G")
>> 
>> Signed-off-by: Harish Patil 
>[...]
>>  [Features]
>> +Speed capabilities   = Y
>
>This feature should be checked only when it is fully implemented,
>i.e. when you return the real capabilities of the device.
>
>> --- a/drivers/net/qede/qede_ethdev.c
>> +++ b/drivers/net/qede/qede_ethdev.c
>> @@ -599,7 +599,8 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
>>   DEV_TX_OFFLOAD_UDP_CKSUM |
>>   DEV_TX_OFFLOAD_TCP_CKSUM);
>>  
>> -dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G;
>> +dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G |
>> +   ETH_LINK_SPEED_100G;
>>  }
>
>It is only faking the capabilities at driver-level.
>You should check if the underlying device is able to achieve 100G
>before advertising this flag to the application.
>
>I suggest to update this patch to remove the doc update.
>The contract is to fill it only when the code is fixed.
>By the way, we must call every other drivers to properly implement
>this feature.
>

Hi Thomas,
Its not really a faking. The same driver supports all three link speeds.
The required support for 100G was already present in the 16.07 inbox
driver.
We just had missed out advertising 100G link speed via
dev_info->speed_capa.
Hence it is - Fixes: 2af14ca79c0a ("net/qede: support 100G?).
Hope it is okay.


Thanks,
Harish

[dpdk-dev] [PATCH 1/2] bnx2x: fix maximum PF queues

2016-10-11 Thread Harish Patil

>

>On Wed, 2016-10-05 at 22:36 -0700, Rasesh Mody wrote:
>> Fix the max number of PF rx/tx queues. Set the value based
>> on BNX2X_MAX_RSS_COUNT() rather than hard coding it to 128.
>> 
>> Fixes: 540a211 ("bnx2x: driver core")
>> 
>> Signed-off-by: Rasesh Mody 
>> ---
>>  drivers/net/bnx2x/bnx2x.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
>> index a49a07f..2bb4a84 100644
>> --- a/drivers/net/bnx2x/bnx2x.c
>> +++ b/drivers/net/bnx2x/bnx2x.c
>> @@ -9556,8 +9556,8 @@ static void bnx2x_init_rte(struct bnx2x_softc *sc)
>>  sc->max_rx_queues = min(BNX2X_VF_MAX_QUEUES_PER_VF,
>>  sc->igu_sb_cnt);
>>  } else {
>> -sc->max_tx_queues = 128;
>> -sc->max_rx_queues = 128;
>> +sc->max_rx_queues = BNX2X_MAX_RSS_COUNT(sc);
>> +sc->max_tx_queues = sc->max_rx_queues;
>>  }
>>  }
>
>Technically, I think max_tx_queues would be max_rx_queues * max_cos.
>However, I don't think there are any DPDK applications that would take
>advantage of this.
>
>Acked-By: Chas Williams <3chas3 at gmail.com>
>

Thanks Chas.
Ideally yes that?s the case.
But the driver doesn?t support asymmetrical no. of rx/tx queues, its only
the queue-pairs and hence RX=TX.
Many places in the driver assumes rx/tx queues are same and loop on rss_id
to access the corresponding tss_id.

Thanks,
Harish

[dpdk-dev] virtio PMD issue

2016-07-15 Thread Harish Patil

>
>it is fixed in 16.07-rc2 that I checked

Great, thanks.

>
>Vincent
>
>On Fri, Jul 15, 2016 at 11:48 AM, Harish Patil 
>wrote:
>> Hi Huawie/Yuanhan,
>> I encounter segfault issue in virtio PMD driver when I run any DPDK
>> application in the VM. The virtio devices should not have been probed in
>> the first place since they are not attached to igb_uio driver (and
>>managed
>> by kernel driver).
>>
>>
>> Network devices using DPDK-compatible driver
>> 
>> :00:09.0 'FastLinQ QL45000 Series 25GbE Controller' drv=igb_uio
>>unused=
>> :00:0a.0 'FastLinQ QL45000 Series 25GbE Controller' drv=igb_uio
>>unused=
>>
>> Network devices using kernel driver
>> ===
>> :00:03.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio
>>
>>
>>
>> #0 0x004e5392 in vtpci_init (dev=0xb61970, hw=0x7fff76146600)
>> at /home2/hpatil/dpdk/drivers/net/virtio/virtio_pci.c:653
>> #1 0x004effc4 in eth_virtio_dev_init (eth_dev=0xacb7a0
>> )
>> at /home2/hpatil/dpdk/drivers/net/virtio/virtio_ethdev.c:1060
>> #2 0x004b730f in rte_eth_dev_init ()
>> #3 0x004cb940 in pci_probe_all_drivers ()
>> #4 0x004cbe88 in rte_eal_pci_probe ()
>> #5 0x004c0336 in rte_eal_init ()
>> #6 0x004404e2 in main ()
>> (gdb) p dev->devargs
>> $1 = (struct rte_devargs *) 0x0
>>
>>
>> Looks like its a known issue based on a old thread:
>> http://dpdk.org/dev/patchwork/patch/12462/
>>
>> Do we know a fix now?
>>
>> Thanks,
>> harish
>>
>>
>>
>>
>

[dpdk-dev] virtio PMD issue

2016-07-15 Thread Harish Patil

Hi Huawie/Yuanhan,
I encounter segfault issue in virtio PMD driver when I run any DPDK
application in the VM. The virtio devices should not have been probed in
the first place since they are not attached to igb_uio driver (and managed
by kernel driver).


Network devices using DPDK-compatible driver

:00:09.0 'FastLinQ QL45000 Series 25GbE Controller' drv=igb_uio unused=
:00:0a.0 'FastLinQ QL45000 Series 25GbE Controller' drv=igb_uio unused=

Network devices using kernel driver
===
:00:03.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio



#0 0x004e5392 in vtpci_init (dev=0xb61970, hw=0x7fff76146600)
at /home2/hpatil/dpdk/drivers/net/virtio/virtio_pci.c:653
#1 0x004effc4 in eth_virtio_dev_init (eth_dev=0xacb7a0
)
at /home2/hpatil/dpdk/drivers/net/virtio/virtio_ethdev.c:1060
#2 0x004b730f in rte_eth_dev_init ()
#3 0x004cb940 in pci_probe_all_drivers ()
#4 0x004cbe88 in rte_eal_pci_probe ()
#5 0x004c0336 in rte_eal_init ()
#6 0x004404e2 in main ()
(gdb) p dev->devargs
$1 = (struct rte_devargs *) 0x0


Looks like its a known issue based on a old thread:
http://dpdk.org/dev/patchwork/patch/12462/

Do we know a fix now?

Thanks,
harish

[dpdk-dev] [PATCH] bnx2x: Correctly determine MSIX vector count

2016-06-21 Thread Harish Patil

>
>From: "Charles (Chas) Williams" 
>
>If MSIX is available, the vector count given by the table size is one
>less than the actual count.  This count also limits the receive and
>transmit queue resources the VF can support.
>
>Fixes: 540a211084a7 ("bnx2x: driver core")
>
>Signed-off-by: Chas Williams 
>---
> drivers/net/bnx2x/bnx2x.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
>index 6edb2f9..4be732f 100644
>--- a/drivers/net/bnx2x/bnx2x.c
>+++ b/drivers/net/bnx2x/bnx2x.c
>@@ -9570,8 +9570,10 @@ static int bnx2x_pci_get_caps(struct bnx2x_softc
>*sc)
> static void bnx2x_init_rte(struct bnx2x_softc *sc)
> {
>   if (IS_VF(sc)) {
>-  sc->max_tx_queues = BNX2X_VF_MAX_QUEUES_PER_VF;
>-  sc->max_rx_queues = BNX2X_VF_MAX_QUEUES_PER_VF;
>+  sc->max_tx_queues = min(BNX2X_VF_MAX_QUEUES_PER_VF,
>+  sc->igu_sb_cnt);
>+  sc->max_rx_queues = min(BNX2X_VF_MAX_QUEUES_PER_VF,
>+  sc->igu_sb_cnt);
>   } else {
>   sc->max_tx_queues = 128;
>   sc->max_rx_queues = 128;
>@@ -9713,7 +9715,7 @@ int bnx2x_attach(struct bnx2x_softc *sc)
>   pci_read(sc,
>(sc->devinfo.pcie_msix_cap_reg + PCIR_MSIX_CTRL), ,
>2);
>-  sc->igu_sb_cnt = (val & PCIM_MSIXCTRL_TABLE_SIZE);
>+      sc->igu_sb_cnt = (val & PCIM_MSIXCTRL_TABLE_SIZE) + 1;
>   } else {
>   sc->igu_sb_cnt = 1;
>   }
>-- 
>2.5.5
>
>

Acked-by: Harish Patil

[dpdk-dev] [PATCH] bnx2x: Don't reset buf_len in RX mbufs

2016-06-17 Thread Harish Patil

>
>Fixes: 540a211084a7 ("bnx2x: driver core")
>
>Signed-off-by: Chas Williams <3chas3 at gmail.com>
>---
> drivers/net/bnx2x/bnx2x_rxtx.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c
>b/drivers/net/bnx2x/bnx2x_rxtx.c
>index 55d2bd7..c963194 100644
>--- a/drivers/net/bnx2x/bnx2x_rxtx.c
>+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
>@@ -416,7 +416,6 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf
>**rx_pkts, uint16_t nb_pkts)
>   rx_mb->next = NULL;
>   rx_mb->pkt_len = rx_mb->data_len = len;
>   rx_mb->port = rxq->port_id;
>-  rx_mb->buf_len = len + pad;
>   rte_prefetch1(rte_pktmbuf_mtod(rx_mb, void *));
> 
>   /*
>-- 
>2.5.5
>
>

Acked-by: Harish Patil

[dpdk-dev] [PATCH 2/2] qede: return LAN stats to MFW

2016-06-01 Thread Harish Patil

>

>
>
>> -Original Message-
>> From: Harish Patil [mailto:harish.patil at qlogic.com]
>> Sent: Wednesday, June 1, 2016 3:16 PM
>> To: Thomas Monjalon 
>> Cc: dev at dpdk.org; Richardson, Bruce ; 
>> Rasesh
>> Mody ; Dept-Eng DPDK Dev > EngDPDKDev at qlogic.com>
>> Subject: Re: [dpdk-dev] [PATCH 2/2] qede: return LAN stats to MFW
>> 
>> >
>> >2016-05-31 19:21, Harish Patil:
>> >>
>> >> >On Fri, May 06, 2016 at 09:21:31PM -0700, Rasesh Mody wrote:
>> >> >> From: Harish Patil 
>> >> >>
>> >> >> Under certain scenarios, MFW periodically polls the driver for LAN
>> >> >> statistics. This patch implements the osal hook to fill in the
>> >> >> stats.
>> >> >>
>> >> >> Fixes: ffa002d318d36 ("qede: add base driver")
>> >> >>
>> >> >What is MFW?
>> >> >
>> >> >/Bruce
>> >> >
>> >>
>> >> MFW - Management FirmWare running on the card.
>> >
>> >So MFW can probably be replaced by firmware in the title.
>> >
>> 
>> Reason I didn?t use ?firmware? in the first place is because there are
>>two
>> different firmware running on the card:
>> 1) MFW (management firmware - which is flashed)
>> 2) Firmware (datapath  firmware - loaded by driver by reading FW file)
>> 
>> So, I can replace it as management firmware explicitly.
>> 
>> 
>> Thanks,
>> Harish
>> 
>How about firmware in the title, and then you can clarify it as
>management firmware in the message itself?
>
>Regards,
>/Bruce
>

Sure, will do.

[dpdk-dev] [PATCH 2/2] qede: return LAN stats to MFW

2016-06-01 Thread Harish Patil

>
>2016-05-31 19:21, Harish Patil:
>> 
>> >On Fri, May 06, 2016 at 09:21:31PM -0700, Rasesh Mody wrote:
>> >> From: Harish Patil 
>> >> 
>> >> Under certain scenarios, MFW periodically polls the driver
>> >> for LAN statistics. This patch implements the osal hook to
>> >> fill in the stats.
>> >> 
>> >> Fixes: ffa002d318d36 ("qede: add base driver")
>> >> 
>> >What is MFW?
>> >
>> >/Bruce
>> >
>> 
>> MFW - Management FirmWare running on the card.
>
>So MFW can probably be replaced by firmware in the title.
>

Reason I didn?t use ?firmware? in the first place is because there are two
different firmware running on the card:
1) MFW (management firmware - which is flashed)
2) Firmware (datapath  firmware - loaded by driver by reading FW file)

So, I can replace it as management firmware explicitly.

Thanks,
Harish

[dpdk-dev] [PATCH 2/2] qede: return LAN stats to MFW

2016-05-31 Thread Harish Patil


>On Fri, May 06, 2016 at 09:21:31PM -0700, Rasesh Mody wrote:
>> From: Harish Patil 
>> 
>> Under certain scenarios, MFW periodically polls the driver
>> for LAN statistics. This patch implements the osal hook to
>> fill in the stats.
>> 
>> Fixes: ffa002d318d36 ("qede: add base driver")
>> 
>What is MFW?
>
>/Bruce
>

MFW - Management FirmWare running on the card.

Thanks
Harish

[dpdk-dev] KNI: Need for KNI-Ethtool support

2016-05-28 Thread Harish Patil

Hello,
Could you please let me know what is the use case for having ethtool
support over KNI interfaces? Is it expected to be implemented by poll mode
drivers? PMD APIs pretty much covers all the configuration/status
retrieval needed from the nic, so not sure what is the the benefit of
providing of ethtool support over KNI.
Besides that there is DPDK/ethtool-app which is similar to Ethtool.
Please let know.

Thanks,
Harish

[dpdk-dev] [PATCH] qede: fix 32-bit build with debug enabled

2016-05-19 Thread Harish Patil

PRIx64 " phys] Bulletins"
>+ " [%p virt 0x%" PRIx64 " phys]\n",
>  p_iov_info->mbx_msg_virt_addr,
>  (u64)p_iov_info->mbx_msg_phys_addr,
>  p_iov_info->mbx_reply_virt_addr,
>@@ -1250,7 +1250,7 @@ static void ecore_iov_vf_mbx_acquire(struct
>ecore_hwfn *p_hwfn,
> 
>   DP_VERBOSE(p_hwfn, ECORE_MSG_IOV,
>  "VF[%d] ACQUIRE_RESPONSE: pfdev_info- chip_num=0x%x,"
>- " db_size=%d, idx_per_sb=%d, pf_cap=0x%lx\n"
>+ " db_size=%d, idx_per_sb=%d, pf_cap=0x%" PRIx64 "\n"
>  "resources- n_rxq-%d, n_txq-%d, n_sbs-%d, n_macs-%d,"
>  " n_vlans-%d, n_mcs-%d\n",
>  vf->abs_vf_id, resp->pfdev_info.chip_num,
>diff --git a/drivers/net/qede/base/ecore_vf.c
>b/drivers/net/qede/base/ecore_vf.c
>index 4073aaf..d32fb35 100644
>--- a/drivers/net/qede/base/ecore_vf.c
>+++ b/drivers/net/qede/base/ecore_vf.c
>@@ -325,8 +325,8 @@ enum _ecore_status_t ecore_vf_hw_prepare(struct
>ecore_dev *p_dev)
>   }
> 
>   DP_VERBOSE(p_hwfn, ECORE_MSG_IOV,
>- "VF's Request mailbox [%p virt 0x%lx phys], Response"
>- " mailbox [%p virt 0x%lx phys]\n",
>+ "VF's Request mailbox [%p virt 0x%" PRIx64 " phys], "
>+     "Response mailbox [%p virt 0x%" PRIx64 " phys]\n",
>  p_sriov->vf2pf_request,
>  (u64)p_sriov->vf2pf_request_phys,
>  p_sriov->pf2vf_reply, (u64)p_sriov->pf2vf_reply_phys);
>@@ -339,7 +339,7 @@ enum _ecore_status_t ecore_vf_hw_prepare(struct
>ecore_dev *p_dev)
>  p_sriov->bulletin.
>  size);
>   DP_VERBOSE(p_hwfn, ECORE_MSG_IOV,
>- "VF's bulletin Board [%p virt 0x%lx phys 0x%08x bytes]\n",
>+ "VF's bulletin Board [%p virt 0x%" PRIx64 " phys 0x%08x 
>bytes]\n",
>  p_sriov->bulletin.p_virt, (u64)p_sriov->bulletin.phys,
>  p_sriov->bulletin.size);
> 
>-- 
>2.7.0
>
>

Looks good, thanks.

Acked-by: Harish Patil

[dpdk-dev] [PATCH v4 1/3] bnx2x: refactor Tx routine for single doorbell mechanism

2016-05-11 Thread Harish Patil


>On Tue, May 03, 2016 at 10:38:20PM -0700, Rasesh Mody wrote:
>> Change the Tx routine logic to ring the doorbell once per burst and not
>> on every Tx packet. This driver-level optimization is necessary to
>>achieve
>> line rates for larger frame sizes (1k or more).
>> 
>> Fixes: 540a211084a7 ("bnx2x: driver core")
>> 
>> Signed-off-by: Rasesh Mody 
>> Signed-off-by: Harish Patil 
>
>Hi Rasesh, Harish,
>
>there is quite a bit of churn to the tx_encap routine in this patch, but
>the
>reason for that function change is not really explained well here - why
>it's
>changed from a burst function to a single mbuf function. This is
>confusing when
>the overall objective of the patch seems to be to do the opposite - have
>things
>more burst oriented.
>
>It might be better to have this patch split into two patches - one
>changing the
>tx_encap function and then a second one to restructure the xmit function.
>
>Regards,
>/Bruce
>
>

Hi Bruce,
Sure. We shall have it split into two patches and send it over.

Thanks,
Harish

[dpdk-dev] [PATCH] qede: fix icc build error

2016-05-10 Thread Harish Patil

Hi Ferruh,

>fix errors:
>icc: command line warning #10006: ignoring unknown option
>'-Wno-unused-value'
>icc: command line warning #10006: ignoring unknown option
>'-Wno-format-nonliteral'
>icc: command line warning #10006: ignoring unknown option
>'-Wno-shift-negative-value'
>qede/base/ecore_dev.c(1643): error #188: enumerated type mixed with
>another type
>return 0;
>   ^
>
>Signed-off-by: Ferruh Yigit 
>---
> drivers/net/qede/Makefile | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile
>index 47e01be..d0c1361 100644
>--- a/drivers/net/qede/Makefile
>+++ b/drivers/net/qede/Makefile
>@@ -27,7 +27,6 @@ OS_TYPE := $(shell uname -s)
> # CFLAGS
> #
> CFLAGS_BASE_DRIVER = -Wno-unused-parameter
>-CFLAGS_BASE_DRIVER += -Wno-unused-value
> CFLAGS_BASE_DRIVER += -Wno-sign-compare
> CFLAGS_BASE_DRIVER += -Wno-missing-prototypes
> CFLAGS_BASE_DRIVER += -Wno-cast-qual
>@@ -35,12 +34,16 @@ CFLAGS_BASE_DRIVER += -Wno-unused-function
> CFLAGS_BASE_DRIVER += -Wno-unused-variable
> CFLAGS_BASE_DRIVER += -Wno-strict-aliasing
> CFLAGS_BASE_DRIVER += -Wno-missing-prototypes
>+
>+ifneq ($(CONFIG_RTE_TOOLCHAIN_ICC),y)
>+CFLAGS_BASE_DRIVER += -Wno-unused-value

This change is not for the actual build error but to mask the warning:

icc: command line warning #10006: ignoring unknown option
'-Wno-unused-value?, right?


If so, what about for Wno-format-nonliteral and Wno-shift-negative-value?

> CFLAGS_BASE_DRIVER += -Wno-format-nonliteral
> ifeq ($(OS_TYPE),Linux)
> ifeq ($(shell clang -Wno-shift-negative-value -Werror -E - < /dev/null >
>/dev/null 2>&1; echo $$?),0)
> CFLAGS_BASE_DRIVER += -Wno-shift-negative-value
> endif
> endif
>+endif
> 
> ifneq (,$(filter gcc gcc48,$(CC)))
> CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
>@@ -57,7 +60,7 @@ ifeq ($(shell clang -Wno-pointer-bool-conversion
>-Werror -E - < /dev/null > /dev
> CFLAGS_BASE_DRIVER += -Wno-pointer-bool-conversion
> endif
> else
>-#icc flags
>+CFLAGS_BASE_DRIVER += -wd188 #188: enumerated type mixed with another
>type
> endif
> 
> #
>-- 
>2.5.5
>
>
Looks good. 
I hope its retested against gcc/clang also to make sure the change doesn?t
cause build errors.

Acked-by: Harish Patil

[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build

2016-04-20 Thread Harish Patil


>On Wed, Apr 20, 2016 at 10:51:06AM +0200, Thomas Monjalon wrote:
>> 2016-04-20 00:14, Harish Patil:
>> > >2016-03-31 19:15, Rasesh Mody:
>> > >> --- a/config/common_base
>> > >> +++ b/config/common_base
>> > >> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24
>> > >> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48
>> > >
>> > >It looks to be some tuning which could be done at runtime. Isn't it?
>> >  
>> > That?s right. Can you please suggest if there is any better option to
>>make
>> > it a runtime? There is no PMD API for that.
>> 
>> There are some devargs for that.
>> For PCI dev, it can be passed in the whitelist option.
>> We should remove this limitation by having a devargs API (and command
>>line
>> options) independent of whitelisting.
>
>But back to the original setting. Are these likely to be values that are
>tunable
>or need to be tunable by the user?

> 
This is a tunable which is equivalent of ethtool -c (in linux) which
controls the rate at which status block is updated.

>If not, I see little reason to make them
>run-time configurable - they could be defines inside the driver itself.

There are defines already which set them to the defaults. The reason to
expose it as config option is that the user don?t have to change the
driver and rather just control it via config file. For now, I can remove
it till we find a better alternative to make those run time. Please
confirm and I can have it removed in next patch submission.

>
>/Bruce
>

[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build

2016-04-20 Thread Harish Patil

>
>2016-04-20 00:14, Harish Patil:
>> >2016-03-31 19:15, Rasesh Mody:
>> >> --- a/config/common_base
>> >> +++ b/config/common_base
>> >> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24
>> >> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48
>> >
>> >It looks to be some tuning which could be done at runtime. Isn't it?
>>  
>> That?s right. Can you please suggest if there is any better option to
>>make
>> it a runtime? There is no PMD API for that.
>
>There are some devargs for that.
>For PCI dev, it can be passed in the whitelist option.
>We should remove this limitation by having a devargs API (and command line
>options) independent of whitelisting.
>

Okay. For now, I?m okay to remove this config option till we find a way
(either an API or command line option).

[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build

2016-04-20 Thread Harish Patil

>
>2016-03-31 19:15, Rasesh Mody:
>> --- a/config/common_base
>> +++ b/config/common_base
>> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24
>> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48
>
>It looks to be some tuning which could be done at runtime. Isn't it?

That?s right. Can you please suggest if there is any better option to make
it a runtime? There is no PMD API for that.

>
>> +CONFIG_RTE_LIBRTE_QEDE_TX_SWITCHING=y
>
>Is it possible to enable this feature at runtime?

For now, I can remove this config since it is only applicable for SR-IOV
PF which we don?t have it currently.

>
>> +#Provides path/name of the firmware file
>> +CONFIG_RTE_LIBRTE_QEDE_FW=n
>
>Should we replace n by a string?
>Why not defaults to an empty string?
>
>
Okay, I shall change it.

Thanks,
Harish

[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build

2016-04-20 Thread Harish Patil

>
>2016-03-31 19:15, Rasesh Mody:
>> --- a/scripts/test-build.sh
>> +++ b/scripts/test-build.sh
>> @@ -116,6 +116,7 @@ config () #   
>>  test "$DPDK_DEP_ZLIB" != y || \
>>  sed -ri  's,(BNX2X_PMD=)n,\1y,' $1/.config
>>  sed -ri's,(NFP_PMD=)n,\1y,' $1/.config
>> +sed -ri  's,(QEDE_PMD=)n,\1y,' $1/.config
>
>As QEDE is enabled in common_base, we do not need to add it
>in test-build.sh.
>

Sure.

Thanks,
Harish

[dpdk-dev] [PATCH v5 01/10] qede: Add maintainers

2016-04-18 Thread Harish Patil

>
>2016-03-31 19:15, Rasesh Mody:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -371,6 +371,13 @@ M: Declan Doherty 
>>  F: drivers/crypto/aesni_gcm/
>>  F: doc/guides/cryptodevs/aesni_gcm.rst
>>  
>> +QLogic qede PMD
>> +M: Harish Patil 
>> +M: Rasesh Mody 
>> +M: Sony Chacko 
>> +F: drivers/net/qede/
>> +F: doc/guides/nics/qede.rst
>
>Please keep the logic order by adding qede below bnx2x.
>
>This patch may be merged with documentation (and license).
>

Sure.

Thanks,
Harish

[dpdk-dev] [PATCH v5 00/10] qede: Add qede PMD

2016-04-01 Thread Harish Patil

>
>On Thu, 31 Mar 2016 19:15:17 -0700
>Rasesh Mody  wrote:
>
>> Hi Thomas, Bruce,
>> 
>> The v5 series incorporates the following review comments:
>>  - move adapter_info logs under debug
>>  - implement qede_mac_addr_remove()
>>  - remove unused rc variable in qede_dev_configure()
>>  - fix indentation in qede_dev_info_get()
>>  - use c99 style struct init in qede_config_accept_any_vlan()
>>  - check error in qede_config_rx_mode()
>>  - update overview.rst since patch didn't apply
>> 
>> The patches are generated and tested against latest dpdk based off of
>> v16.04-rc2.
>> 
>> These patches are checked using checkpatch.sh with following additional
>> ignore option:
>>options="$options --ignore=BIT_MACRO,CONCATENATED_STRING"
>> 
>> Please apply!
>
>Looks good.
>
>One question, is there any restriction on number of Tx queues, relative
>to number of Rx queues.  Is it possible to have 8 Tx queues but only 2 Rx
>queues?
>I know bnx2x and some other drivers have that kind of restriction.
>
>Acked-by: Stephen Hemminger 
>
At the outset, thanks for all the review comments.
Yes, currently we only support symmetrical number of queue pairs.
So we have a check in place not to allow unequal no. of RX/TX queues (say
RX=2, TX=8).
We have a work item to address that later. There is no FW/HW restriction.

Thanks,
Harish

[dpdk-dev] [PATCH v4 05/10] qede: Add core driver

2016-03-31 Thread Harish Patil

>

>On Wed, 30 Mar 2016 22:16:51 +
>Harish Patil  wrote:
>
>> >
>> >On Tue, 29 Mar 2016 22:28:20 -0700
>> >Rasesh Mody  wrote:
>> >
>> >> +
>> >> +static void qede_print_adapter_info(struct qede_dev *qdev)
>> >> +{
>> >> + struct ecore_dev *edev = >edev;
>> >> + struct qed_dev_info *info = >dev_info.common;
>> >> + char ver_str[QED_DRV_VER_STR_SIZE] = { 0 };
>> >> +
>> >> + RTE_LOG(INFO, PMD,
>> >> +   " Chip details : %s%d\n",
>> >> +   ECORE_IS_BB(edev) ? "BB" : "AH",
>> >> +   CHIP_REV_IS_A0(edev) ? 0 : 1);
>> >> +
>> >> + sprintf(ver_str, "%s %s_%d.%d.%d.%d", QEDE_PMD_VER_PREFIX,
>> >> + edev->ver_str, QEDE_PMD_VERSION_MAJOR, QEDE_PMD_VERSION_MINOR,
>> >> + QEDE_PMD_VERSION_REVISION, QEDE_PMD_VERSION_PATCH);
>> >> + strcpy(qdev->drv_ver, ver_str);
>> >> + RTE_LOG(INFO, PMD, " Driver version : %s\n", ver_str);
>> >> +
>> >> + ver_str[0] = '\0';
>> >> + sprintf(ver_str, "%d.%d.%d.%d", info->fw_major, info->fw_minor,
>> >> + info->fw_rev, info->fw_eng);
>> >> + RTE_LOG(INFO, PMD, " Firmware version : %s\n", ver_str);
>> >> +
>> >> + ver_str[0] = '\0';
>> >> + sprintf(ver_str, "%d.%d.%d.%d",
>> >> + (info->mfw_rev >> 24) & 0xff,
>> >> + (info->mfw_rev >> 16) & 0xff,
>> >> + (info->mfw_rev >> 8) & 0xff, (info->mfw_rev) & 0xff);
>> >> + RTE_LOG(INFO, PMD, " Management firmware version : %s\n", ver_str);
>> >> +
>> >> + RTE_LOG(INFO, PMD, " Firmware file : %s\n", QEDE_FW_FILE_NAME);
>> >
>> >This means the driver is far too chatty in the logs.
>> >Can't this be made DEBUG level?
>> >
>> Not clear what is the issue here?
>> RTE_LOG is used here to display basic adapter info like firmware/driver
>> versions etc without the need to enable any debug flags.
>> The driver debug logging is under the control of appropriate debug
>>flags.
>> 
>
>The DPDK log messages end up being examined by tech support and customers.
>Too much code puts extra stuff in so it is hard to find the real problem.
>This is obviously debug info, so either:
>  1) make it conditionally compiled
>  2) change log level to DEBUG
>  3) remove it.
>

This is not really a debug msg per se. We want it to be printed on the
stdout unconditionally (displayed only once) so that we can readily know
what firmware/driver/hw versions we are dealing with. We don?t want to
depend on the apps to print those and many of the apps may not do so
including testpmd. Even the linux drivers prints basic stuff  under dmesg.
We have found this to be useful for triage and would like to retain it if
there is no objection.

[dpdk-dev] [PATCH v4 05/10] qede: Add core driver

2016-03-31 Thread Harish Patil

>
>On Tue, 29 Mar 2016 22:28:20 -0700
>Rasesh Mody  wrote:
>
>> +static void
>> +qede_alloc_etherdev(struct qede_dev *qdev, struct qed_dev_eth_info
>>*info)
>> +{
>> +rte_memcpy(>dev_info, info, sizeof(*info));
>
>Why bother with rte_memcpy here? why not just assignment or memcpy()?

Basically, I have tried using rte_* equivalent macros if available.
Would it be a problem?
OR is it that rte_memcpy() is meant to be used only in data path?

>
>> +qdev->num_tc = qdev->dev_info.num_tc;
>> +qdev->ops = qed_ops;
>> +}
>

[dpdk-dev] [PATCH v4 05/10] qede: Add core driver

2016-03-30 Thread Harish Patil

>
>On Tue, 29 Mar 2016 22:28:20 -0700
>Rasesh Mody  wrote:
>
>> +static void
>> +qede_mac_addr_remove(__rte_unused struct rte_eth_dev *eth_dev,
>> + __rte_unused uint32_t index)
>> +{
>> +struct qede_dev *qdev = eth_dev->data->dev_private;
>> +struct ecore_dev *edev = >edev;
>> +
>> +/* TBD: Not implemented currently because DPDK does not provide
>> + * macaddr and instead just passes the index. So pmd needs to
>> + * maintain index mapping to macaddr.
>> + */
>> +DP_NOTICE(edev, false, "%s: Unsupported operation\n", __func__);
>> +}
>> +
>
>Rather than have a stub and break software, why not just
>not define the operation and let base DPDK handle the error?
>
Okay. I shall have it implemented and not leave it as stubbed one.

[dpdk-dev] [PATCH v4 05/10] qede: Add core driver

2016-03-30 Thread Harish Patil

>
>On Tue, 29 Mar 2016 22:28:20 -0700
>Rasesh Mody  wrote:
>
>> +
>> +static void qede_print_adapter_info(struct qede_dev *qdev)
>> +{
>> +struct ecore_dev *edev = >edev;
>> +struct qed_dev_info *info = >dev_info.common;
>> +char ver_str[QED_DRV_VER_STR_SIZE] = { 0 };
>> +
>> +RTE_LOG(INFO, PMD,
>> +  " Chip details : %s%d\n",
>> +  ECORE_IS_BB(edev) ? "BB" : "AH",
>> +  CHIP_REV_IS_A0(edev) ? 0 : 1);
>> +
>> +sprintf(ver_str, "%s %s_%d.%d.%d.%d", QEDE_PMD_VER_PREFIX,
>> +edev->ver_str, QEDE_PMD_VERSION_MAJOR, QEDE_PMD_VERSION_MINOR,
>> +QEDE_PMD_VERSION_REVISION, QEDE_PMD_VERSION_PATCH);
>> +strcpy(qdev->drv_ver, ver_str);
>> +RTE_LOG(INFO, PMD, " Driver version : %s\n", ver_str);
>> +
>> +ver_str[0] = '\0';
>> +sprintf(ver_str, "%d.%d.%d.%d", info->fw_major, info->fw_minor,
>> +info->fw_rev, info->fw_eng);
>> +RTE_LOG(INFO, PMD, " Firmware version : %s\n", ver_str);
>> +
>> +ver_str[0] = '\0';
>> +sprintf(ver_str, "%d.%d.%d.%d",
>> +(info->mfw_rev >> 24) & 0xff,
>> +(info->mfw_rev >> 16) & 0xff,
>> +(info->mfw_rev >> 8) & 0xff, (info->mfw_rev) & 0xff);
>> +RTE_LOG(INFO, PMD, " Management firmware version : %s\n", ver_str);
>> +
>> +RTE_LOG(INFO, PMD, " Firmware file : %s\n", QEDE_FW_FILE_NAME);
>
>This means the driver is far too chatty in the logs.
>Can't this be made DEBUG level?
>
Not clear what is the issue here?
RTE_LOG is used here to display basic adapter info like firmware/driver
versions etc without the need to enable any debug flags.
The driver debug logging is under the control of appropriate debug flags.

[dpdk-dev] Question on examples/multi_process app

2016-03-30 Thread Harish Patil

>>
>>
>>
>>
>>
>>Hi Harish,
>>
>>> >> >
>>> >> >> -Original Message-
>>> >> >> From: Richardson, Bruce
>>> >> >> Sent: Wednesday, March 23, 2016 11:45 AM
>>> >> >> To: Ananyev, Konstantin
>>> >> >> Cc: Harish Patil; dev at dpdk.org
>>> >> >> Subject: Re: [dpdk-dev] Question on examples/multi_process app
>>> >> >>
>>> >> >> On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin
>>>wrote:
>>> >> >> > Hi everyone,
>>> >> >> >
>>> >> >> > > -Original Message-
>>> >> >> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
>>> >> >>Richardson
>>> >> >> > > Sent: Tuesday, March 22, 2016 9:38 PM
>>> >> >> > > To: Harish Patil
>>> >> >> > > Cc: dev at dpdk.org
>>> >> >> > > Subject: Re: [dpdk-dev] Question on examples/multi_process
>>>app
>>> >> >> > >
>>> >> >> > > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
>>> >> >> > > > Hi,
>>> >> >> > > > I have a question regarding symmetric_mp and mp_server
>>> >> >>applications under
>>> >> >> > > > examples/multi_process. In those apps,
>>> >> >>rte_eth_promiscuous_enable() is
>>> >> >> > > > called before rte_eth_dev_start(). Is this the correct way
>>>to
>>> >> >>initialize
>>> >> >> > > > the port/device? As per the description in
>>> >> >> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
>>> >> >> > > >
>>> >> >> > > > "The functions exported by the application Ethernet API to
>>> >>setup
>>> >> >>a device
>>> >> >> > > > designated by its port identifier must be invoked in the
>>> >> >>following order:
>>> >> >> > > >
>>> >> >> > > > * rte_eth_dev_configure()
>>> >> >> > > > * rte_eth_tx_queue_setup()
>>> >> >> > > > * rte_eth_rx_queue_setup()
>>> >> >> > > > * rte_eth_dev_start()
>>> >> >> > > >
>>> >> >> > > > Then, the network application can invoke, in any order, the
>>> >> >>functions
>>> >> >> > > > exported by the Ethernet API to get the MAC address of a
>>>given
>>> >> >>device, to
>>> >> >> > > > get the speed and the status of a device physical link, to
>>> >> >> > > > receive/transmit [burst of] packets, and so on.?
>>> >> >> > > >
>>> >> >> > > > So should I consider this as an application issue or
>>>whether
>>> >>the
>>> >> >>PMD is
>>> >> >> > > > expected to handle it? If PMD is to handle it, then should
>>>the
>>> >> >>PMD be:
>>> >> >> > > >
>>> >> >> > > > 1) Rejecting the Promisc config? OR
>>> >> >> > > > 2) Cache the config and apply when dev_start() is called at
>>> >>later
>>> >> >>point?
>>> >> >> >
>>> >> >> > Yes as I remember 2) is done.
>>> >> >> > dev_start() invokes rte_eth_dev_config_restore(), which
>>>restores
>>> >> >> > promisc mode, mac addresses, etc.
>>> >> >> >
>>> >> >> > > >
>>> >> >> > > > Thanks,
>>> >> >> > > > Harish
>>> >> >> > > >
>>> >> >> > > Good question. I think most/all of the Intel adapters, - for
>>> >>which
>>> >> >>the app was
>>> >> >> > > originally written, way back in the day when there were only
>>>2
>>> >>PMDs
>>> >> >>in DPDK :)
>>> >> >> > > - will handle the promiscuous mode call either before

[dpdk-dev] Question on examples/multi_process app

2016-03-29 Thread Harish Patil

>
>
>
>Hi Harish,
>
>> >> >
>> >> >> -Original Message-
>> >> >> From: Richardson, Bruce
>> >> >> Sent: Wednesday, March 23, 2016 11:45 AM
>> >> >> To: Ananyev, Konstantin
>> >> >> Cc: Harish Patil; dev at dpdk.org
>> >> >> Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> >> >>
>> >> >> On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin
>>wrote:
>> >> >> > Hi everyone,
>> >> >> >
>> >> >> > > -Original Message-
>> >> >> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
>> >> >>Richardson
>> >> >> > > Sent: Tuesday, March 22, 2016 9:38 PM
>> >> >> > > To: Harish Patil
>> >> >> > > Cc: dev at dpdk.org
>> >> >> > > Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> >> >> > >
>> >> >> > > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
>> >> >> > > > Hi,
>> >> >> > > > I have a question regarding symmetric_mp and mp_server
>> >> >>applications under
>> >> >> > > > examples/multi_process. In those apps,
>> >> >>rte_eth_promiscuous_enable() is
>> >> >> > > > called before rte_eth_dev_start(). Is this the correct way
>>to
>> >> >>initialize
>> >> >> > > > the port/device? As per the description in
>> >> >> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
>> >> >> > > >
>> >> >> > > > "The functions exported by the application Ethernet API to
>> >>setup
>> >> >>a device
>> >> >> > > > designated by its port identifier must be invoked in the
>> >> >>following order:
>> >> >> > > >
>> >> >> > > > * rte_eth_dev_configure()
>> >> >> > > > * rte_eth_tx_queue_setup()
>> >> >> > > > * rte_eth_rx_queue_setup()
>> >> >> > > > * rte_eth_dev_start()
>> >> >> > > >
>> >> >> > > > Then, the network application can invoke, in any order, the
>> >> >>functions
>> >> >> > > > exported by the Ethernet API to get the MAC address of a
>>given
>> >> >>device, to
>> >> >> > > > get the speed and the status of a device physical link, to
>> >> >> > > > receive/transmit [burst of] packets, and so on.?
>> >> >> > > >
>> >> >> > > > So should I consider this as an application issue or whether
>> >>the
>> >> >>PMD is
>> >> >> > > > expected to handle it? If PMD is to handle it, then should
>>the
>> >> >>PMD be:
>> >> >> > > >
>> >> >> > > > 1) Rejecting the Promisc config? OR
>> >> >> > > > 2) Cache the config and apply when dev_start() is called at
>> >>later
>> >> >>point?
>> >> >> >
>> >> >> > Yes as I remember 2) is done.
>> >> >> > dev_start() invokes rte_eth_dev_config_restore(), which restores
>> >> >> > promisc mode, mac addresses, etc.
>> >> >> >
>> >> >> > > >
>> >> >> > > > Thanks,
>> >> >> > > > Harish
>> >> >> > > >
>> >> >> > > Good question. I think most/all of the Intel adapters, - for
>> >>which
>> >> >>the app was
>> >> >> > > originally written, way back in the day when there were only 2
>> >>PMDs
>> >> >>in DPDK :)
>> >> >> > > - will handle the promiscuous mode call either before or after
>> >>the
>> >> >>dev start.
>> >> >> > > Assuming that's the case, and if it makes life easier for
>>other
>> >> >>driver writers,
>> >> >> > > we should indeed standardize on one supported way of doing
>> >>things -
>> >> >>the way
>> >> >

[dpdk-dev] Updating bnx2x firmware

2016-03-24 Thread Harish Patil

>
>Guys,
>
> Currently, the bnx2x.c driver looks for the following firmware files
>(when
>PMD is enabled for it):
>
>---
>$ ~/sources/dpdk/dpdk-2.2.0/drivers/net/bnx2x$ grep lib\/firmware *
>bnx2x.c:#define FW_NAME_57711 "/lib/firmware/bnx2x/bnx2x-e1h-7.2.51.0.fw"
>bnx2x.c:#define FW_NAME_57810 "/lib/firmware/bnx2x/bnx2x-e2-7.2.51.0.fw"
>---
>
> Files bnx2x-e1h-7.2.51.0.fw and bnx2x-e2-7.2.51.0.fw.
>
>
> However, on Ubuntu 16.04, the package linux-firmware comes with:
>
>---
>$ dpkg -L linux-firmware | grep -i bnx2x
>/lib/firmware/bnx2x/bnx2x-e1h-7.12.30.0.fw
>/lib/firmware/bnx2x/bnx2x-e1-7.12.30.0.fw
>/lib/firmware/bnx2x/bnx2x-e1-7.13.1.0.fw
>/lib/firmware/bnx2x/bnx2x-e2-7.12.30.0.fw
>/lib/firmware/bnx2x/bnx2x-e1h-7.13.1.0.fw
>/lib/firmware/bnx2x/bnx2x-e2-7.13.1.0.fw
>---
>
>
> Is it okay to just point bnx2x.c to a new version and rebuild it ?
>
> For example: bnx2x-e1h-7.13.1.0.fw and bnx2x-e2-7.13.1.0.fw ?
>
>
> I would prefer to not manually download old firmware from Github:
>
> https://github.com/cernekee/linux-firmware/tree/master/bnx2x
>
>
>Thanks,
>Thiago
>

Hi Thiago
Any reason why you don?t prefer to get the required FW file from other
source?

You can certainly download it from:
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre
e/bnx2x

Any other FW is an untested combination.

Thanks,
Harish

[dpdk-dev] Question on examples/multi_process app

2016-03-24 Thread Harish Patil


>
>
>> >
>> >> -Original Message-
>> >> From: Richardson, Bruce
>> >> Sent: Wednesday, March 23, 2016 11:45 AM
>> >> To: Ananyev, Konstantin
>> >> Cc: Harish Patil; dev at dpdk.org
>> >> Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> >>
>> >> On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin wrote:
>> >> > Hi everyone,
>> >> >
>> >> > > -Original Message-----
>> >> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
>> >>Richardson
>> >> > > Sent: Tuesday, March 22, 2016 9:38 PM
>> >> > > To: Harish Patil
>> >> > > Cc: dev at dpdk.org
>> >> > > Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> >> > >
>> >> > > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
>> >> > > > Hi,
>> >> > > > I have a question regarding symmetric_mp and mp_server
>> >>applications under
>> >> > > > examples/multi_process. In those apps,
>> >>rte_eth_promiscuous_enable() is
>> >> > > > called before rte_eth_dev_start(). Is this the correct way to
>> >>initialize
>> >> > > > the port/device? As per the description in
>> >> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
>> >> > > >
>> >> > > > "The functions exported by the application Ethernet API to
>>setup
>> >>a device
>> >> > > > designated by its port identifier must be invoked in the
>> >>following order:
>> >> > > >
>> >> > > > * rte_eth_dev_configure()
>> >> > > > * rte_eth_tx_queue_setup()
>> >> > > > * rte_eth_rx_queue_setup()
>> >> > > > * rte_eth_dev_start()
>> >> > > >
>> >> > > > Then, the network application can invoke, in any order, the
>> >>functions
>> >> > > > exported by the Ethernet API to get the MAC address of a given
>> >>device, to
>> >> > > > get the speed and the status of a device physical link, to
>> >> > > > receive/transmit [burst of] packets, and so on.?
>> >> > > >
>> >> > > > So should I consider this as an application issue or whether
>>the
>> >>PMD is
>> >> > > > expected to handle it? If PMD is to handle it, then should the
>> >>PMD be:
>> >> > > >
>> >> > > > 1) Rejecting the Promisc config? OR
>> >> > > > 2) Cache the config and apply when dev_start() is called at
>>later
>> >>point?
>> >> >
>> >> > Yes as I remember 2) is done.
>> >> > dev_start() invokes rte_eth_dev_config_restore(), which restores
>> >> > promisc mode, mac addresses, etc.
>> >> >
>> >> > > >
>> >> > > > Thanks,
>> >> > > > Harish
>> >> > > >
>> >> > > Good question. I think most/all of the Intel adapters, - for
>>which
>> >>the app was
>> >> > > originally written, way back in the day when there were only 2
>>PMDs
>> >>in DPDK :)
>> >> > > - will handle the promiscuous mode call either before or after
>>the
>> >>dev start.
>> >> > > Assuming that's the case, and if it makes life easier for other
>> >>driver writers,
>> >> > > we should indeed standardize on one supported way of doing
>>things -
>> >>the way
>> >> > > specified in the documentation being that one way, I would guess.
>> >> > >
>> >> > > So, e1000, ixgbe maintainers - do you see any issues with forcing
>> >>the promiscuous
>> >> > > mode set API to be called after the call to dev_start()?
>> >> >
>> >> > Not sure, why do we need to enforce that restriction?
>> >> > Is there any problem with current way?
>> 
>> Yes, at least with the our driver/firmware interface. The port/device
>> bring-up is carried out in a certain order which requires port config
>>like
>> promisc mode is called after dev_start().
>> 
>> >>
>> >> It complicates things for driver writers is all,
>> >
>> >Not sure how?
>> >All this replay is done at rte_ethdev layer.
>> >Honestly, so far I don't remember any complaint about promisc on/off.
>> >
>> >> and conflicts slightly with
>> >> what is stated in the docs.
>> >
>> >Update the docs? :)
>> 
>> Anyway, please let me know what you guys decide? If the app is changed
>> then nothing needs to done on driver side. Otherwise I have to think of
>> how to handle this.
>> 
>
>So you are saying that for your device if dev_ops->promiscuous_enable()
>is called before dev_ops->dev_start(), it would cause  a problem right?
>Konstantin 
>
>

Yes, with the way it is implemented currently it would pose a problem.
Please note that it can be addressed in the driver, not an issue. However,
I wanted to be sure if the app behavior is correct. Either ways, please
let me know - I can take care of both.

Thanks,
Harish

[dpdk-dev] Question on examples/multi_process app

2016-03-24 Thread Harish Patil

>
>
>
>
>> -Original Message-
>> From: Richardson, Bruce
>> Sent: Wednesday, March 23, 2016 11:45 AM
>> To: Ananyev, Konstantin
>> Cc: Harish Patil; dev at dpdk.org
>> Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> 
>> On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin wrote:
>> > Hi everyone,
>> >
>> > > -Original Message-
>> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
>>Richardson
>> > > Sent: Tuesday, March 22, 2016 9:38 PM
>> > > To: Harish Patil
>> > > Cc: dev at dpdk.org
>> > > Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> > >
>> > > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
>> > > > Hi,
>> > > > I have a question regarding symmetric_mp and mp_server
>>applications under
>> > > > examples/multi_process. In those apps,
>>rte_eth_promiscuous_enable() is
>> > > > called before rte_eth_dev_start(). Is this the correct way to
>>initialize
>> > > > the port/device? As per the description in
>> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
>> > > >
>> > > > "The functions exported by the application Ethernet API to setup
>>a device
>> > > > designated by its port identifier must be invoked in the
>>following order:
>> > > >
>> > > > * rte_eth_dev_configure()
>> > > > * rte_eth_tx_queue_setup()
>> > > > * rte_eth_rx_queue_setup()
>> > > > * rte_eth_dev_start()
>> > > >
>> > > > Then, the network application can invoke, in any order, the
>>functions
>> > > > exported by the Ethernet API to get the MAC address of a given
>>device, to
>> > > > get the speed and the status of a device physical link, to
>> > > > receive/transmit [burst of] packets, and so on.?
>> > > >
>> > > > So should I consider this as an application issue or whether the
>>PMD is
>> > > > expected to handle it? If PMD is to handle it, then should the
>>PMD be:
>> > > >
>> > > > 1) Rejecting the Promisc config? OR
>> > > > 2) Cache the config and apply when dev_start() is called at later
>>point?
>> >
>> > Yes as I remember 2) is done.
>> > dev_start() invokes rte_eth_dev_config_restore(), which restores
>> > promisc mode, mac addresses, etc.
>> >
>> > > >
>> > > > Thanks,
>> > > > Harish
>> > > >
>> > > Good question. I think most/all of the Intel adapters, - for which
>>the app was
>> > > originally written, way back in the day when there were only 2 PMDs
>>in DPDK :)
>> > > - will handle the promiscuous mode call either before or after the
>>dev start.
>> > > Assuming that's the case, and if it makes life easier for other
>>driver writers,
>> > > we should indeed standardize on one supported way of doing things -
>>the way
>> > > specified in the documentation being that one way, I would guess.
>> > >
>> > > So, e1000, ixgbe maintainers - do you see any issues with forcing
>>the promiscuous
>> > > mode set API to be called after the call to dev_start()?
>> >
>> > Not sure, why do we need to enforce that restriction?
>> > Is there any problem with current way?

Yes, at least with the our driver/firmware interface. The port/device
bring-up is carried out in a certain order which requires port config like
promisc mode is called after dev_start().

>> 
>> It complicates things for driver writers is all,
>
>Not sure how?
>All this replay is done at rte_ethdev layer.
>Honestly, so far I don't remember any complaint about promisc on/off.
>
>> and conflicts slightly with
>> what is stated in the docs.
>
>Update the docs? :)

Anyway, please let me know what you guys decide? If the app is changed
then nothing needs to done on driver side. Otherwise I have to think of
how to handle this.

>
>> 
>> /Bruce
>

[dpdk-dev] Question on examples/multi_process app

2016-03-22 Thread Harish Patil

Hi,
I have a question regarding symmetric_mp and mp_server applications under
examples/multi_process. In those apps, rte_eth_promiscuous_enable() is
called before rte_eth_dev_start(). Is this the correct way to initialize
the port/device? As per the description in
http://dpdk.org/doc/api/rte__ethdev_8h.html:

"The functions exported by the application Ethernet API to setup a device
designated by its port identifier must be invoked in the following order:

* rte_eth_dev_configure()
* rte_eth_tx_queue_setup()
* rte_eth_rx_queue_setup()
* rte_eth_dev_start()

Then, the network application can invoke, in any order, the functions
exported by the Ethernet API to get the MAC address of a given device, to
get the speed and the status of a device physical link, to
receive/transmit [burst of] packets, and so on.?

So should I consider this as an application issue or whether the PMD is
expected to handle it? If PMD is to handle it, then should the PMD be:

1) Rejecting the Promisc config? OR
2) Cache the config and apply when dev_start() is called at later point?

Thanks,
Harish

[dpdk-dev] [PATCH 0/6] DPDK PMD for new QLogic FastLinQ QL4xxxx 25G/40G CNAs

2016-03-10 Thread Harish Patil

>>
>>
>>
>>On Sat, Feb 20, 2016 at 07:40:25AM -0800, Harish Patil wrote:
>>> This patch set introduces DPDK poll mode driver for new QLogic FastLinQ
>>>QL4
>>> 25G/40G capable family of CNAs as well as their SR-IOV Virtual
>>>Functions (VF).
>>> 
>>> The overall PMD driver design includes a common module called ecore
>>>that deals
>>> with the low level HW and a upper layer portion that provides the glue
>>>logic.
>>> 
>>> Specifically, the ecore module contains all of the common logic,
>>> e.g. initialization, cleanup, infrastructure for interrupt handling,
>>>link
>>> management, slowpath etc. as well as protocol agnostic features and
>>>supplying
>>> an abstraction layer for other modules.
>>> 
>>> The higher layer implements DPDK exported APIs/driver entry points by
>>> interfacing with the common module for configuration/status and also
>>>the
>>> fastpath routines.
>>> 
>>> Included in the patch set is the supporting documentation and
>>>maintainers.
>>> 
>>> Please apply.
>>> 
>>> Thanks,
>>> 
>>> Harish Patil (6):
>>>   qede: add maintainers
>>>   qede: add documentation
>>>   qede: add QLogic PCI ids
>>>   qede: add driver common module
>>>   qede: add driver
>>>   qede: enable PMD build
>>Hi Harish,
>>
>>there are quite a few comments to be addressed on this patchset. Are
>>there plans
>>for a V2 in time for the code freeze deadline later this week?
>>
>>  /Bruce
>>
>>
>
>Hi Bruce,
>Yes we are working on V2 series with the comments addressed. Will send out
>the patches soon.
>Thanks,
>Harish
>
>

Hi Bruce
FYI - We have submitted v2 patch series after incorporating all review
comments.

Thanks,
Harish

[dpdk-dev] [PATCH v2 02/10] qede: add documentation

2016-03-10 Thread Harish Patil

>
>2016-03-10 05:45, Rasesh Mody:
>>  doc/guides/nics/index.rst |1 +
>>  doc/guides/nics/qede.rst  |  340
>>+
>>  2 files changed, 341 insertions(+)
>
>It would be nice to see a new column in the matrix of overview.rst.
>

Hi Thomas,
Yes, we had updated overview.rst with two new columns, but missed this
file while submitting patches.
Will send a follow-on patch.

Thanks,
Harish

[dpdk-dev] [PATCH 0/6] DPDK PMD for new QLogic FastLinQ QL4xxxx 25G/40G CNAs

2016-03-08 Thread Harish Patil

>
>On Sat, Feb 20, 2016 at 07:40:25AM -0800, Harish Patil wrote:
>> This patch set introduces DPDK poll mode driver for new QLogic FastLinQ
>>QL4
>> 25G/40G capable family of CNAs as well as their SR-IOV Virtual
>>Functions (VF).
>> 
>> The overall PMD driver design includes a common module called ecore
>>that deals
>> with the low level HW and a upper layer portion that provides the glue
>>logic.
>> 
>> Specifically, the ecore module contains all of the common logic,
>> e.g. initialization, cleanup, infrastructure for interrupt handling,
>>link
>> management, slowpath etc. as well as protocol agnostic features and
>>supplying
>> an abstraction layer for other modules.
>> 
>> The higher layer implements DPDK exported APIs/driver entry points by
>> interfacing with the common module for configuration/status and also the
>> fastpath routines.
>> 
>> Included in the patch set is the supporting documentation and
>>maintainers.
>> 
>> Please apply.
>> 
>> Thanks,
>> 
>> Harish Patil (6):
>>   qede: add maintainers
>>   qede: add documentation
>>   qede: add QLogic PCI ids
>>   qede: add driver common module
>>   qede: add driver
>>   qede: enable PMD build
>Hi Harish,
>
>there are quite a few comments to be addressed on this patchset. Are
>there plans
>for a V2 in time for the code freeze deadline later this week?
>
>   /Bruce
>
>

Hi Bruce,
Yes we are working on V2 series with the comments addressed. Will send out
the patches soon.
Thanks,
Harish

[dpdk-dev] [PATCH 2/6] qede: add documentation

2016-02-24 Thread Harish Patil

>>
>>-Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harish Patil
>> Sent: Saturday, February 20, 2016 3:40 PM
>> To: dev at dpdk.org
>> Cc: Sony Chacko 
>> Subject: [dpdk-dev] [PATCH 2/6] qede: add documentation
>> 
>> Signed-off-by: Harish Patil 
>> Signed-off-by: Rasesh Mody 
>> Signed-off-by: Sony Chacko 
>> ---
>>  doc/guides/nics/index.rst |   1 +
>>  doc/guides/nics/qede.rst  | 344
>
>Hi,
>
>Thanks for the docs. The overall format and content seem good. A few
>comments below.
>
>
>> +#. Bind the QLogic 579xx adapters to ``igb_uio`` or ``vfio-pci`` loaded
>> in the
>> +   previous step::
>> +
>> +  ./tools/dpdk_nic_bind.py --bind igb_uio :84:00.0 :84:00.1
>> + :84:00.2 :84:00.3
>
>Fixed width lines should be constrained to 80 characters or else they will
>go off the page in the PDF docs. The usual workaround is to use a command-
>line continuation (or text wrap). For example:
>
>
> ./tools/dpdk_nic_bind.py --bind igb_uio \
>  :84:00.0 :84:00.1 \
>  :84:00.2 :84:00.3
>
>Or similar. This also applies to the command-lines in other sections.
>> +
>> +#. Start ``testpmd`` with basic parameters:
>> +
>> +   .. code-block:: console
>> +
>> +  testpmd -c 0xf8000 -n 4 -- -i --nb-cores=4 --portmask=0xf
>> + --rxd=4096 --txd=4096 --txfreet=4068 --rxq=2 --txq=2 --rss-ip
>> + --rss-udp
>
>Same comment about using continuations.
>
>
>> +
>> +  [...]
>> +
>> +EAL: PCI device :84:00.0 on NUMA socket 1
>> +EAL:   probe driver: 1077:1634 rte_qede_pmd
>
>Align the text in this section to the same level of indentation.
>
>
>> +EAL:   Not managed by a supported kernel driver, skipped
>> +EAL: PCI device :84:00.1 on NUMA socket 1
>> +EAL:   probe driver: 1077:1634 rte_qede_pmd
>> +EAL:   Not managed by a supported kernel driver, skipped
>> +EAL: PCI device :88:00.0 on NUMA socket 1
>> +EAL:   probe driver: 1077:1656 rte_qede_pmd
>> +EAL:   PCI memory mapped at 0x7f738b20
>> +EAL:   PCI memory mapped at 0x7f738b28
>> +EAL:   PCI memory mapped at 0x7f738b30
>> +[QEDE PMD: (88:00.0:dpdk-port-0)]qed_load_firmware_data: Loading
>>the
>> firmware file /lib/firmware/qed/qed_init_values_zipped.bin...
>
>Again, try wrap the code/console section at 80 chars in some way that
>still
>maintains the meaning. Maybe something like the following (with a note to
>say that the text has been wrapped for clarity):
>
>[QEDE PMD: (88:00.0:dpdk-port-0)]qed_load_firmware_data:
>   Loading the firmware file
>   /lib/firmware/qed/qed_init_values_zipped.bin...
>[QEDE PMD: (88:00.0:dpdk-port-0)]
>   qede_print_adapter_info:Chip details - BB1
>[QEDE PMD: (88:00.0:dpdk-port-0)]
>   qede_print_adapter_info:Driver version:QEDE PMD
>8.7.9.0_1.0.0
>[QEDE PMD: (88:00.0:dpdk-port-0)]
>   qede_print_adapter_info:Firmware version:8.7.7.0
>
>
>You can test the PDF output as follows:
>
>make -j doc-guides-pdf
>pdf_veiwer build/doc/pdf/guides/nics.pdf
>
>John
>

These are the actual output from the console that was pasted, that?s why
they are more than 80 chars.
Sure, will take care of that as you mentioned.


Thanks,
Harish

[dpdk-dev] [PATCH 4/6] qede: add driver common module

2016-02-23 Thread Harish Patil

>
>On Sat, 20 Feb 2016 07:58:31 -0800
> wrote:
>
>> +unsigned long log2_align(unsigned long n)
>> +{
>
>Common code is good, but you need to practice good function name
>hygiene on public functions to avoid any namespace clashes when
>using static linking.
>
>The application might define a function with log2_align.
>Either make the functions static, or use a common prefix for all qede
>internal functions.
>

Sure. Will fix those

[dpdk-dev] [PATCH 5/6] qede: add driver

2016-02-23 Thread Harish Patil

>>
>>
>>
>>On Tue, 23 Feb 2016 02:28:25 +
>>Harish Patil  wrote:
>>
>>> All of the checkpatch warnings had been fixed  (except one which cannot
>>>be
>>> fixed) using the checkpatch script available under DPDK scripts/
>>> directory. The linux checkpatch version is 0.32.
>>> 
>>> [root at dut4019 dpdk]# ./scripts/checkpatches.sh patches-send/*.patch
>>> 
>>> ### patches-send/0004-qede-add-driver-common-module.patch
>>> 
>>> WARNING:CAMELCASE: Avoid CamelCase: 
>>> #251: FILE: drivers/net/qede/ecore/bcm_osal.c:120:
>>> +   inflateEnd(p_hwfn->stream);
>>> 
>>> total: 0 errors, 1 warnings, 54467 lines checked
>>> 
>>> Wouldn?t that suffice?
>>
>>Maybe your version of checkpatch from kernel is older than more recent
>>version I am using (from Linux 4.4).
>>
>I had used checkpatch version 0.32 as mentioned above.
>The latest checkpatch version in net-next also shows 0.32.
>my $V = '0.32?;
>
>I see similar checkpatch related conversations going on in other threads
>in the distribution.
>Please advise.
>+Thomas
>
>Thanks,
>Harish 
>
>
>
+Thomas

[dpdk-dev] [PATCH 5/6] qede: add driver

2016-02-23 Thread Harish Patil

>
>On Tue, 23 Feb 2016 02:28:25 +
>Harish Patil  wrote:
>
>> All of the checkpatch warnings had been fixed  (except one which cannot
>>be
>> fixed) using the checkpatch script available under DPDK scripts/
>> directory. The linux checkpatch version is 0.32.
>> 
>> [root at dut4019 dpdk]# ./scripts/checkpatches.sh patches-send/*.patch
>> 
>> ### patches-send/0004-qede-add-driver-common-module.patch
>> 
>> WARNING:CAMELCASE: Avoid CamelCase: 
>> #251: FILE: drivers/net/qede/ecore/bcm_osal.c:120:
>> +   inflateEnd(p_hwfn->stream);
>> 
>> total: 0 errors, 1 warnings, 54467 lines checked
>> 
>> Wouldn?t that suffice?
>
>Maybe your version of checkpatch from kernel is older than more recent
>version I am using (from Linux 4.4).
>
I had used checkpatch version 0.32 as mentioned above.
The latest checkpatch version in net-next also shows 0.32.
my $V = '0.32?;

I see similar checkpatch related conversations going on in other threads
in the distribution.
Please advise.
+Thomas

Thanks,
Harish

[dpdk-dev] [PATCH 0/6] DPDK PMD for new QLogic FastLinQ QL4xxxx 25G/40G CNAs

2016-02-23 Thread Harish Patil

>
>2016-02-22 16:47, Harish Patil:
>> >Please could you share some performance numbers?
>> 
>> We have measured ~68 MPPS @ 64B with zero drop for the 4x25G adapter
>> running bi-di RFC traffic.
>
>How many queues/cores to achieve this performance?
Using single queue/core per port. Eg:  Running L2FWD application in the
4x25G configuration shall use 4 cores with single queue pair per port.

>
>> >What is the status about the integration of this driver in other
>> >environments?
>> 
>> Not very sure what you mean here. If you are asking about linux, then
>> qede/qed kernel drivers are part of kernel.org.
>> If its about BSD then we have compile tested the current poll mode
>>driver
>> under FreeBSD (64 bit).
>
>OK, so the base driver is shared only between Linux and DPDK?
>Nothing in BSD kernels?
BSD driver also uses the common base code.

>
>> By the way, the patch 4/6 is still held up (not posted) due to size
>> restrictions.
>> Could you please allow it to be posted?
>
>It was posted but curiously out of the thread:
>   http://dpdk.org/ml/archives/dev/2016-February/033612.html

Ok thanks
>
>> 
>> 
>> This message and any attached documents contain information from the
>>sending company or its parent company(s), subsidiaries, divisions or
>>branch offices that may be confidential. If you are not the intended
>>recipient, you may not read, copy, distribute, or use this information.
>>If you have received this transmission in error, please notify the
>>sender immediately by reply e-mail and then delete this message.
>
>Please avoid this message --^
>
I have got it fixed at the exchange level. Hopefully should be fixed with
this email onwards.

[dpdk-dev] [PATCH 0/6] DPDK PMD for new QLogic FastLinQ QL4xxxx 25G/40G CNAs

2016-02-22 Thread Harish Patil

>
>2016-02-20 07:40, Harish Patil:
>> This patch set introduces DPDK poll mode driver for new QLogic FastLinQ
>>QL4
>> 25G/40G capable family of CNAs as well as their SR-IOV Virtual
>>Functions (VF).
>>
>> The overall PMD driver design includes a common module called ecore
>>that deals
>> with the low level HW and a upper layer portion that provides the glue
>>logic.
>>
>> Specifically, the ecore module contains all of the common logic,
>> e.g. initialization, cleanup, infrastructure for interrupt handling,
>>link
>> management, slowpath etc. as well as protocol agnostic features and
>>supplying
>> an abstraction layer for other modules.
>>
>> The higher layer implements DPDK exported APIs/driver entry points by
>> interfacing with the common module for configuration/status and also the
>> fastpath routines.
>
>A new driver is always a good news :)

Thank you!

>Please could you share some performance numbers?

We have measured ~68 MPPS @ 64B with zero drop for the 4x25G adapter
running bi-di RFC traffic.


>
>What is the status about the integration of this driver in other
>environments?

Not very sure what you mean here. If you are asking about linux, then
qede/qed kernel drivers are part of kernel.org.
If its about BSD then we have compile tested the current poll mode driver
under FreeBSD (64 bit).


>
>The layer named ecore seems to be what is named a base driver in other
>DPDK drivers. Maybe you could consider renaming the directory to base/ for
>consistency?

Sure

>
>About the format of the patches, I think it's better to split driver
>imports
>in several pieces to ease reviewing and later reference for specific bugs.
>What do you think of introducing basic features one by one?
>

I don?t know how easy its going to be to split the driver on a feature by
feature basis.
Some of them could be coupled/dependent on other sections of the L2 code.
But yes, we shall think thru? this and get back to you.
By the way, the patch 4/6 is still held up (not posted) due to size
restrictions.
Could you please allow it to be posted?

Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 6/6] qede: enable PMD build

2016-02-20 Thread Harish Patil

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 config/common_bsdapp   | 15 +++
 config/common_linuxapp | 16 
 drivers/net/Makefile   |  1 +
 mk/rte.app.mk  |  2 ++
 scripts/test-build.sh  |  1 +
 5 files changed, 35 insertions(+)

diff --git a/config/common_bsdapp b/config/common_bsdapp
index 696382c..b1a6f38 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -295,6 +295,21 @@ CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
 CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n

 #
+# QLogic 25G/40G PMD
+#
+CONFIG_RTE_LIBRTE_QEDE_PMD=y
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_ECORE=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24
+CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48
+CONFIG_RTE_LIBRTE_QEDE_TX_SWITCHING=y
+#Provides path/name of the firmware file
+CONFIG_RTE_LIBRTE_QEDE_FW=n
+
+#
 # Compile null PMD
 #
 CONFIG_RTE_LIBRTE_PMD_NULL=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index f1638db..52e966c 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -308,6 +308,22 @@ CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 #
 CONFIG_RTE_LIBRTE_PMD_XENVIRT=n

+
+#
+# QLogic 25G/40G PMD
+#
+CONFIG_RTE_LIBRTE_QEDE_PMD=y
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_ECORE=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24
+CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48
+CONFIG_RTE_LIBRTE_QEDE_TX_SWITCHING=y
+#Provides path/name of the firmware file
+CONFIG_RTE_LIBRTE_QEDE_FW=n
+
 #
 # Compile null PMD
 #
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6e4497e..fd10734 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,6 +51,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += szedata2
 DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
 DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+DIRS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede

 include $(RTE_SDK)/mk/rte.sharelib.mk
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 8ecab41..bebb06e 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -109,6 +109,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD)   += -libverbs
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2)   += -lsze2
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT)+= -lxenstore
 _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD)  += -lgxio
+_LDLIBS-$(CONFIG_RTE_LIBRTE_QEDE_PMD)   += -lz
 # QAT PMD has a dependency on libcrypto (from openssl) for calculating HMAC 
precomputes
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lcrypto
 endif # CONFIG_RTE_BUILD_COMBINE_LIBS or not CONFIG_RTE_BUILD_SHARED_LIBS
@@ -152,6 +153,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD)  += 
-lrte_pmd_mpipe
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING)   += -lrte_pmd_ring
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP)   += -lrte_pmd_pcap
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET)  += -lrte_pmd_af_packet
+_LDLIBS-$(CONFIG_RTE_LIBRTE_QEDE_PMD)   += -lrte_pmd_qede
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NULL)   += -lrte_pmd_null
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lrte_pmd_qat

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index 6d28c5d..dfdc190 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -118,6 +118,7 @@ config () #   
test "$DPDK_DEP_ZLIB" != y || \
sed -ri  's,(BNX2X_PMD=)n,\1y,' $1/.config
sed -ri's,(NFP_PMD=)n,\1y,' $1/.config
+   sed -ri  's,(QEDE_PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_PCAP" != y || \
sed -ri   's,(PCAP=)n,\1y,' $1/.config
test -z "$AESNI_MULTI_BUFFER_LIB_PATH" || \
-- 
1.8.3.1

[dpdk-dev] [PATCH 5/6] qede: add driver

2016-02-20 Thread Harish Patil

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 drivers/net/qede/LICENSE.qede_pmd |   28 +
 drivers/net/qede/Makefile |   95 ++
 drivers/net/qede/qede_eth_if.c|  461 ++
 drivers/net/qede/qede_eth_if.h|  180 
 drivers/net/qede/qede_ethdev.c|  815 +
 drivers/net/qede/qede_ethdev.h|  138 +++
 drivers/net/qede/qede_if.h|  167 
 drivers/net/qede/qede_logs.h  |   93 ++
 drivers/net/qede/qede_main.c  |  587 +
 drivers/net/qede/qede_rxtx.c  | 1346 +
 drivers/net/qede/qede_rxtx.h  |  183 
 drivers/net/qede/rte_pmd_qede_version.map |4 +
 12 files changed, 4097 insertions(+)
 create mode 100644 drivers/net/qede/LICENSE.qede_pmd
 create mode 100644 drivers/net/qede/Makefile
 create mode 100644 drivers/net/qede/qede_eth_if.c
 create mode 100644 drivers/net/qede/qede_eth_if.h
 create mode 100644 drivers/net/qede/qede_ethdev.c
 create mode 100644 drivers/net/qede/qede_ethdev.h
 create mode 100644 drivers/net/qede/qede_if.h
 create mode 100644 drivers/net/qede/qede_logs.h
 create mode 100644 drivers/net/qede/qede_main.c
 create mode 100644 drivers/net/qede/qede_rxtx.c
 create mode 100644 drivers/net/qede/qede_rxtx.h
 create mode 100644 drivers/net/qede/rte_pmd_qede_version.map

diff --git a/drivers/net/qede/LICENSE.qede_pmd 
b/drivers/net/qede/LICENSE.qede_pmd
new file mode 100644
index 000..c7cbdcc
--- /dev/null
+++ b/drivers/net/qede/LICENSE.qede_pmd
@@ -0,0 +1,28 @@
+/*
+ * BSD LICENSE
+ *
+ * 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. 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.
+ * 3. Neither the name of QLogic Corporation nor the name of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written consent.
+ *
+ * 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.
+ */
diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile
new file mode 100644
index 000..a62d80e
--- /dev/null
+++ b/drivers/net/qede/Makefile
@@ -0,0 +1,95 @@
+#Copyright (c) 2016 QLogic Corporation.
+#All rights reserved.
+#www.qlogic.com
+#
+#See LICENSE.qede_pmd for copyright and licensing details.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_qede.a
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+EXPORT_MAP := rte_pmd_qede_version.map
+
+LIBABIVER := 1
+
+#
+#OS
+#
+OS_TYPE := $(shell uname -s)
+
+#
+# CFLAGS
+#
+CFLAGS_ECORE_DRIVER = -Wno-unused-parameter
+CFLAGS_ECORE_DRIVER += -Wno-unused-value
+CFLAGS_ECORE_DRIVER += -Wno-sign-compare
+CFLAGS_ECORE_DRIVER += -Wno-missing-prototypes
+CFLAGS_ECORE_DRIVER += -Wno-cast-qual
+CFLAGS_ECORE_DRIVER += -Wno-unused-function
+CFLAGS_ECORE_DRIVER += -Wno-unused-variable
+CFLAGS_ECORE_DRIVER += -Wno-strict-aliasing
+CFLAGS_ECORE_DRIVER += -Wno-missing-prototypes
+CFLAGS_ECORE_DRIVER += -Wno-format-nonliteral
+ifeq ($(OS_TYPE),Linux)
+CFLAGS_ECORE_DRIVER += -Wno-shift-negative-value
+endif
+
+ifneq (,$(filter gcc gcc48,$(CC)))
+CFLAGS_ECORE_DRIVER += -Wno-unused-but-set-variable
+CFLAGS_ECORE_DRIVER += -Wno-missing-declarations
+CFLAGS_ECORE_DRIVER += -Wno-maybe-uninitialized
+CFLAGS_ECORE_DRIVER += -Wno-strict-prototypes
+else ifeq ($(CC), clang)
+CFLAGS_ECORE_DRIVER += -Wno-format-extra-args
+CFLAGS_ECORE_DRIVER += -Wno-visibility
+CFLAGS_ECORE_DRIVER += -Wno-empty-body
+CFLAGS_ECORE_DRIVER += -Wno-invalid-source-encoding
+CFLAGS_ECORE_DRIVER += -Wno-sometimes-uninitialized
+CFLAGS_ECORE_DRIVER += -Wno-pointer-bool-conversion
+else
+#icc flags
+endif
+
+#
+# Add extra flags for base ecore driver files
+# to disable warnings in them
+#
+#
+ECORE_DRIVER

[dpdk-dev] [PATCH 3/6] qede: add QLogic PCI ids

2016-02-20 Thread Harish Patil

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 lib/librte_eal/common/include/rte_pci_dev_ids.h | 44 +
 1 file changed, 44 insertions(+)

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 d088191..0c1a3fe 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -152,6 +152,14 @@
 #define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
 #endif

+#ifndef RTE_PCI_DEV_ID_DECL_QEDE
+#define RTE_PCI_DEV_ID_DECL_QEDE(vend, dev)
+#endif
+
+#ifndef RTE_PCI_DEV_ID_DECL_QEDEVF
+#define RTE_PCI_DEV_ID_DECL_QEDEVF(vend, dev)
+#endif
+
 #ifndef PCI_VENDOR_ID_INTEL
 /** Vendor ID used by Intel devices */
 #define PCI_VENDOR_ID_INTEL 0x8086
@@ -177,6 +185,11 @@
 #define PCI_VENDOR_ID_BROADCOM 0x14E4
 #endif

+#ifndef PCI_VENDOR_ID_QLOGIC
+/** Vendor ID used by QLogic devices */
+#define PCI_VENDOR_ID_QLOGIC 0x1077
+#endif
+
 / Physical EM devices from e1000_hw.h /

 #define E1000_DEV_ID_825420x1000
@@ -651,6 +664,35 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, 
BNX2X_DEV_ID_57811_MF)
 RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57840_MF)
 #endif

+/** QLogic 25G/40G devices  **/
+#define CHIP_NUM_57980E 0x1634
+#define CHIP_NUM_57980S 0x1629
+#define CHIP_NUM_VF 0x1630
+#define CHIP_NUM_57980S_40  0x1634
+#define CHIP_NUM_57980S_VF  0x1637 /* will change to 1664 */
+#define CHIP_NUM_57980S_25  0x1656
+#define CHIP_NUM_57980S_IOV 0x1664
+#define CHIP_NUM_AH 0x8070
+
+#ifndef PCI_DEVICE_ID_NX2_57980E
+#define PCI_DEVICE_ID_NX2_57980ECHIP_NUM_57980E
+#define PCI_DEVICE_ID_NX2_57980SCHIP_NUM_57980S
+#define PCI_DEVICE_ID_NX2_VFCHIP_NUM_VF
+#define PCI_DEVICE_ID_57980S_40 CHIP_NUM_57980S_40
+#define PCI_DEVICE_ID_57980S_VF CHIP_NUM_57980S_VF
+#define PCI_DEVICE_ID_57980S_25 CHIP_NUM_57980S_25
+#define PCI_DEVICE_ID_57980S_IOVCHIP_NUM_57980S_IOV
+#define PCI_DEVICE_ID_AHCHIP_NUM_AH
+#endif
+
+RTE_PCI_DEV_ID_DECL_QEDE(PCI_VENDOR_ID_QLOGIC, PCI_DEVICE_ID_NX2_57980E)
+RTE_PCI_DEV_ID_DECL_QEDE(PCI_VENDOR_ID_QLOGIC, PCI_DEVICE_ID_NX2_57980S)
+RTE_PCI_DEV_ID_DECL_QEDE(PCI_VENDOR_ID_QLOGIC, PCI_DEVICE_ID_57980S_40)
+RTE_PCI_DEV_ID_DECL_QEDE(PCI_VENDOR_ID_QLOGIC, PCI_DEVICE_ID_57980S_25)
+RTE_PCI_DEV_ID_DECL_QEDEVF(PCI_VENDOR_ID_QLOGIC, PCI_DEVICE_ID_NX2_VF)
+RTE_PCI_DEV_ID_DECL_QEDEVF(PCI_VENDOR_ID_QLOGIC, PCI_DEVICE_ID_57980S_VF)
+RTE_PCI_DEV_ID_DECL_QEDEVF(PCI_VENDOR_ID_QLOGIC, PCI_DEVICE_ID_57980S_IOV)
+
 /*
  * Undef all RTE_PCI_DEV_ID_DECL_* here.
  */
@@ -667,3 +709,5 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, 
BNX2X_DEV_ID_57840_MF)
 #undef RTE_PCI_DEV_ID_DECL_VMXNET3
 #undef RTE_PCI_DEV_ID_DECL_FM10K
 #undef RTE_PCI_DEV_ID_DECL_FM10KVF
+#undef RTE_PCI_DEV_ID_DECL_QEDE
+#undef RTE_PCI_DEV_ID_DECL_QEDEVF
-- 
1.8.3.1

[dpdk-dev] [PATCH 2/6] qede: add documentation

2016-02-20 Thread Harish Patil

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 doc/guides/nics/index.rst |   1 +
 doc/guides/nics/qede.rst  | 344 ++
 2 files changed, 345 insertions(+)
 create mode 100644 doc/guides/nics/qede.rst

diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 8618114..f092f75 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -50,6 +50,7 @@ Network Interface Controller Drivers
 virtio
 vmxnet3
 pcap_ring
+qede

 **Figures**

diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
new file mode 100644
index 000..de4fecd
--- /dev/null
+++ b/doc/guides/nics/qede.rst
@@ -0,0 +1,344 @@
+..  BSD LICENSE
+Copyright (c) 2016 QLogic Corporation
+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 QLogic 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.
+
+QEDE Poll Mode Driver
+==
+
+The QEDE poll mode driver library (**librte_pmd_qede**) implements support
+for **QLogic FastLinQ QL4 25G/40G CNA** family of adapters as well
+as their virtual functions (VF) in SR-IOV context. It is supported on
+several standard Linux distros like RHEL7.x and SLES12.x OS.
+It is compile-tested under FreeBSD OS.
+
+More information can be found at `QLogic Corporation's Official Website
+<http://www.qlogic.com>`_.
+
+Supported Features
+--
+
+- Unicast/multicast/VLAN filtering
+- Promiscuous mode
+- Allmulti mode
+- Port hardware statistics
+- Jumbo frames (using single buffer)
+- VLAN tag insertion/removal
+- Stateless checksum offloads (IPv4/TCP/UDP)
+- Multiple Rx/Tx queues (queue-pairs)
+- RSS (with default table/key)
+- TSS
+- Multiple MAC address
+- Default pause flow control
+- SR-IOV VF
+
+Non-supported Features
+--
+
+- Scatter-Gather Rx/Tx frames
+- User configurable RETA table/key
+- Unequal number of Rx/Tx queues
+- MTU change (dynamic)
+- SR-IOV PF
+- Tunneling offloads
+
+Supported QLogic NICs
+-
+
+- QLogic FastLinQ QL4 25G/40G CNAs
+
+Prerequisites
+-
+
+- Requires storm firmware version **8.7.x.** and management
+  firmware version **8.7.x and higher**. Storm firmware may be available
+  under /usr/lib/firmware/qed/ in certain newer Linux
+  distributions (e.g. qed_init_values_zipped-8.7.8.0.bin).
+
+- If the required firmware files are not available then visit
+  `QLogic Driver Download Center <http://driverdownloads.qlogic.com>`
+
+- This driver relies on external zlib library (-lz) for uncompressing
+  the firmware file.
+
+Config File Options
+~~~
+
+The following options can be modified in the ``.config`` file. Please note that
+enabling debugging options may affect system performance.
+
+- ``CONFIG_RTE_LIBRTE_QEDE_PMD`` (default **y**)
+
+  Toggle compilation of QEDE PMD driver.
+
+- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO`` (default **n**)
+
+  Toggle display of generic debugging messages.
+
+- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_ECORE`` (default **n**)
+
+  Toggle display of ecore related messages.
+
+- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX`` (default **n**)
+
+  Toggle display of transmit fast path run-time messages.
+
+- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX`` (default **n**)
+
+  Toggle display of receive fast path run-time messages.
+
+- ``CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US`` (default **24**)
+
+  Change Rx interrupt coalescing timer (in us).
+
+- ``CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US`` (default **48**)
+

[dpdk-dev] [PATCH 1/6] qede: add maintainers

2016-02-20 Thread Harish Patil

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 628bc05..1b27467 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -352,6 +352,13 @@ Null PMD
 M: Tetsuya Mukawa 
 F: drivers/net/null/

+QLogic qede PMD
+M: Harish Patil 
+M: Rasesh Mody 
+M: Sony Chacko 
+F: drivers/net/qede/
+F: doc/guides/nics/qede.rst
+
 Intel AES-NI Multi-Buffer
 M: Declan Doherty 
 F: drivers/crypto/aesni_mb/
-- 
1.8.3.1

[dpdk-dev] [PATCH 0/6] DPDK PMD for new QLogic FastLinQ QL4xxxx 25G/40G CNAs

2016-02-20 Thread Harish Patil

This patch set introduces DPDK poll mode driver for new QLogic FastLinQ QL4
25G/40G capable family of CNAs as well as their SR-IOV Virtual Functions (VF).

The overall PMD driver design includes a common module called ecore that deals
with the low level HW and a upper layer portion that provides the glue logic.

Specifically, the ecore module contains all of the common logic,
e.g. initialization, cleanup, infrastructure for interrupt handling, link
management, slowpath etc. as well as protocol agnostic features and supplying
an abstraction layer for other modules.

The higher layer implements DPDK exported APIs/driver entry points by
interfacing with the common module for configuration/status and also the
fastpath routines.

Included in the patch set is the supporting documentation and maintainers.

Please apply.

Thanks,

Harish Patil (6):
  qede: add maintainers
  qede: add documentation
  qede: add QLogic PCI ids
  qede: add driver common module
  qede: add driver
  qede: enable PMD build

 MAINTAINERS | 7 +
 config/common_bsdapp|15 +
 config/common_linuxapp  |16 +
 doc/guides/nics/index.rst   | 1 +
 doc/guides/nics/qede.rst|   344 +
 drivers/net/Makefile| 1 +
 drivers/net/qede/LICENSE.qede_pmd   |28 +
 drivers/net/qede/Makefile   |95 +
 drivers/net/qede/ecore/bcm_osal.c   |   130 +
 drivers/net/qede/ecore/bcm_osal.h   |   408 +
 drivers/net/qede/ecore/common_hsi.h |   714 ++
 drivers/net/qede/ecore/ecore.h  |   785 ++
 drivers/net/qede/ecore/ecore_attn_values.h  | 13287 ++
 drivers/net/qede/ecore/ecore_chain.h|   724 ++
 drivers/net/qede/ecore/ecore_cxt.c  |  2164 
 drivers/net/qede/ecore/ecore_cxt.h  |   173 +
 drivers/net/qede/ecore/ecore_cxt_api.h  |79 +
 drivers/net/qede/ecore/ecore_dcbx.c |   950 ++
 drivers/net/qede/ecore/ecore_dcbx.h |55 +
 drivers/net/qede/ecore/ecore_dcbx_api.h |   166 +
 drivers/net/qede/ecore/ecore_dev.c  |  3907 +++
 drivers/net/qede/ecore/ecore_dev_api.h  |   497 +
 drivers/net/qede/ecore/ecore_gtt_reg_addr.h |42 +
 drivers/net/qede/ecore/ecore_gtt_values.h   |33 +
 drivers/net/qede/ecore/ecore_hsi_common.h   |  1912 
 drivers/net/qede/ecore/ecore_hsi_eth.h  |  1912 
 drivers/net/qede/ecore/ecore_hsi_tools.h|  1081 ++
 drivers/net/qede/ecore/ecore_hw.c   |  1000 ++
 drivers/net/qede/ecore/ecore_hw.h   |   273 +
 drivers/net/qede/ecore/ecore_hw_defs.h  |49 +
 drivers/net/qede/ecore/ecore_init_fw_funcs.c|  1275 +++
 drivers/net/qede/ecore/ecore_init_fw_funcs.h|   263 +
 drivers/net/qede/ecore/ecore_init_ops.c |   610 +
 drivers/net/qede/ecore/ecore_init_ops.h |   103 +
 drivers/net/qede/ecore/ecore_int.c  |  2234 
 drivers/net/qede/ecore/ecore_int.h  |   234 +
 drivers/net/qede/ecore/ecore_int_api.h  |   277 +
 drivers/net/qede/ecore/ecore_iov_api.h  |   931 ++
 drivers/net/qede/ecore/ecore_iro.h  |   168 +
 drivers/net/qede/ecore/ecore_iro_values.h   |59 +
 drivers/net/qede/ecore/ecore_l2.c   |  1801 +++
 drivers/net/qede/ecore/ecore_l2.h   |   151 +
 drivers/net/qede/ecore/ecore_l2_api.h   |   401 +
 drivers/net/qede/ecore/ecore_mcp.c  |  1952 
 drivers/net/qede/ecore/ecore_mcp.h  |   304 +
 drivers/net/qede/ecore/ecore_mcp_api.h  |   629 +
 drivers/net/qede/ecore/ecore_proto_if.h |88 +
 drivers/net/qede/ecore/ecore_rt_defs.h  |   449 +
 drivers/net/qede/ecore/ecore_sp_api.h   |42 +
 drivers/net/qede/ecore/ecore_sp_commands.c  |   531 +
 drivers/net/qede/ecore/ecore_sp_commands.h  |   137 +
 drivers/net/qede/ecore/ecore_spq.c  |   989 ++
 drivers/net/qede/ecore/ecore_spq.h  |   302 +
 drivers/net/qede/ecore/ecore_sriov.c|  3422 ++
 drivers/net/qede/ecore/ecore_sriov.h|   390 +
 drivers/net/qede/ecore/ecore_status.h   |30 +
 drivers/net/qede/ecore/ecore_utils.h|31 +
 drivers/net/qede/ecore/ecore_vf.c   |  1319 +++
 drivers/net/qede/ecore/ecore_vf.h   |   415 +
 drivers/net/qede/ecore/ecore_vf_api.h   |   185 +
 drivers/net/qede/ecore/ecore_vfpf_if.h  |   588 +
 drivers/net/qede/ecore/eth_common.h |   526 +
 drivers/net/qede/ecore/mcp_public.h |  1243 ++
 drivers/net/qede/ecore/nvm_cfg.h|   935 ++
 drivers/net/qede/ecore/reg_addr.h   |  1112 ++
 drivers/net/qede/qede_eth_if.c  |   461 +
 drivers/net/qede

[dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API

2016-01-28 Thread Harish Patil



From: Marc Sune mailto:marcde...@gmail.com>>
Date: Sunday, October 4, 2015 at 2:12 PM
To: "dev at dpdk.org" mailto:dev at 
dpdk.org>>
Subject: [dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API

This patch redesigns the API to set the link speed/s configure
for an ethernet port. Specifically:

- it allows to define a set of advertised speeds for
  auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.

Other changes:

* Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
  values of all supported link speeds, in Mbps.
* Converted link_speed to uint32_t to accomodate 100G speeds
  (bug).
* Added autoneg flag in struct rte_eth_link to indicate if
  link speed was a result of auto-negociation or was fixed
  by configuration.
* Added utility function to convert numeric speeds to bitmap
  fields.
* Adapted testpmd to the new link API.

Signed-off-by: Marc Sune mailto:marcdevel at gmail.com>>
---
 app/test-pmd/cmdline.c | 124 +++--
 app/test/virtual_pmd.c |   4 +-
 drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c |   8 +-
 drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
 drivers/net/e1000/base/e1000_82541.c   |   8 +-
 drivers/net/e1000/base/e1000_82543.c   |   4 +-
 drivers/net/e1000/base/e1000_82575.c   |  11 +--
 drivers/net/e1000/base/e1000_api.c |   2 +-
 drivers/net/e1000/base/e1000_api.h |   2 +-
 drivers/net/e1000/base/e1000_defines.h |   4 +-
 drivers/net/e1000/base/e1000_hw.h  |   2 +-
 drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
 drivers/net/e1000/base/e1000_mac.c |   9 ++-
 drivers/net/e1000/base/e1000_mac.h |   6 +-
 drivers/net/e1000/base/e1000_vf.c  |   4 +-
 drivers/net/e1000/base/e1000_vf.h  |   2 +-
 drivers/net/e1000/em_ethdev.c  | 108 -
 drivers/net/e1000/igb_ethdev.c | 103 
 drivers/net/fm10k/fm10k_ethdev.c   |   8 +-
 drivers/net/i40e/i40e_ethdev.c |  70 
 drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c   |  72 -
 drivers/net/mlx4/mlx4.c|   2 +
 drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
 drivers/net/null/rte_eth_null.c|   5 +-
 drivers/net/pcap/rte_eth_pcap.c|   9 ++-
 drivers/net/ring/rte_eth_ring.c|   5 +-
 drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
 examples/ip_pipeline/config_parse.c|   3 +-
 lib/librte_ether/rte_ethdev.c  |  49 
 lib/librte_ether/rte_ethdev.h  | 113 --
 34 files changed, 437 insertions(+), 356 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0f8f48f..c62f5be 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -897,14 +897,65 @@ struct cmd_config_speed_all {
 cmdline_fixed_string_t value2;
 };

+static int
+parse_and_check_speed_duplex(char *value1, char *value2, uint32_t *link_speed)
+{
+
+int duplex;
+
+if (!strcmp(value2, "half")) {
+duplex = 0;
+} else if (!strcmp(value2, "full")) {
+duplex = 1;
+} else if (!strcmp(value2, "auto")) {
+duplex = 1;
+} else {
+printf("Unknown parameter\n");
+return -1;
+}
+
+if (!strcmp(value1, "10")) {
+*link_speed = (duplex) ? ETH_LINK_SPEED_10M :
+ETH_LINK_SPEED_10M_HD;
+} else if (!strcmp(value1, "100")) {
+*link_speed = (duplex) ? ETH_LINK_SPEED_100M :
+ETH_LINK_SPEED_100M_HD;
+} else if (!strcmp(value1, "1000")) {
+if (!duplex)
+goto invalid_speed_param;
+*link_speed = ETH_LINK_SPEED_1G;
+} else if (!strcmp(value1, "1")) {
+if (!duplex)
+goto invalid_speed_param;
+*link_speed = ETH_LINK_SPEED_10G;
+} else if (!strcmp(value1, "4")) {
+if (!duplex)
+goto invalid_speed_param;
+*link_speed = ETH_LINK_SPEED_40G;
+} else if (!strcmp(value1, "auto")) {
+if (!duplex)
+goto invalid_speed_param;
+*link_speed = ETH_LINK_SPEED_AUTONEG;
+} else {
+printf("Unknown parameter\n");
+return -1;
+}
+
+return 0;
+
+invalid_speed_param:
+
+printf("Invalid speed parameter\n");
+return -1;
+}
+
 static void
 cmd_config_speed_all_parsed(void *parsed_result,
 __attribute__((unused)) struct cmdline *cl,
 __attribute__((unused)) void *data)
 {
 struct cmd_config_speed_all *res = parsed_result;
-uint16_t link_speed =

[dpdk-dev] bnx2x driver and 57800 versus 57810

2016-01-27 Thread Harish Patil

>
>I have to practically identical systems, same hypervisor on each (Centos
>7.x).  In one, I have a 57800 card which works fine with DPDK with
>SRIOV.  In the other, I have a 57810 card which doesn't work with SRIOV.
>
>For the 57810 I have tracked this down to the status block in the VF
>failing to be updated.  The linux driver works fine but it appears to
>use a slightly different scheme -- writing some sort of fastpath status
>block generation per interrupt.
>
>Does anyone have any suggestions or a programming guide for this device?
>
>

What is not working with 57810? Is it link related or traffic? Please
provide the details.
Attached is the SW programming guide for 577xx/578xx. I?m not sure if it
has details pertaining to the specific issue that you have.

Thanks,
Harish


FYI- I had replied to your email earlier with the doc attached but it did
not go thru? yet due to size restrictions.

Your mail to 'dev' with the subject

Re: [dpdk-dev] bnx2x driver and 57800 versus 57810

Is being held until the list moderator can review it for approval.

The reason it is being held:

Message body is too big: 1350322 bytes with a limit of 300 KB




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH] bnx2x: remove unused mbuf_alloc_size

2016-01-05 Thread Harish Patil

>
>The mbuf_alloc_size is leftover from BSD or some other code base.
>It is set but never used in DPDK driver.  After that the related defines
>can also be eliminated.
>
>Signed-off-by: Stephen Hemminger 
>---
> drivers/net/bnx2x/bnx2x.c |  9 -
> drivers/net/bnx2x/bnx2x.h | 18 --
> 2 files changed, 27 deletions(-)
>
>diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
>index 67af5da..6ba6f44 100644
>--- a/drivers/net/bnx2x/bnx2x.c
>+++ b/drivers/net/bnx2x/bnx2x.c
>@@ -2331,15 +2331,6 @@ static void bnx2x_set_fp_rx_buf_size(struct
>bnx2x_softc *sc)
>   /* get the Rx buffer size for RX frames */
>   sc->fp[i].rx_buf_size =
>   (IP_HEADER_ALIGNMENT_PADDING + ETH_OVERHEAD + sc->mtu);
>-
>-  /* get the mbuf allocation size for RX frames */
>-  if (sc->fp[i].rx_buf_size <= MCLBYTES) {
>-  sc->fp[i].mbuf_alloc_size = MCLBYTES;
>-  } else if (sc->fp[i].rx_buf_size <= BNX2X_PAGE_SIZE) {
>-  sc->fp[i].mbuf_alloc_size = PAGE_SIZE;
>-  } else {
>-  sc->fp[i].mbuf_alloc_size = MJUM9BYTES;
>-  }
>   }
> }
>
>diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
>index 2abab0c..9682b8d 100644
>--- a/drivers/net/bnx2x/bnx2x.h
>+++ b/drivers/net/bnx2x/bnx2x.h
>@@ -151,23 +151,6 @@ struct bnx2x_device_type {
> #define FW_PREFETCH_CNT  16U
> #define DROPLESS_FC_HEADROOM 100
>
>-#ifndef MCLSHIFT
>-#define MCLSHIFT  11
>-#endif
>-#define MCLBYTES  (1 << MCLSHIFT)
>-
>-#if !defined(MJUMPAGESIZE)
>-#if BNX2X_PAGE_SIZE < 2048
>-#define MJUMPAGESIZEMCLBYTES
>-#elif BNX2X_PAGE_SIZE <= 8192
>-#define MJUMPAGESIZEBNX2X_PAGE_SIZE
>-#else
>-#define MJUMPAGESIZE(8 * 1024)
>-#endif
>-#endif
>-#define MJUM9BYTES  (9 * 1024)
>-#define MJUM16BYTES (16 * 1024)
>-
> /*
>  * Transmit Buffer Descriptor (tx_bd) definitions*
>  */
>@@ -402,7 +385,6 @@ struct bnx2x_fastpath {
>   uint8_t fw_sb_id;  /* status block number in FW */
>
>   uint32_t rx_buf_size;
>-  int mbuf_alloc_size;
>
>   int state;
> #define BNX2X_FP_STATE_CLOSED  0x01
>--
>2.1.4
>
>

Acked-by: Harish Patil 


Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] bnx2x pmd performance expectations

2015-12-29 Thread Harish Patil

>
>Thank you for pointing this out. While it seems to me problem here is RX,
>I
>will also look into TX burst limitations.
>
>-a
>
>On 28 December 2015 at 00:17, Chas Williams <3chas3 at gmail.com> wrote:
>
>> I wouldn't consider myself an expert on this driver but while looking
>> at some other things, I have noted that RTE_PMD_BNX2X_TX_MAX_BURST is
>> defined to be 1.  This bursts single packets to bnx2x_tx_encap() but it
>> looks like bnx2x_tx_encap() is far more capable than that.
>>
>> On Tue, 2015-12-22 at 14:52 +0300, Alexander Belyakov wrote:
>> > Hi,
>> >
>> > just tried to forward a lot of tiny packets with testpmd (dpdk-2.2.0)
>> > running on Broadcom Corporation NetXtreme II BCM57810S 10 Gigabit
>> > Ethernet
>> > (rev 10) adapter. I see forwarding performance of 2.6Mpps instead of
>> > expected 14.8Mpps. What should be done to achieve better results?
>> >
>> > Thank you,
>> > Alexander Belyakov
>>
>

Alex/Chas,
We have HW/FW limitation for PPS. The adapter can only do ~3 MPPS.
However, yes we can revamp the Tx routines a bit to transmit multiple
packets in a single burst at a time using single doorbelling mechanism.

Thanks
Harish

This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH] bnx2x: set Ethernet address type during transmit for VF's

2015-12-07 Thread Harish Patil

>
>On Sun, 2015-12-06 at 23:34 +, Harish Patil wrote:
>> >
>> >The original was always setting unicast.  While here, clean up some
>> >other references that also point into the Ethernet header.
>> >
>> >Signed-off-by: Chas Williams <3chas3 at gmail.com>
>> >---
>> > drivers/net/bnx2x/bnx2x.c | 23 +++
>> > drivers/net/bnx2x/ecore_hsi.h |  5 +++--
>> > 2 files changed, 18 insertions(+), 10 deletions(-)
>> >
>> >diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
>> >index 76444eb..294711f 100644
>> >--- a/drivers/net/bnx2x/bnx2x.c
>> >+++ b/drivers/net/bnx2x/bnx2x.c
>> >@@ -2177,25 +2177,32 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq,
>> >struct rte_mbuf **m_head, int m_p
>> >   bd_prod = NEXT_TX_BD(bd_prod);
>> >   if (IS_VF(sc)) {
>> >   struct eth_tx_parse_bd_e2 *tx_parse_bd;
>> >-  uint8_t *data = rte_pktmbuf_mtod(m0, uint8_t *);
>> >+  const struct ether_hdr *eh =
>>rte_pktmbuf_mtod(m0, struct ether_hdr *);
>> >+  uint8_t mac_type = UNICAST_ADDRESS;
>> >
>> >   tx_parse_bd =
>> >   >tx_ring[TX_BD(bd_prod,
>>txq)].parse_bd_e2;
>> >+  if (is_multicast_ether_addr(>d_addr)) {
>>
>> Minor comment. unlikely() may be used here to keep it consistent with
>>base
>> driver.
>
>It wasn't clear to me that this code path is all that unlikely().

Its an optional comment, unlikely() is because fast path traffic is mostly
unicast.
BTW, have you tested the patches? Another question, not related to your
change though.
I guess this block of code does not have to been under the IS_VF() check.

>
>> >+  if
>>(is_broadcast_ether_addr(>d_addr))
>> >+  mac_type = BROADCAST_ADDRESS;
>> >+  else
>> >+  mac_type = MULTICAST_ADDRESS;
>> >+  }
>
>
>

This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH] bnx2x: set Ethernet address type during transmit for VF's

2015-12-06 Thread Harish Patil

>
>The original was always setting unicast.  While here, clean up some
>other references that also point into the Ethernet header.
>
>Signed-off-by: Chas Williams <3chas3 at gmail.com>
>---
> drivers/net/bnx2x/bnx2x.c | 23 +++
> drivers/net/bnx2x/ecore_hsi.h |  5 +++--
> 2 files changed, 18 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
>index 76444eb..294711f 100644
>--- a/drivers/net/bnx2x/bnx2x.c
>+++ b/drivers/net/bnx2x/bnx2x.c
>@@ -2177,25 +2177,32 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq,
>struct rte_mbuf **m_head, int m_p
>   bd_prod = NEXT_TX_BD(bd_prod);
>   if (IS_VF(sc)) {
>   struct eth_tx_parse_bd_e2 *tx_parse_bd;
>-  uint8_t *data = rte_pktmbuf_mtod(m0, uint8_t *);
>+  const struct ether_hdr *eh = rte_pktmbuf_mtod(m0, 
>struct ether_hdr *);
>+  uint8_t mac_type = UNICAST_ADDRESS;
>
>   tx_parse_bd =
>   >tx_ring[TX_BD(bd_prod, txq)].parse_bd_e2;
>+  if (is_multicast_ether_addr(>d_addr)) {

Minor comment. unlikely() may be used here to keep it consistent with base
driver.

>+  if (is_broadcast_ether_addr(>d_addr))
>+  mac_type = BROADCAST_ADDRESS;
>+  else
>+  mac_type = MULTICAST_ADDRESS;
>+  }
>   tx_parse_bd->parsing_data =
>-  (1 << ETH_TX_PARSE_BD_E2_ETH_ADDR_TYPE_SHIFT);
>+  (mac_type << 
>ETH_TX_PARSE_BD_E2_ETH_ADDR_TYPE_SHIFT);
>
>   rte_memcpy(_parse_bd->data.mac_addr.dst_hi,
>- [0], 2);
>+ >d_addr.addr_bytes[0], 2);
>   rte_memcpy(_parse_bd->data.mac_addr.dst_mid,
>- [2], 2);
>+ >d_addr.addr_bytes[2], 2);
>   rte_memcpy(_parse_bd->data.mac_addr.dst_lo,
>- [4], 2);
>+ >d_addr.addr_bytes[4], 2);
>   rte_memcpy(_parse_bd->data.mac_addr.src_hi,
>- [6], 2);
>+ >s_addr.addr_bytes[0], 2);
>   rte_memcpy(_parse_bd->data.mac_addr.src_mid,
>- [8], 2);
>+ >s_addr.addr_bytes[2], 2);
>   rte_memcpy(_parse_bd->data.mac_addr.src_lo,
>- [10], 2);
>+ >s_addr.addr_bytes[4], 2);
>
>   tx_parse_bd->data.mac_addr.dst_hi =
>   rte_cpu_to_be_16(tx_parse_bd->data.mac_addr.dst_hi);
>diff --git a/drivers/net/bnx2x/ecore_hsi.h b/drivers/net/bnx2x/ecore_hsi.h
>index a4ed9b5..6c11c5a 100644
>--- a/drivers/net/bnx2x/ecore_hsi.h
>+++ b/drivers/net/bnx2x/ecore_hsi.h
>@@ -4029,7 +4029,7 @@ struct double_regpair
>
>
> /*
>- * Ethernet address typesm used in ethernet tx BDs
>+ * Ethernet address types used in ethernet tx BDs
>  */
> enum eth_addr_type
> {
>@@ -4037,7 +4037,8 @@ enum eth_addr_type
>   UNICAST_ADDRESS,
>   MULTICAST_ADDRESS,
>   BROADCAST_ADDRESS,
>-  MAX_ETH_ADDR_TYPE};
>+  MAX_ETH_ADDR_TYPE
>+};
>
>
> /*
>--
>2.1.0
>
>

Acked-by: Harish Patil 


Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH] bnx2x: tx_start_bd->vlan_or_ethertype is le16

2015-12-01 Thread Harish Patil

>
>On Tue, 1 Dec 2015 21:53:59 +
>Harish Patil  wrote:
>
>> >
>> >Anyone to review please?
>> >
>> >2015-11-03 12:26, Chas Williams:
>> >> Signed-off-by: Chas Williams <3chas3 at gmail.com>
>> >> ---
>> >>  drivers/net/bnx2x/bnx2x.c | 3 ++-
>> >>  1 file changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
>> >> index fed7a06..76444eb 100644
>> >> --- a/drivers/net/bnx2x/bnx2x.c
>> >> +++ b/drivers/net/bnx2x/bnx2x.c
>> >> @@ -2169,7 +2169,8 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq,
>> >>struct rte_mbuf **m_head, int m_p
>> >>  struct ether_hdr *eh
>> >>  = rte_pktmbuf_mtod(m0, struct
>>ether_hdr *);
>> >>
>> >> -tx_start_bd->vlan_or_ethertype =
>>eh->ether_type;
>> >> +tx_start_bd->vlan_or_ethertype
>> >> +=
>>rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
>> >>  }
>> >>  }
>> >
>> >
>>
>> Acked-by: Harish Patil 
>>
>>
>> Minor question - any specific reason to use rte_be_to_cpu_16() on
>> ether_type alone before converting from native order to le16?
>
>ether_type is in network byte order (big endian)
>and hardware wants little endian. On x86 the second step is a nop.
>

Thanks. Yes the question was for second step, second step would be a no-op
on x86 - thanks for clarifying.

This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH] l3fwd: Fix l3fwd crash due to unaligned load/store intrinsics

2015-11-16 Thread Harish Patil

>

>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of
>>harish.patil at qlogic.com
>> Sent: Sunday, November 08, 2015 7:40 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH] l3fwd: Fix l3fwd crash due to unaligned
>>load/store intrinsics
>>
>> From: Harish Patil 
>>
>> l3fwd app expects PMDs to return packets whose L2 header is
>> 16-byte aligned due to usage of _mm_load_si128()/_mm_store_si128()
>> intrinsics in the app. However, most of the protocol stacks expects
>> packets such that its IP/L3 header be aligned on a 16-byte boundary.
>>
>> Based on the recommendations received on dpdk-dev, we are changing
>> the l3fwd app to use _mm_loadu_si128()/_mm_loadu_si128() so that the
>> address need not be 16-byte aligned and thereby preventing crash.
>> We have tested that there is no performance impact due to this
>> change.
>>
>> Signed-off-by: Harish Patil 
>> ---
>
>Acked-by: Konstantin Ananyev 
>
>As a side notice:
>In fact with gcc build I do see a slight regression: ~1%
>for 4 ports over 1 core test-case.
>Though I think the problem is not in the patch itself.
>By some, unknown to me reason, gcc treats aligned and unaligned load/store
>instrincts in a different way (at least for that particular case).
>With aligned load/store in use it generates code that is pretty close to
>the source:
> 4 loads first, then 4 BLENDs, then 4  stores  (with some interfering
>scalar instructions of course).
>But with unaligned ones  gcc starts to mix loads and blends for the same
>register, so now it is:
>load x0; blend x0; load x1; blend x1; ..
>As if the source code was:
>
>te[0] = _mm_loadu_si128(p[0]);
>te[0] =  _mm_blend_epi16(te[0], ve[0], MASK_ETH);
>te[1] = _mm_loadu_si128(p[1]);
>te[1] =  _mm_blend_epi16(te[1], ve[1], MASK_ETH);
>...
>
>So load latency is not hidden any more.
>I tried it with different versions of  - same story for all of them.
>Clang doesn't have such issue and generates similar code for both
>aligned and unaligned instrincts.
>
>The only way to fix it I can think about  -  put rte_compiler_barrier()
>just before the first blend instinct.
>That helped, now there are no noticeable differences in generated code
>and results before and after the patch.
> So I suppose, I'll have to submit a patch after yours one to fix that
>problem.
>Konstantin
>
>

Sure, thanks for verifying and providing fix.

Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 3/5] bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option

2015-11-08 Thread Harish Patil


>> >Either other "debug" logs can be put as INFO level, or
>> >you need a level 9 for verbose debug.
>> >But I don't really understand what is the problem of a verbose debug.
>> >
>> >It is not critical for the acceptance of this patch. Just wanted to
>> >discuss
>> >it as we have many config options to tune the debug.
>> >
>> >Please, at least, use the DEBUG word in the option name as done for
>> >CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX.
>> >
>>
>> Currently PMD_DRV_LOG(DEBUG,..) is used all over the places and
>>converting
>> that into INFO/NOTICE levels results in lot of changes.
>
>Having a lot of changes to do is not a good argument.
>But that's an argument to reduce the size of the bnx2x driver.

Okay, we need to look into that if there is a way.

>And more generally, this driver would deserve some big changes.
>
>> Even if we convert other debug logs as INFO level logs, since level 8 is
>> the default debug level,  the user would have to edit config file to
>> prevent flooding of the messages on the console.
>
>The user *should* change the log evel in most cases.
>Or we could raise the default level to INFO.
>And users of packaged DPDK may already have a different configuration
>from the distribution.

Yes, I think we should default it to INFO.

>
>> So I guess adding a debug
>> option without needing additional level would suffice for now. I shall
>> rename it as CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC and include all
>> periodic events like statistics, register R/Ws etc under this debug.
>
>Yes it could work.
>But it would be nice to have a consistent log management across drivers.
>
Okay, I will re-submit the patch with this change, thanks for the feedback.





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] PMD/l3fwd issue

2015-11-07 Thread Harish Patil


>
>
>> -Original Message-----
>> From: Harish Patil [mailto:harish.patil at qlogic.com]
>> Sent: Friday, September 04, 2015 2:08 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Cc: Ameen Rahman
>> Subject: Re: PMD/l3fwd issue
>>
>> Hi Konstantin,
>>
>> >Hi Patil,
>> >
>> >> -Original Message-
>> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harish Patil
>> >> Sent: Thursday, September 03, 2015 4:53 PM
>> >> To: dev at dpdk.org
>> >> Subject: [dpdk-dev] PMD/l3fwd issue
>> >>
>> >> Hello,
>> >> Have a question regarding l3fwd application. The l3fwd application
>> >>expects
>> >> the poll mode driver to return packets whose L2 header is 16-byte
>> >>aligned.
>> >
>> >Yep, and as I remember, by default PMD returns ti the upper layer mbufs
>> >with data offsets
>> >aligned to cahce line size (64B).
>> >Unless you'll change RTE_PKTMBUF_HEADROOM config parameter.
>> >
>> >> Otherwise, it results in a crash. This is due to use of
>>_mm_load_si128()
>> >> and _mm_store_si128() intrinsics which expects the address to be
>>16-byte
>> >> aligned. However, most of the real protocol stack expects packets
>>such
>> >> that its IP header be aligned on a 16-byte boundary (not L2). Its not
>> >>just
>> >> for IP but any L3 for that matter.  That?s way we usually see
>> >> skb_reserve(skb, NET_IP_ALIGN) calls in linux drivers.
>> >
>> >Well, l3fwd is just an example application to demonstrate usage of DPDK
>> >API
>> >And max performance it could get for that type of workload.
>> >No-one forces you to use aligned load/store in your own application.
>>
>> Yes, I agree if its our private application. But l3fwd being widely used
>> as a benchmarking/testing tool and they may ran into this issue.
>>
>
>If someone would try to run it with RTE_PKTMBUF_HEADROOM non-aligned on
>16B, then probably yes.
>
>> >
>> >>
>> >> So I?m looking for suggestions here, whether l3wd application or poll
>> >>mode
>> >> driver should be changed to fix that? What is the right thing to do?
>> >> Can a check be added in l3fwd to use _mm_loadu_si128/_mm_storeu_si128
>> >> instructions instead of mm_load_si128/_mm_store_si128 if address is
>> >>found
>> >> not be 16B aligned?
>> >
>> >I'd personally just change l3fwd to use to use
>> >_mm_loadu_si128/_mm_storeu_si128 unconditionally.
>> >As by default  address is 16B aligned anyway, I think that using MOVDQU
>> >instead of MOVDQA here
>> >shouldn't make that big difference.
>> >But off course testing need to be done to make sure there is no
>> >performance drop with that change.
>>
>> I too would just change l3fwd application so that all poll mode drivers
>> would just work. Are you proposing that we upstream l3fwd change if we
>> don?t see performance drop?
>
>Yep, I'd suggest to verify there is no performance difference and submit
>a patch.
>From our side we can do some extra performance testing too.
>Thanks
>Konstantin

Hi Konstantin,
As you suggested, I have submitted the patch.

Thanks,
Harish


>
>>
>> >Konstantin
>> >
>> >>
>> >> Thanks,
>> >> Harish
>> >>
>> >>
>> >>
>> >> 
>> >>
>> >> This message and any attached documents contain information from the
>> >>sending company or its parent company(s), subsidiaries,
>> >> divisions or branch offices that may be confidential. If you are not
>> >>the intended recipient, you may not read, copy, distribute, or use
>> >> this information. If you have received this transmission in error,
>> >>please notify the sender immediately by reply e-mail and then delete
>> >> this message.
>> >
>>
>>
>>
>> 
>>
>> This message and any attached documents contain information from the
>>sending company or its parent company(s), subsidiaries,
>> divisions or branch offices that may be confidential. If you are not
>>the intended recipient, you may not read, copy, distribute, or use
>> this information. If you have received this transmission in error,
>>please notify the sender immediately by reply e-mail and then delete
>> this message.
>





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 3/5] bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option

2015-11-07 Thread Harish Patil


>2015-10-23 22:28, Harish Patil:
>> >2015-09-11 17:42, Rasesh Mody:
>> >> From: Harish Patil 
>> >> --- a/config/common_linuxapp
>> >> +++ b/config/common_linuxapp
>> >> @@ -220,6 +220,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
>> >>  CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
>> >>  CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
>> >>  CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
>> >> +CONFIG_RTE_LIBRTE_BNX2X_REG_ACCESS=n
>> >
>> >Why do you need this option?
>>
>> Currently logging of register accesses is using (wrongly) the generic
>> driver debug option of PMD_DRV_LOG (which gets enabled if
>> CONFIG_RTE_LIBRTE_BNX2X_DEBUG=y).
>> This floods the console due to excessive printing of register
>> reads/writes. So creating a new debug option in order to capture only
>>the
>> register read/writes (if required) and also does not interfere with the
>> informational/user-level debug.
>
>You mean there is not enough log levels?
>
>#define RTE_LOG_EMERG1U  /**< System is unusable.   */
>#define RTE_LOG_ALERT2U  /**< Action must be taken immediately. */
>#define RTE_LOG_CRIT 3U  /**< Critical conditions.  */
>#define RTE_LOG_ERR  4U  /**< Error conditions. */
>#define RTE_LOG_WARNING  5U  /**< Warning conditions.   */
>#define RTE_LOG_NOTICE   6U  /**< Normal but significant condition. */
>#define RTE_LOG_INFO 7U  /**< Informational.*/
>#define RTE_LOG_DEBUG8U  /**< Debug-level messages. */
>
>Either other "debug" logs can be put as INFO level, or
>you need a level 9 for verbose debug.
>But I don't really understand what is the problem of a verbose debug.
>
>It is not critical for the acceptance of this patch. Just wanted to
>discuss
>it as we have many config options to tune the debug.
>
>Please, at least, use the DEBUG word in the option name as done for
>CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX.
>

Currently PMD_DRV_LOG(DEBUG,..) is used all over the places and converting
that into INFO/NOTICE levels results in lot of changes.
Even if we convert other debug logs as INFO level logs, since level 8 is
the default debug level,  the user would have to edit config file to
prevent flooding of the messages on the console. So I guess adding a debug
option without needing additional level would suffice for now. I shall
rename it as CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC and include all
periodic events like statistics, register R/Ws etc under this debug.

Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

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

2015-11-03 Thread Harish Patil

>
>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
>
>

Acked-by: Harish Patil 


Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 2/5] bnx2x: Fix x86_64-native-linuxapp-clang build error

2015-11-03 Thread Harish Patil


>2015-10-23 16:36, Harish Patil:
>> >
>> >2015-09-11 17:42, Rasesh Mody:
>> >>  #define SHMEM_EEE_ADV_STATUS_MASK  0x00f0
>> >>  #define SHMEM_EEE_100M_ADV (1<<0)
>> >> -#define SHMEM_EEE_1G_ADV   (1<<1)
>> >> +#define SHMEM_EEE_1G_ADV   (1U<<1)
>> >>  #define SHMEM_EEE_10G_ADV  (1<<2)
>> >
>> >Why other constants are not changed?
>> I only addressed the build error which is against SHMEM_EEE_1G_ADV.
>> Is that okay?
>
>I would say no but you have the ownership on this code.
>Please think which code quality you are expecting.

[Harish] I checked out internally. This is a header file based on regspecs
which would be difficult to change/test everywhere.
So I would just have to do this point fix.
>
>> This message and any attached documents contain information from the
>>sending company or its parent company(s), subsidiaries, divisions or
>>branch offices that may be confidential. If you are not the intended
>>recipient, you may not read, copy, distribute, or use this information.
>>If you have received this transmission in error, please notify the
>>sender immediately by reply e-mail and then delete this message.
>
>Please remove this footer, irrelevant on a mailing list.
>





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] Status of bnx2x pmd?

2015-11-02 Thread Harish Patil

>
>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,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH v5 08/28] bnx2x: copy pci device info to eth_dev data

2015-10-23 Thread Harish Patil

>
>Signed-off-by: Bernard Iremonger 
>---
> drivers/net/bnx2x/bnx2x_ethdev.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c
>b/drivers/net/bnx2x/bnx2x_ethdev.c
>index 09b5920..fbcd5f4 100644
>--- a/drivers/net/bnx2x/bnx2x_ethdev.c
>+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
>@@ -419,6 +419,9 @@ bnx2x_common_dev_init(struct rte_eth_dev *eth_dev,
>int is_vf)
>
>   eth_dev->dev_ops = is_vf ? _eth_dev_ops : _eth_dev_ops;
>   pci_dev = eth_dev->pci_dev;
>+
>+  rte_eth_copy_dev_info(eth_dev, pci_dev);
>+
>   sc = eth_dev->data->dev_private;
>   sc->pcie_bus= pci_dev->addr.bus;
>   sc->pcie_device = pci_dev->addr.devid;
>--
>1.9.1
>
>

Acked-by: Harish Patil 


Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 3/5] bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option

2015-10-23 Thread Harish Patil

>
>2015-09-11 17:42, Rasesh Mody:
>> From: Harish Patil 
>> --- a/config/common_linuxapp
>> +++ b/config/common_linuxapp
>> @@ -220,6 +220,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
>>  CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
>>  CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
>>  CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
>> +CONFIG_RTE_LIBRTE_BNX2X_REG_ACCESS=n
>
>Why do you need this option?

Currently logging of register accesses is using (wrongly) the generic
driver debug option of PMD_DRV_LOG (which gets enabled if
CONFIG_RTE_LIBRTE_BNX2X_DEBUG=y).
This floods the console due to excessive printing of register
reads/writes. So creating a new debug option in order to capture only the
register read/writes (if required) and also does not interfere with the
informational/user-level debug.


>Why only for Linux?
It was added for BSD as well in the subsequent patch ([PATCH 1/6] bnx2x:
FreeBSD enablement). Will include it in a single patch in v2 series.

>And last but not the least, why nobody else have reviewed carefully this
>patch
>after one month?
>
>





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 2/5] bnx2x: Fix x86_64-native-linuxapp-clang build error

2015-10-23 Thread Harish Patil

>
>2015-09-11 17:42, Rasesh Mody:
>>  #define SHMEM_EEE_ADV_STATUS_MASK  0x00f0
>>  #define SHMEM_EEE_100M_ADV (1<<0)
>> -#define SHMEM_EEE_1G_ADV   (1<<1)
>> +#define SHMEM_EEE_1G_ADV   (1U<<1)
>>  #define SHMEM_EEE_10G_ADV  (1<<2)
>
>Why other constants are not changed?
I only addressed the build error which is against SHMEM_EEE_1G_ADV.
Is that okay?
>
>Please put at least the build error in the message.
>
Sure, will include the build error and submit new patch.

drivers/net/bnx2x/elink.c:10384:41: error: shifting a
  negative signed value is undefined [-Werror,-Wshift-negative-value]
vars->eee_status &= ~SHMEM_EEE_1G_ADV <<
~ ^
1 error generated.
make[6]: *** [elink.o] Error 1
make[5]: *** [bnx2x] Error 2
make[4]: *** [net] Error 2
make[3]: *** [drivers] Error 2
make[2]: *** [all] Error 2
make[1]: *** [x86_64-native-linuxapp-clang_install] Error 2
make: *** [install] Error 2





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 1/5] bnx2x: SR-IOV VF driver changes to support OOB PF driver

2015-10-21 Thread Harish Patil

>
>2015-10-21 15:24, Harish Patil:
>> >
>> >2015-09-11 17:42, Rasesh Mody:
>> >> From: Harish Patil 
>> >>
>> >> Signed-off-by: Harish Patil 
>> >
>> >Please explain your change a bit more.
>> >
>> >
>>
>> SR-IOV is supported using bnx2x poll mode driver running as VF driver
>>and
>> native linux driver running as PF (in host/hypervisor). There is no
>>issue
>> while running with the PF driver which is at the base version as that of
>> PMD. However, there is a compatibility issue between newer out-of-box PF
>> drivers with older VF driver. So the newer VFs would also need to send
>> BNX2X_VF_TLV_PHYS_PORT_ID (among other TLVs) to differentiate between
>> newer and older VFs.
>
>So the title should be "update VF to support new PF drivers".
>Please put the detailed explanation in the commit message.
>

Agree, shall do.

Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 1/5] bnx2x: SR-IOV VF driver changes to support OOB PF driver

2015-10-21 Thread Harish Patil

>
>2015-09-11 17:42, Rasesh Mody:
>> From: Harish Patil 
>>
>> Signed-off-by: Harish Patil 
>
>Please explain your change a bit more.
>
>

SR-IOV is supported using bnx2x poll mode driver running as VF driver and
native linux driver running as PF (in host/hypervisor). There is no issue
while running with the PF driver which is at the base version as that of
PMD. However, there is a compatibility issue between newer out-of-box PF
drivers with older VF driver. So the newer VFs would also need to send
BNX2X_VF_TLV_PHYS_PORT_ID (among other TLVs) to differentiate between
newer and older VFs.

Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] DPDK PktGen: sending multiple streams

2015-09-24 Thread Harish Patil

Hi,
I?m trying to figure out how to send multiple streams of traffic (say by
changing port/ipaddr) from the peer to SUT to test multiqueue with RSS
functionality. I?m using DPDK PktGen on the SUT as well to bind each
receive queue to different cores for spreading the load.
Can we use pcap option for that?
-s P:file: The PCAP packet file to stream. P is the port number.
If so, can you pls give the exact example?
Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 0/5] bnx2x: Enhancement, fixes, licensing and doumentation

2015-09-12 Thread Harish Patil


>On Fri, 11 Sep 2015 17:42:51 -0700
>Rasesh Mody  wrote:
>
>> Hi
>>
>> This patch set consists of enhancements, fixes, licensing and
>> documentation changes for the QLogic bnx2x Poll Mode Driver. The patches
>> have been generated and tested against latest dpdk tree.
>>
>> Please apply.
>>
>> Thanks!
>> Rasesh
>>
>> Harish Patil (4):
>>   bnx2x: SR-IOV VF driver changes to support OOB PF driver
>>   bnx2x: Fix x86_64-native-linuxapp-clang build error
>>   bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option
>>   doc: Add BNX2X PMD documentation
>>
>> Rasesh Mody (1):
>>   bnx2x: Add LICENSE.bnx2x_pmd and update source files
>>
>>  config/common_linuxapp  |1 +
>>  doc/guides/nics/bnx2x.rst   |  324
>>+++
>>  drivers/net/bnx2x/LICENSE.bnx2x_pmd |   28 +++
>>  drivers/net/bnx2x/Makefile  |2 +-
>>  drivers/net/bnx2x/bnx2x.c   |   29 +---
>>  drivers/net/bnx2x/bnx2x.h   |   31 +---
>>  drivers/net/bnx2x/bnx2x_ethdev.c|4 +
>>  drivers/net/bnx2x/bnx2x_ethdev.h|4 +
>>  drivers/net/bnx2x/bnx2x_logs.h  |   12 ++
>>  drivers/net/bnx2x/bnx2x_rxtx.c  |4 +
>>  drivers/net/bnx2x/bnx2x_rxtx.h  |4 +
>>  drivers/net/bnx2x/bnx2x_stats.c |   27 +--
>>  drivers/net/bnx2x/bnx2x_stats.h |   27 +--
>>  drivers/net/bnx2x/bnx2x_vfpf.c  |   15 +-
>>  drivers/net/bnx2x/bnx2x_vfpf.h  |   19 ++
>>  drivers/net/bnx2x/debug.c   |   51 ++
>>  drivers/net/bnx2x/ecore_fw_defs.h   |   27 +--
>>  drivers/net/bnx2x/ecore_hsi.h   |   29 +---
>>  drivers/net/bnx2x/ecore_init.h  |   27 +--
>>  drivers/net/bnx2x/ecore_init_ops.h  |   27 +--
>>  drivers/net/bnx2x/ecore_mfw_req.h   |   27 +--
>>  drivers/net/bnx2x/ecore_reg.h   |   27 +--
>>  drivers/net/bnx2x/ecore_sp.c|   27 +--
>>  drivers/net/bnx2x/ecore_sp.h|   27 +--
>>  drivers/net/bnx2x/elink.c   |   29 +---
>>  drivers/net/bnx2x/elink.h   |   29 +---
>>  26 files changed, 483 insertions(+), 375 deletions(-)
>>  create mode 100644 doc/guides/nics/bnx2x.rst
>>  create mode 100644 drivers/net/bnx2x/LICENSE.bnx2x_pmd
>
>
>This part looks good. Could you send a patch to MAINTAINERS file
>as well.
>
>Acked-by: Stephen Hemminger 
>

Hi Stephen,

[dpdk-dev] PMD/l3fwd issue

2015-09-04 Thread Harish Patil

Hi Konstantin,

>Hi Patil,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harish Patil
>> Sent: Thursday, September 03, 2015 4:53 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] PMD/l3fwd issue
>>
>> Hello,
>> Have a question regarding l3fwd application. The l3fwd application
>>expects
>> the poll mode driver to return packets whose L2 header is 16-byte
>>aligned.
>
>Yep, and as I remember, by default PMD returns ti the upper layer mbufs
>with data offsets
>aligned to cahce line size (64B).
>Unless you'll change RTE_PKTMBUF_HEADROOM config parameter.
>
>> Otherwise, it results in a crash. This is due to use of _mm_load_si128()
>> and _mm_store_si128() intrinsics which expects the address to be 16-byte
>> aligned. However, most of the real protocol stack expects packets such
>> that its IP header be aligned on a 16-byte boundary (not L2). Its not
>>just
>> for IP but any L3 for that matter.  That?s way we usually see
>> skb_reserve(skb, NET_IP_ALIGN) calls in linux drivers.
>
>Well, l3fwd is just an example application to demonstrate usage of DPDK
>API
>And max performance it could get for that type of workload.
>No-one forces you to use aligned load/store in your own application.

Yes, I agree if its our private application. But l3fwd being widely used
as a benchmarking/testing tool and they may ran into this issue.

>
>>
>> So I?m looking for suggestions here, whether l3wd application or poll
>>mode
>> driver should be changed to fix that? What is the right thing to do?
>> Can a check be added in l3fwd to use _mm_loadu_si128/_mm_storeu_si128
>> instructions instead of mm_load_si128/_mm_store_si128 if address is
>>found
>> not be 16B aligned?
>
>I'd personally just change l3fwd to use to use
>_mm_loadu_si128/_mm_storeu_si128 unconditionally.
>As by default  address is 16B aligned anyway, I think that using MOVDQU
>instead of MOVDQA here
>shouldn't make that big difference.
>But off course testing need to be done to make sure there is no
>performance drop with that change.

I too would just change l3fwd application so that all poll mode drivers
would just work. Are you proposing that we upstream l3fwd change if we
don?t see performance drop?

>Konstantin
>
>>
>> Thanks,
>> Harish
>>
>>
>>
>> 
>>
>> This message and any attached documents contain information from the
>>sending company or its parent company(s), subsidiaries,
>> divisions or branch offices that may be confidential. If you are not
>>the intended recipient, you may not read, copy, distribute, or use
>> this information. If you have received this transmission in error,
>>please notify the sender immediately by reply e-mail and then delete
>> this message.
>





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [RFC PATCH 03/18] bnx2x: remove type field and initialise name field in rte_driver structure

2015-09-04 Thread Harish Patil

>
>Signed-off-by: Bernard Iremonger 
>---
> drivers/net/bnx2x/bnx2x_ethdev.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c
>b/drivers/net/bnx2x/bnx2x_ethdev.c
>index 09b5920..b25ca21 100644
>--- a/drivers/net/bnx2x/bnx2x_ethdev.c
>+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
>@@ -1,5 +1,6 @@
> /*
>  * Copyright (c) 2013-2015 Brocade Communications Systems, Inc.
>+ * Copyright(c) 2015 Intel Corporation.
>  *
>  * All rights reserved.
>  */
>@@ -529,12 +530,12 @@ static int rte_bnx2xvf_pmd_init(const char *name
>__rte_unused, const char *param
> }
>
> static struct rte_driver rte_bnx2x_driver = {
>-  .type = PMD_PDEV,
>+  .name = "rte_bnx2x_driver", /* PCI device */
>   .init = rte_bnx2x_pmd_init,
> };
>
> static struct rte_driver rte_bnx2xvf_driver = {
>-  .type = PMD_PDEV,
>+  .name = "rte_bnx2xvf_driver",   /* PCI device */
>   .init = rte_bnx2xvf_pmd_init,
> };
>
>--
>1.9.1
>
>

Acked-by: Harish Patil 


Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] PMD/l3fwd issue

2015-09-03 Thread Harish Patil

Hello,
Have a question regarding l3fwd application. The l3fwd application expects
the poll mode driver to return packets whose L2 header is 16-byte aligned.
Otherwise, it results in a crash. This is due to use of _mm_load_si128()
and _mm_store_si128() intrinsics which expects the address to be 16-byte
aligned. However, most of the real protocol stack expects packets such
that its IP header be aligned on a 16-byte boundary (not L2). Its not just
for IP but any L3 for that matter.  That?s way we usually see
skb_reserve(skb, NET_IP_ALIGN) calls in linux drivers.

So I?m looking for suggestions here, whether l3wd application or poll mode
driver should be changed to fix that? What is the right thing to do?
Can a check be added in l3fwd to use _mm_loadu_si128/_mm_storeu_si128
instructions instead of mm_load_si128/_mm_store_si128 if address is found
not be 16B aligned?

Thanks,
Harish





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH v5 0/4] bnx2x: poll mode driver

2015-07-23 Thread Harish Patil

>
>Changes in this version (v5):
>  - rebase to 2.1.0-rc1
>  - fix version map for 2.1
>  - fix doxygen comments
>  - add BCM57410 ids
>
>Stephen Hemminger (4):
>  eal: provide functions to access PCI config
>  bnx2x: driver core
>  bnx2x: driver support routines
>  bnx2x: enable PMD build
>
> MAINTAINERS | 3 +
> config/common_linuxapp  |10 +
> drivers/net/Makefile| 1 +
> drivers/net/bnx2x/Makefile  |28 +
> drivers/net/bnx2x/bnx2x.c   | 11821
>+++
> drivers/net/bnx2x/bnx2x.h   |  1998 
> drivers/net/bnx2x/bnx2x_ethdev.c|   542 +
> drivers/net/bnx2x/bnx2x_ethdev.h|79 +
> drivers/net/bnx2x/bnx2x_logs.h  |51 +
> drivers/net/bnx2x/bnx2x_rxtx.c  |   487 +
> drivers/net/bnx2x/bnx2x_rxtx.h  |85 +
> drivers/net/bnx2x/bnx2x_stats.c |  1619 +++
> drivers/net/bnx2x/bnx2x_stats.h |   632 +
> drivers/net/bnx2x/bnx2x_vfpf.c  |   597 +
> drivers/net/bnx2x/bnx2x_vfpf.h  |   315 +
> drivers/net/bnx2x/debug.c   |   113 +
> drivers/net/bnx2x/ecore_fw_defs.h   |   422 +
> drivers/net/bnx2x/ecore_hsi.h   |  6348 ++
> drivers/net/bnx2x/ecore_init.h  |   841 ++
> drivers/net/bnx2x/ecore_init_ops.h  |   886 ++
> drivers/net/bnx2x/ecore_mfw_req.h   |   206 +
> drivers/net/bnx2x/ecore_reg.h   |  3663 ++
> drivers/net/bnx2x/ecore_sp.c|  5455 +
> drivers/net/bnx2x/ecore_sp.h|  1795 +++
> drivers/net/bnx2x/elink.c   | 13378
>++
> drivers/net/bnx2x/elink.h   |   609 +
> drivers/net/bnx2x/rte_pmd_bnx2x_version.map | 4 +
> lib/librte_eal/bsdapp/eal/eal_pci.c |83 +
> lib/librte_eal/bsdapp/eal/rte_eal_version.map   | 3 +-
> lib/librte_eal/common/include/rte_pci.h |32 +
> lib/librte_eal/common/include/rte_pci_dev_ids.h |61 +
> lib/librte_eal/linuxapp/eal/eal_pci.c   |50 +
> lib/librte_eal/linuxapp/eal/eal_pci_init.h  |11 +
> lib/librte_eal/linuxapp/eal/eal_pci_uio.c   |14 +
> lib/librte_eal/linuxapp/eal/eal_pci_vfio.c  |16 +
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +-
> mk/rte.app.mk   | 2 +
> 37 files changed, 52261 insertions(+), 2 deletions(-)
> create mode 100644 drivers/net/bnx2x/Makefile
> create mode 100644 drivers/net/bnx2x/bnx2x.c
> create mode 100644 drivers/net/bnx2x/bnx2x.h
> create mode 100644 drivers/net/bnx2x/bnx2x_ethdev.c
> create mode 100644 drivers/net/bnx2x/bnx2x_ethdev.h
> create mode 100644 drivers/net/bnx2x/bnx2x_logs.h
> create mode 100644 drivers/net/bnx2x/bnx2x_rxtx.c
> create mode 100644 drivers/net/bnx2x/bnx2x_rxtx.h
> create mode 100644 drivers/net/bnx2x/bnx2x_stats.c
> create mode 100644 drivers/net/bnx2x/bnx2x_stats.h
> create mode 100644 drivers/net/bnx2x/bnx2x_vfpf.c
> create mode 100644 drivers/net/bnx2x/bnx2x_vfpf.h
> create mode 100644 drivers/net/bnx2x/debug.c
> create mode 100644 drivers/net/bnx2x/ecore_fw_defs.h
> create mode 100644 drivers/net/bnx2x/ecore_hsi.h
> create mode 100644 drivers/net/bnx2x/ecore_init.h
> create mode 100644 drivers/net/bnx2x/ecore_init_ops.h
> create mode 100644 drivers/net/bnx2x/ecore_mfw_req.h
> create mode 100644 drivers/net/bnx2x/ecore_reg.h
> create mode 100644 drivers/net/bnx2x/ecore_sp.c
> create mode 100644 drivers/net/bnx2x/ecore_sp.h
> create mode 100644 drivers/net/bnx2x/elink.c
> create mode 100644 drivers/net/bnx2x/elink.h
> create mode 100644 drivers/net/bnx2x/rte_pmd_bnx2x_version.map
>
>--
>2.1.4
>
>

Acked-by: Harish Patil 

Thanks,
Harish






This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] [PATCH 0/4 v5] bnx2x: poll mode driver

2015-06-26 Thread Harish Patil


>From: Stephen Hemminger 
>
>Changes since last time:
> 1. Support pci_config on BSD. Although since BSD probably doesn't
>have same filesystem  (/lib/firmware) the driver won't work.
> 2. Change location of driver to match new filesystem hierarchy
>
>Stephen Hemminger (4):
>  eal: provide functions to access PCI config
>  bnx2x: driver core
>  bnx2x: driver support routines
>  bnx2x: enable PMD build
>
> MAINTAINERS | 3 +
> config/common_linuxapp  |10 +
> drivers/net/Makefile| 1 +
> drivers/net/bnx2x/Makefile  |28 +
> drivers/net/bnx2x/bnx2x.c   | 11821
>+++
> drivers/net/bnx2x/bnx2x.h   |  1998 
> drivers/net/bnx2x/bnx2x_ethdev.c|   542 +
> drivers/net/bnx2x/bnx2x_ethdev.h|79 +
> drivers/net/bnx2x/bnx2x_logs.h  |51 +
> drivers/net/bnx2x/bnx2x_rxtx.c  |   487 +
> drivers/net/bnx2x/bnx2x_rxtx.h  |85 +
> drivers/net/bnx2x/bnx2x_stats.c |  1619 +++
> drivers/net/bnx2x/bnx2x_stats.h |   632 +
> drivers/net/bnx2x/bnx2x_vfpf.c  |   597 +
> drivers/net/bnx2x/bnx2x_vfpf.h  |   315 +
> drivers/net/bnx2x/debug.c   |   113 +
> drivers/net/bnx2x/ecore_fw_defs.h   |   422 +
> drivers/net/bnx2x/ecore_hsi.h   |  6348 ++
> drivers/net/bnx2x/ecore_init.h  |   841 ++
> drivers/net/bnx2x/ecore_init_ops.h  |   886 ++
> drivers/net/bnx2x/ecore_mfw_req.h   |   206 +
> drivers/net/bnx2x/ecore_reg.h   |  3663 ++
> drivers/net/bnx2x/ecore_sp.c|  5455 +
> drivers/net/bnx2x/ecore_sp.h|  1795 +++
> drivers/net/bnx2x/elink.c   | 13378
>++
> drivers/net/bnx2x/elink.h   |   609 +
> drivers/net/bnx2x/rte_pmd_bnx2x_version.map | 4 +
> lib/librte_eal/bsdapp/eal/eal_pci.c |83 +
> lib/librte_eal/bsdapp/eal/rte_eal_version.map   | 2 +
> lib/librte_eal/common/include/rte_pci.h |28 +
> lib/librte_eal/common/include/rte_pci_dev_ids.h |30 +
> lib/librte_eal/linuxapp/eal/eal_pci.c   |50 +
> lib/librte_eal/linuxapp/eal/eal_pci_init.h  |11 +
> lib/librte_eal/linuxapp/eal/eal_pci_uio.c   |14 +
> lib/librte_eal/linuxapp/eal/eal_pci_vfio.c  |16 +
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 +
> mk/rte.app.mk   | 2 +
> 37 files changed, 52226 insertions(+)
> create mode 100644 drivers/net/bnx2x/Makefile
> create mode 100644 drivers/net/bnx2x/bnx2x.c
> create mode 100644 drivers/net/bnx2x/bnx2x.h
> create mode 100644 drivers/net/bnx2x/bnx2x_ethdev.c
> create mode 100644 drivers/net/bnx2x/bnx2x_ethdev.h
> create mode 100644 drivers/net/bnx2x/bnx2x_logs.h
> create mode 100644 drivers/net/bnx2x/bnx2x_rxtx.c
> create mode 100644 drivers/net/bnx2x/bnx2x_rxtx.h
> create mode 100644 drivers/net/bnx2x/bnx2x_stats.c
> create mode 100644 drivers/net/bnx2x/bnx2x_stats.h
> create mode 100644 drivers/net/bnx2x/bnx2x_vfpf.c
> create mode 100644 drivers/net/bnx2x/bnx2x_vfpf.h
> create mode 100644 drivers/net/bnx2x/debug.c
> create mode 100644 drivers/net/bnx2x/ecore_fw_defs.h
> create mode 100644 drivers/net/bnx2x/ecore_hsi.h
> create mode 100644 drivers/net/bnx2x/ecore_init.h
> create mode 100644 drivers/net/bnx2x/ecore_init_ops.h
> create mode 100644 drivers/net/bnx2x/ecore_mfw_req.h
> create mode 100644 drivers/net/bnx2x/ecore_reg.h
> create mode 100644 drivers/net/bnx2x/ecore_sp.c
> create mode 100644 drivers/net/bnx2x/ecore_sp.h
> create mode 100644 drivers/net/bnx2x/elink.c
> create mode 100644 drivers/net/bnx2x/elink.h
> create mode 100644 drivers/net/bnx2x/rte_pmd_bnx2x_version.map
>
>--
>2.1.4
>
>
Acked-by: Harish Patil 


Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] freeing memzone

2015-05-28 Thread Harish Patil

>
>On 21/05/2015 17:59, Harish Patil wrote:
>> Hello dpdk-dev,
>>
>> I understand that the reserved memzones cannot be freed, as mentioned in
>> the DPDK specs. But I would like to know why? Is there any limitations?
>There should be a few threads in the mailing list related to this topic.
>Last that comes to mind:
>http://dpdk.org/ml/archives/dev/2015-April/016501.html
>
>Short answer is, it has not been implemented yet.
>> If the memory is not freed/returned, then can it be reused for
>>subsequent
>> allocations without re-init (i.e. with same memzone name)?
>> We use it for allocating DMA?ble memory.
>It is up to the application to manage the use/re-use of memzones.
>By the way, would maybe rte_malloc memory be more suitable than memzones
>for your application?
>You can retrieve the physical address of memory allcoated by rte_malloc
>with rte_malloc_virt2phy.
>> Secondly, there was a related discussion on this in the following email
>> thread:
>> http://dpdk.org/ml/archives/dev/2014-July/004456.html
>>
>> Do we plan to incorporate that changes?
>There is some ongoing work related to freeing memzones:
>http://dpdk.org/ml/archives/dev/2015-May/017470.html
>
>Feel free to comment on it.
>
>Sergio
>> Thanks,
>> Harish
>>
>>
>> 
>>
>

Thanks very much Sergio. I will take a look at your suggested links and
get back to you shortly.

Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] freeing memzone

2015-05-21 Thread Harish Patil

Hello dpdk-dev,

I understand that the reserved memzones cannot be freed, as mentioned in
the DPDK specs. But I would like to know why? Is there any limitations?
If the memory is not freed/returned, then can it be reused for subsequent
allocations without re-init (i.e. with same memzone name)?
We use it for allocating DMA?ble memory.

Secondly, there was a related discussion on this in the following email
thread:
http://dpdk.org/ml/archives/dev/2014-July/004456.html

Do we plan to incorporate that changes?

Thanks,
Harish




This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] KNI ethtool related question

2014-10-10 Thread Harish Patil

Hello,
I would like to use KNI interface *only* for the ethtool/ifconfig support,
not for the data packets movement into and from the kernel. For the fast
path, I would like to use PMD. Is this doable? What are the other options
for a PMD driver to support standard linux utilities?
Thanks in adv.,
Harish





This message and any attached documents contain information from the sending 
company or its parent company(s), subsidiaries, divisions or branch offices 
that may be confidential. If you are not the intended recipient, you may not 
read, copy, distribute, or use this information. If you have received this 
transmission in error, please notify the sender immediately by reply e-mail and 
then delete this message.

[dpdk-dev] Inter-VM communication packet flow

2014-07-24 Thread Harish Patil

Gentle second request.

>DPDK-dev,
>From the documentation, its not very clear to me how would the inter-VM
>communication packet path (traffic crossing the physical port), especially
>the way macaddr table is populated in each PF port and role of the PF poll
>mode driver in this context. Could you please explain the flow here?
>
>Thanks,
>Harish
>
>
>
>





This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

[dpdk-dev] Inter-VM communication packet flow

2014-07-23 Thread Harish Patil

DPDK-dev,

[dpdk-dev] KNI interface

2014-07-19 Thread Harish Patil



>KNI is mainly designed for exception path or control plane packets that
>need to be pushed
>to Linux TCP/IP packets in the kernel. You can push all the packets that
>DPDK PMD received
>in the user space via KNI to kernel, but majority of them will be dropped
>for two reasons: 1) skb
>allocation/free and memory copy between mbuf and skb 2) slow TCP/IP
>stack.
>In terms of how to use it, basically it is user responsibility to do
>simple flow classification using
>5-tuple in DPDK application, and push exception packets or control
>packets to KNI queues, in other
>words, to slow path. While DPDK user space still process fast path
>packets.

Thanks for the clarification, Bruce/Danny.

Few follow-on questions:

i) Does the generic 5-tuple flow classification that the DPDK provides
would cover all possible packet types (e.g. Q-Q/tunneled/vxlan etc)?.
Manual packet parsing by the poll mode driver would be a daunting task by
itself.

ii) How would the forwarding/routing changes in the kernel pushed to (or
synchronized with) the DPDK L2/L3 application?

iii) Can we just live with [base DPDK + linux TCP/IP stack], without
third-party modules, to achieve full networking stack functionality at
least in a non-virtualized environment ?


>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harish Patil
>> Sent: Saturday, July 19, 2014 8:09 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] KNI interface
>>
>> Hello dpdk-dev,
>> Went thru? couple of documentation but not very clear to me. Does using
>> KNI means handing over all the packets received/transmitted by the poll
>> mode driver to the linux stack or can it be controlled for the control
>> packets only ? What is the KNI use-case (besides ethtool) and what are
>>the
>> best options/choices/strategy to use poll mode driver for data path and
>> linux for control plane operations ?
>>
>> Thanks,
>> Harish
>>
>>
>>
>>
>>
>>
>> 
>>
>> This message and any attached documents contain information from QLogic
>>Corporation or its wholly-owned subsidiaries that may be
>> confidential. If you are not the intended recipient, you may not read,
>>copy, distribute, or use this information. If you have received this
>> transmission in error, please notify the sender immediately by reply
>>e-mail and then delete this message.
>





This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

[dpdk-dev] KNI interface

2014-07-19 Thread Harish Patil

Hello dpdk-dev,
Went thru? couple of documentation but not very clear to me. Does using
KNI means handing over all the packets received/transmitted by the poll
mode driver to the linux stack or can it be controlled for the control
packets only ? What is the KNI use-case (besides ethtool) and what are the
best options/choices/strategy to use poll mode driver for data path and
linux for control plane operations ?

Thanks,
Harish








This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

[dpdk-dev] NIC-related dpdk questions.

2014-06-23 Thread Harish Patil

Folks,
I?m a newbie going thru? dpdk. Have few quick questions.

1) Where can I find implementations of PMD of third party (non-Intel)
adapters like librte_pmd_mlx4 or librte_pmd_oce? Is it available for
reference?

2) What are the pre-requisites to start using PMD for a thirdparty NIC vendor ?

3) Things to keep in mind if any for using dpdk ?

4) My understanding is that dpdk can also work other than IA arch but
with some penalty (eg: ppc)? Is that right ?

Thx
harish

91 matches

Mail list logo