[dpdk-dev] Question on examples/multi_process app

[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
>> >> >> > > 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.
>
>If that's a real HW limitation, then my opinion yes, we probably better
>address it.
No its not a HW limitation. It can be handled.

>Though not sure what is the best way:
>1) just update the docs and rely on users to read them 

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

[Rasesh Mody]

This patch enables the QEDE PMD build.

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 config/common_base  |   14 ++
 drivers/net/Makefile|1 +
 mk/rte.app.mk   |2 ++
 scripts/checkpatches.sh |1 +
 scripts/test-build.sh   |1 +
 5 files changed, 19 insertions(+)

diff --git a/config/common_base b/config/common_base
index dbd405b..14b37df 100644
--- a/config/common_base
+++ b/config/common_base
@@ -295,6 +295,20 @@ CONFIG_RTE_LIBRTE_PMD_BOND=y
 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 software PMD backed by AF_PACKET sockets (Linux only)
 #
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 0c3393f..529f1c6 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -46,6 +46,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += mpipe
 DIRS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += nfp
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += null
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += pcap
+DIRS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += ring
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += szedata2
 DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index b6c7bb0..e3f6501 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -103,6 +103,7 @@ _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_NFP_PMD)+= -lm
+_LDLIBS-$(CONFIG_RTE_LIBRTE_QEDE_PMD)   += -lz
 # QAT / AESNI GCM PMDs are dependent on libcrypto (from openssl)
 # for calculating HMAC precomputes
 ifeq ($(CONFIG_RTE_LIBRTE_PMD_QAT),y)
@@ -148,6 +149,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

 ifeq ($(CONFIG_RTE_LIBRTE_CRYPTODEV),y)
diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
index afc611b..ae26687 100755
--- a/scripts/checkpatches.sh
+++ b/scripts/checkpatches.sh
@@ -49,6 +49,7 @@ options="$options 
--ignore=LINUX_VERSION_CODE,FILE_PATH_CHANGES,\
 VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,PREFER_KERNEL_TYPES,\
 
SPLIT_STRING,LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_STYLE,\
 NEW_TYPEDEFS,COMPARISON_TO_NULL"
+options="$options --ignore=BIT_MACRO,CONCATENATED_STRING"

 print_usage () {
echo "usage: $(basename $0) [-q] [-v] [patch1 [patch2] ...]]"
diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index 5f3cab5..dfc8915 100755
--- 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
test "$DPDK_DEP_PCAP" != y || \
sed -ri   's,(PCAP=)n,\1y,' $1/.config
test -z "$AESNI_MULTI_BUFFER_LIB_PATH" || \
-- 
1.7.10.3

[dpdk-dev] [PATCH v4 09/10] qede: Add DCBX support

[Rasesh Mody]

This patch adds LLDP and DCBX capabilities to the qede PMD.

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 drivers/net/qede/Makefile |1 +
 drivers/net/qede/base/bcm_osal.h  |1 +
 drivers/net/qede/base/ecore.h |2 +
 drivers/net/qede/base/ecore_dcbx.c|  887 +
 drivers/net/qede/base/ecore_dcbx.h|   55 ++
 drivers/net/qede/base/ecore_dcbx_api.h|  160 ++
 drivers/net/qede/base/ecore_dev.c |   27 +
 drivers/net/qede/base/ecore_l2.c  |3 -
 drivers/net/qede/base/ecore_mcp.c |   16 +
 drivers/net/qede/base/ecore_sp_commands.c |4 +
 drivers/net/qede/base/mcp_public.h|  205 +++
 drivers/net/qede/base/nvm_cfg.h   |6 +
 12 files changed, 1364 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/qede/base/ecore_dcbx.c
 create mode 100644 drivers/net/qede/base/ecore_dcbx.h
 create mode 100644 drivers/net/qede/base/ecore_dcbx_api.h

diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile
index 8970921..cb59bbe 100644
--- a/drivers/net/qede/Makefile
+++ b/drivers/net/qede/Makefile
@@ -77,6 +77,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_spq.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_init_ops.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_mcp.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_int.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_dcbx.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/bcm_osal.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_sriov.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_vf.c
diff --git a/drivers/net/qede/base/bcm_osal.h b/drivers/net/qede/base/bcm_osal.h
index cbd10a3..21e8130 100644
--- a/drivers/net/qede/base/bcm_osal.h
+++ b/drivers/net/qede/base/bcm_osal.h
@@ -305,6 +305,7 @@ u32 qede_find_first_zero_bit(unsigned long *, u32);
 #define ETH_ALEN   ETHER_ADDR_LEN

 #define OSAL_LINK_UPDATE(hwfn) nothing
+#define OSAL_DCBX_AEN(hwfn, mib_type) nothing

 /* SR-IOV channel */

diff --git a/drivers/net/qede/base/ecore.h b/drivers/net/qede/base/ecore.h
index 63f8ca7..f76f0eb 100644
--- a/drivers/net/qede/base/ecore.h
+++ b/drivers/net/qede/base/ecore.h
@@ -152,6 +152,7 @@ struct ecore_dma_mem;
 struct ecore_sb_sp_info;
 struct ecore_igu_info;
 struct ecore_mcp_info;
+struct ecore_dcbx_info;

 struct ecore_rt_data {
u32 *init_val;
@@ -499,6 +500,7 @@ struct ecore_hwfn {
struct ecore_vf_iov *vf_iov_info;
struct ecore_pf_iov *pf_iov_info;
struct ecore_mcp_info *mcp_info;
+   struct ecore_dcbx_info *p_dcbx_info;

struct ecore_hw_cid_data *p_tx_cids;
struct ecore_hw_cid_data *p_rx_cids;
diff --git a/drivers/net/qede/base/ecore_dcbx.c 
b/drivers/net/qede/base/ecore_dcbx.c
new file mode 100644
index 000..6a966cb
--- /dev/null
+++ b/drivers/net/qede/base/ecore_dcbx.c
@@ -0,0 +1,887 @@
+/*
+ * Copyright (c) 2016 QLogic Corporation.
+ * All rights reserved.
+ * www.qlogic.com
+ *
+ * See LICENSE.qede_pmd for copyright and licensing details.
+ */
+
+#include "bcm_osal.h"
+#include "ecore.h"
+#include "ecore_sp_commands.h"
+#include "ecore_dcbx.h"
+#include "ecore_cxt.h"
+#include "ecore_gtt_reg_addr.h"
+#include "ecore_iro.h"
+
+#define ECORE_DCBX_MAX_MIB_READ_TRY(100)
+#define ECORE_MAX_PFC_PRIORITIES   8
+#define ECORE_ETH_TYPE_DEFAULT (0)
+
+#define ECORE_DCBX_INVALID_PRIORITY0xFF
+
+/* Get Traffic Class from priority traffic class table, 4 bits represent
+ * the traffic class corresponding to the priority.
+ */
+#define ECORE_DCBX_PRIO2TC(prio_tc_tbl, prio) \
+   ((u32)(pri_tc_tbl >> ((7 - prio) * 4)) & 0x7)
+
+static bool ecore_dcbx_app_ethtype(u32 app_info_bitmap)
+{
+   return (ECORE_MFW_GET_FIELD(app_info_bitmap, DCBX_APP_SF) ==
+   DCBX_APP_SF_ETHTYPE) ? true : false;
+}
+
+static bool ecore_dcbx_app_port(u32 app_info_bitmap)
+{
+   return (ECORE_MFW_GET_FIELD(app_info_bitmap, DCBX_APP_SF) ==
+   DCBX_APP_SF_PORT) ? true : false;
+}
+
+static bool ecore_dcbx_default_tlv(u32 app_info_bitmap, u16 proto_id)
+{
+   return (ecore_dcbx_app_ethtype(app_info_bitmap) &&
+   proto_id == ECORE_ETH_TYPE_DEFAULT) ? true : false;
+}
+
+static bool ecore_dcbx_enabled(u32 dcbx_cfg_bitmap)
+{
+   return (ECORE_MFW_GET_FIELD(dcbx_cfg_bitmap, DCBX_CONFIG_VERSION) ==
+   DCBX_CONFIG_VERSION_DISABLED) ? false : true;
+}
+
+static bool ecore_dcbx_cee(u32 dcbx_cfg_bitmap)
+{
+   return (ECORE_MFW_GET_FIELD(dcbx_cfg_bitmap, DCBX_CONFIG_VERSION) ==
+   DCBX_CONFIG_VERSION_CEE) ? true : false;
+}
+
+static bool ecore_dcbx_ieee(u32 dcbx_cfg_bitmap)
+{
+   return (ECORE_MFW_GET_FIELD(dcbx_cfg_bitmap, DCBX_CONFIG_VERSION) ==
+   DCBX_CONFIG_VERSION_IEEE) ? true : false;
+}
+
+/* @@@TBD A0 Eagle workaround */
+void ecore_dcbx_eagle_workaround(struct ecore_hwfn *p_hwfn,
+

[dpdk-dev] [PATCH v4 08/10] qede: Add attention support

[Rasesh Mody]

Physical link is handled by the management Firmware.
This patch lays the infrastructure for attention handling in the driver,
as link change notifications arrive via async attentions, as well as the
handling of such notifications. It adds async event notification handler
interfaces to the PMD.

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 drivers/net/qede/base/ecore_attn_values.h |13287 +
 drivers/net/qede/base/ecore_dev.c |   51 +
 drivers/net/qede/base/ecore_int.c | 1131 +++
 3 files changed, 14469 insertions(+)
 create mode 100644 drivers/net/qede/base/ecore_attn_values.h

diff --git a/drivers/net/qede/base/ecore_attn_values.h 
b/drivers/net/qede/base/ecore_attn_values.h
new file mode 100644
index 000..d8951bc
--- /dev/null
+++ b/drivers/net/qede/base/ecore_attn_values.h
@@ -0,0 +1,13287 @@
+/*
+ * Copyright (c) 2016 QLogic Corporation.
+ * All rights reserved.
+ * www.qlogic.com
+ *
+ * See LICENSE.qede_pmd for copyright and licensing details.
+ */
+
+#ifndef __ATTN_VALUES_H__
+#define __ATTN_VALUES_H__
+
+#ifndef __PREVENT_INT_ATTN__
+
+/* HW Attention register */
+struct attn_hw_reg {
+   u16 reg_idx;/* Index of this register in its block */
+   u16 num_of_bits;/* number of valid attention bits */
+   const u16 *bit_attn_idx;/* attention index per valid bit */
+   u32 sts_addr;   /* Address of the STS register */
+   u32 sts_clr_addr;   /* Address of the STS_CLR register */
+   u32 sts_wr_addr;/* Address of the STS_WR register */
+   u32 mask_addr;  /* Address of the MASK register */
+};
+
+/* HW block attention registers */
+struct attn_hw_regs {
+   u16 num_of_int_regs;/* Number of interrupt regs */
+   u16 num_of_prty_regs;   /* Number of parity regs */
+   struct attn_hw_reg **int_regs;  /* interrupt regs */
+   struct attn_hw_reg **prty_regs; /* parity regs */
+};
+
+/* HW block attention registers */
+struct attn_hw_block {
+   const char *name;   /* Block name */
+   const char **int_desc;  /* Array of interrupt attention descriptions */
+   const char **prty_desc; /* Array of parity attention descriptions */
+   struct attn_hw_regs chip_regs[3];   /* attention regs per chip.*/
+};
+
+#ifdef ATTN_DESC
+static const char *grc_int_attn_desc[5] = {
+   "grc_address_error",
+   "grc_timeout_event",
+   "grc_global_reserved_address",
+   "grc_path_isolation_error",
+   "grc_trace_fifo_valid_data",
+};
+#else
+#define grc_int_attn_desc OSAL_NULL
+#endif
+
+static const u16 grc_int0_bb_a0_attn_idx[4] = {
+   0, 1, 2, 3,
+};
+
+static struct attn_hw_reg grc_int0_bb_a0 = {
+   0, 4, grc_int0_bb_a0_attn_idx, 0x50180, 0x5018c, 0x50188, 0x50184
+};
+
+static struct attn_hw_reg *grc_int_bb_a0_regs[1] = {
+   _int0_bb_a0,
+};
+
+static const u16 grc_int0_bb_b0_attn_idx[4] = {
+   0, 1, 2, 3,
+};
+
+static struct attn_hw_reg grc_int0_bb_b0 = {
+   0, 4, grc_int0_bb_b0_attn_idx, 0x50180, 0x5018c, 0x50188, 0x50184
+};
+
+static struct attn_hw_reg *grc_int_bb_b0_regs[1] = {
+   _int0_bb_b0,
+};
+
+static const u16 grc_int0_k2_attn_idx[5] = {
+   0, 1, 2, 3, 4,
+};
+
+static struct attn_hw_reg grc_int0_k2 = {
+   0, 5, grc_int0_k2_attn_idx, 0x50180, 0x5018c, 0x50188, 0x50184
+};
+
+static struct attn_hw_reg *grc_int_k2_regs[1] = {
+   _int0_k2,
+};
+
+#ifdef ATTN_DESC
+static const char *grc_prty_attn_desc[3] = {
+   "grc_mem003_i_mem_prty",
+   "grc_mem002_i_mem_prty",
+   "grc_mem001_i_mem_prty",
+};
+#else
+#define grc_prty_attn_desc OSAL_NULL
+#endif
+
+static const u16 grc_prty1_bb_a0_attn_idx[2] = {
+   1, 2,
+};
+
+static struct attn_hw_reg grc_prty1_bb_a0 = {
+   0, 2, grc_prty1_bb_a0_attn_idx, 0x50200, 0x5020c, 0x50208, 0x50204
+};
+
+static struct attn_hw_reg *grc_prty_bb_a0_regs[1] = {
+   _prty1_bb_a0,
+};
+
+static const u16 grc_prty1_bb_b0_attn_idx[2] = {
+   0, 1,
+};
+
+static struct attn_hw_reg grc_prty1_bb_b0 = {
+   0, 2, grc_prty1_bb_b0_attn_idx, 0x50200, 0x5020c, 0x50208, 0x50204
+};
+
+static struct attn_hw_reg *grc_prty_bb_b0_regs[1] = {
+   _prty1_bb_b0,
+};
+
+static const u16 grc_prty1_k2_attn_idx[2] = {
+   0, 1,
+};
+
+static struct attn_hw_reg grc_prty1_k2 = {
+   0, 2, grc_prty1_k2_attn_idx, 0x50200, 0x5020c, 0x50208, 0x50204
+};
+
+static struct attn_hw_reg *grc_prty_k2_regs[1] = {
+   _prty1_k2,
+};
+
+#ifdef ATTN_DESC
+static const char *miscs_int_attn_desc[14] = {
+   "miscs_address_error",
+   "miscs_generic_sw",
+   "miscs_cnig_interrupt",
+   "miscs_opte_dorq_fifo_err_eng1",
+   "miscs_opte_dorq_fifo_err_eng0",
+   "miscs_opte_dbg_fifo_err_eng1",
+   "miscs_opte_dbg_fifo_err_eng0",
+   "miscs_opte_btb_if1_fifo_err_eng1",
+   "miscs_opte_btb_if1_fifo_err_eng0",
+   "miscs_opte_btb_if0_fifo_err_eng1",
+   

[dpdk-dev] [PATCH v4 07/10] qede: Add SRIOV support

[Rasesh Mody]

This patch adds following SRIOV features to qede PMD:
 - VF configuration
 - VF intialization/de-initialization
 - VF PF communications channel
 - statistics capture and query

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 drivers/net/qede/Makefile  |2 +
 drivers/net/qede/base/bcm_osal.c   |9 +
 drivers/net/qede/base/bcm_osal.h   |7 +-
 drivers/net/qede/base/ecore.h  |1 +
 drivers/net/qede/base/ecore_dev.c  |   99 +-
 drivers/net/qede/base/ecore_hw.c   |9 +-
 drivers/net/qede/base/ecore_init_ops.c |4 +
 drivers/net/qede/base/ecore_int.c  |   31 +-
 drivers/net/qede/base/ecore_iov_api.h  |  933 +
 drivers/net/qede/base/ecore_l2.c   |  233 ++-
 drivers/net/qede/base/ecore_l2.h   |   50 +
 drivers/net/qede/base/ecore_mcp.c  |   30 +
 drivers/net/qede/base/ecore_spq.c  |8 +-
 drivers/net/qede/base/ecore_sriov.c| 3422 
 drivers/net/qede/base/ecore_sriov.h|  390 
 drivers/net/qede/base/ecore_vf.c   | 1322 
 drivers/net/qede/base/ecore_vf.h   |  415 
 drivers/net/qede/base/ecore_vf_api.h   |  186 ++
 drivers/net/qede/base/ecore_vfpf_if.h  |  590 ++
 drivers/net/qede/qede_ethdev.c |   20 +-
 drivers/net/qede/qede_ethdev.h |4 +-
 drivers/net/qede/qede_main.c   |  155 +-
 22 files changed, 7827 insertions(+), 93 deletions(-)
 create mode 100644 drivers/net/qede/base/ecore_iov_api.h
 create mode 100644 drivers/net/qede/base/ecore_sriov.c
 create mode 100644 drivers/net/qede/base/ecore_sriov.h
 create mode 100644 drivers/net/qede/base/ecore_vf.c
 create mode 100644 drivers/net/qede/base/ecore_vf.h
 create mode 100644 drivers/net/qede/base/ecore_vf_api.h
 create mode 100644 drivers/net/qede/base/ecore_vfpf_if.h

diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile
index eb08635..8970921 100644
--- a/drivers/net/qede/Makefile
+++ b/drivers/net/qede/Makefile
@@ -78,6 +78,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_init_ops.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_mcp.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_int.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/bcm_osal.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_sriov.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_vf.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_ethdev.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_eth_if.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_main.c
diff --git a/drivers/net/qede/base/bcm_osal.c b/drivers/net/qede/base/bcm_osal.c
index 90f16c4..cd4ce57 100644
--- a/drivers/net/qede/base/bcm_osal.c
+++ b/drivers/net/qede/base/bcm_osal.c
@@ -14,6 +14,7 @@
 #include "bcm_osal.h"
 #include "ecore.h"
 #include "ecore_hw.h"
+#include "ecore_iov_api.h"

 unsigned long qede_log2_align(unsigned long n)
 {
@@ -81,6 +82,14 @@ inline u32 qede_find_first_zero_bit(unsigned long *addr, u32 
limit)
return (i == nwords) ? limit : i * OSAL_BITS_PER_UL + qede_ffz(addr[i]);
 }

+void qede_vf_fill_driver_data(struct ecore_hwfn *hwfn,
+ __rte_unused struct vf_pf_resc_request *resc_req,
+ struct ecore_vf_acquire_sw_info *vf_sw_info)
+{
+   vf_sw_info->os_type = VFPF_ACQUIRE_OS_LINUX_USERSPACE;
+   vf_sw_info->override_fw_version = 1;
+}
+
 void *osal_dma_alloc_coherent(struct ecore_dev *p_dev,
  dma_addr_t *phys, size_t size)
 {
diff --git a/drivers/net/qede/base/bcm_osal.h b/drivers/net/qede/base/bcm_osal.h
index b31532f..cbd10a3 100644
--- a/drivers/net/qede/base/bcm_osal.h
+++ b/drivers/net/qede/base/bcm_osal.h
@@ -22,6 +22,8 @@
 /* Forward declaration */
 struct ecore_dev;
 struct ecore_hwfn;
+struct ecore_vf_acquire_sw_info;
+struct vf_pf_resc_request;

 #if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
 #undef __BIG_ENDIAN
@@ -315,12 +317,15 @@ u32 qede_find_first_zero_bit(unsigned long *, u32);
 #define OSAL_IOV_VF_ACQUIRE(hwfn, vfid) 0
 #define OSAL_IOV_VF_CLEANUP(hwfn, vfid) nothing
 #define OSAL_IOV_VF_VPORT_UPDATE(hwfn, vfid, p_params, p_mask) 0
-#define OSAL_VF_FILL_ACQUIRE_RESC_REQ(_dev_p, _resc_req, _os_info) nothing
 #define OSAL_VF_UPDATE_ACQUIRE_RESC_RESP(_dev_p, _resc_resp) 0
 #define OSAL_IOV_GET_OS_TYPE() 0

 u32 qede_unzip_data(struct ecore_hwfn *p_hwfn, u32 input_len,
   u8 *input_buf, u32 max_size, u8 *unzip_buf);
+void qede_vf_fill_driver_data(struct ecore_hwfn *, struct vf_pf_resc_request *,
+ struct ecore_vf_acquire_sw_info *);
+#define OSAL_VF_FILL_ACQUIRE_RESC_REQ(_dev_p, _resc_req, _os_info) \
+   qede_vf_fill_driver_data(_dev_p, _resc_req, _os_info)

 #define OSAL_UNZIP_DATA(p_hwfn, input_len, buf, max_size, unzip_buf) \
qede_unzip_data(p_hwfn, input_len, buf, max_size, unzip_buf)
diff --git a/drivers/net/qede/base/ecore.h b/drivers/net/qede/base/ecore.h
index 32a3de9..63f8ca7 100644
--- 

[dpdk-dev] [PATCH v4 06/10] qede: Add L2 support

[Rasesh Mody]

This patch adds the features to supports configuration of various Layer 2
elements, such as channels and filtering options.

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 drivers/net/qede/Makefile|2 +
 drivers/net/qede/base/ecore_chain.h  |6 +
 drivers/net/qede/base/ecore_l2.c | 1608 ++
 drivers/net/qede/base/ecore_l2.h |  101 +++
 drivers/net/qede/base/ecore_l2_api.h |  401 +
 drivers/net/qede/qede_eth_if.c   |  455 ++
 drivers/net/qede/qede_eth_if.h   |2 +-
 drivers/net/qede/qede_ethdev.c   |   17 +-
 drivers/net/qede/qede_ethdev.h   |1 +
 drivers/net/qede/qede_if.h   |9 +
 drivers/net/qede/qede_main.c |2 +
 drivers/net/qede/qede_rxtx.c |  192 
 12 files changed, 2792 insertions(+), 4 deletions(-)
 create mode 100644 drivers/net/qede/base/ecore_l2.c
 create mode 100644 drivers/net/qede/base/ecore_l2.h
 create mode 100644 drivers/net/qede/base/ecore_l2_api.h
 create mode 100644 drivers/net/qede/qede_eth_if.c

diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile
index efaefb2..eb08635 100644
--- a/drivers/net/qede/Makefile
+++ b/drivers/net/qede/Makefile
@@ -70,6 +70,7 @@ $(foreach obj, $(ECORE_DRIVER_OBJS), $(eval 
CFLAGS+=$(CFLAGS_ECORE_DRIVER)))
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_dev.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_hw.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_cxt.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_l2.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_sp_commands.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_init_fw_funcs.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_spq.c
@@ -78,6 +79,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_mcp.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_int.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/bcm_osal.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_ethdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_eth_if.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_main.c
 SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_rxtx.c

diff --git a/drivers/net/qede/base/ecore_chain.h 
b/drivers/net/qede/base/ecore_chain.h
index 98bbffc..c573449 100644
--- a/drivers/net/qede/base/ecore_chain.h
+++ b/drivers/net/qede/base/ecore_chain.h
@@ -251,6 +251,12 @@ static OSAL_INLINE u32 ecore_chain_get_page_cnt(struct 
ecore_chain *p_chain)
return p_chain->page_cnt;
 }

+static OSAL_INLINE
+dma_addr_t ecore_chain_get_pbl_phys(struct ecore_chain *p_chain)
+{
+   return p_chain->pbl.p_phys_table;
+}
+
 /**
  * @brief ecore_chain_advance_page -
  *
diff --git a/drivers/net/qede/base/ecore_l2.c b/drivers/net/qede/base/ecore_l2.c
new file mode 100644
index 000..88e9087
--- /dev/null
+++ b/drivers/net/qede/base/ecore_l2.c
@@ -0,0 +1,1608 @@
+/*
+ * Copyright (c) 2016 QLogic Corporation.
+ * All rights reserved.
+ * www.qlogic.com
+ *
+ * See LICENSE.qede_pmd for copyright and licensing details.
+ */
+
+#include "bcm_osal.h"
+
+#include "ecore.h"
+#include "ecore_status.h"
+#include "ecore_hsi_eth.h"
+#include "ecore_chain.h"
+#include "ecore_spq.h"
+#include "ecore_init_fw_funcs.h"
+#include "ecore_cxt.h"
+#include "ecore_l2.h"
+#include "ecore_sp_commands.h"
+#include "ecore_gtt_reg_addr.h"
+#include "ecore_iro.h"
+#include "reg_addr.h"
+#include "ecore_int.h"
+#include "ecore_hw.h"
+#include "ecore_mcp.h"
+
+#define ECORE_MAX_SGES_NUM 16
+#define CRC32_POLY 0x1edc6f41
+
+enum _ecore_status_t
+ecore_sp_eth_vport_start(struct ecore_hwfn *p_hwfn,
+struct ecore_sp_vport_start_params *p_params)
+{
+   struct vport_start_ramrod_data *p_ramrod = OSAL_NULL;
+   struct ecore_spq_entry *p_ent = OSAL_NULL;
+   enum _ecore_status_t rc = ECORE_NOTIMPL;
+   struct ecore_sp_init_data init_data;
+   u8 abs_vport_id = 0;
+   u16 rx_mode = 0;
+
+   rc = ecore_fw_vport(p_hwfn, p_params->vport_id, _vport_id);
+   if (rc != ECORE_SUCCESS)
+   return rc;
+
+   /* Get SPQ entry */
+   OSAL_MEMSET(_data, 0, sizeof(init_data));
+   init_data.cid = ecore_spq_get_cid(p_hwfn);
+   init_data.opaque_fid = p_params->opaque_fid;
+   init_data.comp_mode = ECORE_SPQ_MODE_EBLOCK;
+
+   rc = ecore_sp_init_request(p_hwfn, _ent,
+  ETH_RAMROD_VPORT_START,
+  PROTOCOLID_ETH, _data);
+   if (rc != ECORE_SUCCESS)
+   return rc;
+
+   p_ramrod = _ent->ramrod.vport_start;
+   p_ramrod->vport_id = abs_vport_id;
+
+   p_ramrod->mtu = OSAL_CPU_TO_LE16(p_params->mtu);
+   p_ramrod->inner_vlan_removal_en = p_params->remove_inner_vlan;
+   p_ramrod->handle_ptp_pkts = p_params->handle_ptp_pkts;
+   p_ramrod->drop_ttl0_en = p_params->drop_ttl0;
+   p_ramrod->untagged = p_params->only_untagged;
+   p_ramrod->zero_placement_offset = p_params->zero_placement_offset;
+

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

[Rasesh Mody]

The Qlogic Everest Driver for Ethernet(QEDE) Poll Mode Driver(PMD) is
the DPDK specific module for QLogic FastLinQ QL4 25G/40G CNA family
of adapters as well as their virtual functions (VF) in SR-IOV context.

This patch adds QEDE PMD, which interacts with base driver and
initialises the HW.

This patch content also includes:
 - eth_dev_ops callbacks
 - Rx/Tx support for the driver
 - link default configuration
 - change link property
 - link up/down/update notifications
 - vlan offload and filtering capability
 - device/function/port statistics

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 drivers/net/qede/Makefile |   90 +++
 drivers/net/qede/qede_eth_if.h|  173 +
 drivers/net/qede/qede_ethdev.c|  957 +++
 drivers/net/qede/qede_ethdev.h|  158 
 drivers/net/qede/qede_if.h|  155 
 drivers/net/qede/qede_logs.h  |   93 +++
 drivers/net/qede/qede_main.c  |  548 ++
 drivers/net/qede/qede_rxtx.c  | 1172 +
 drivers/net/qede/qede_rxtx.h  |  187 +
 drivers/net/qede/rte_pmd_qede_version.map |4 +
 10 files changed, 3537 insertions(+)
 create mode 100644 drivers/net/qede/Makefile
 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/Makefile b/drivers/net/qede/Makefile
new file mode 100644
index 000..efaefb2
--- /dev/null
+++ b/drivers/net/qede/Makefile
@@ -0,0 +1,90 @@
+#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_OBJS=$(patsubst %.c,%.o,$(notdir $(wildcard $(SRCDIR)/base/*.c)))
+$(foreach obj, $(ECORE_DRIVER_OBJS), $(eval CFLAGS+=$(CFLAGS_ECORE_DRIVER)))
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_dev.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_hw.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_cxt.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_sp_commands.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_init_fw_funcs.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_spq.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_init_ops.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_mcp.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/ecore_int.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += base/bcm_osal.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_ethdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_main.c
+SRCS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede_rxtx.c
+
+# dependent libs:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += lib/librte_eal lib/librte_ether
+DEPDIRS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += lib/librte_mempool lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += lib/librte_net lib/librte_malloc
+
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/qede/qede_eth_if.h b/drivers/net/qede/qede_eth_if.h
new file mode 100644
index 000..95a58ac
--- /dev/null
+++ b/drivers/net/qede/qede_eth_if.h
@@ -0,0 +1,173 @@
+/*
+ * Copyright 

[dpdk-dev] [PATCH v4 04/10] qede: Add base driver

[Rasesh Mody]

The base driver is the backend module for the QLogic FastLinQ QL4
25G/40G CNA family of adapters as well as their virtual functions (VF)
in SR-IOV context.

The purpose of the base module is to:
 - provide all the common code that will be shared between the various
   drivers that would be used with said line of products. Flows such as
   chip initialization and de-initialization fall under this category.
 - abstract the protocol-specific HW & FW components, allowing the
   protocol drivers to have clean APIs, which are detached in its
   slowpath configuration from the actual Hardware Software Interface(HSI).

This patch adds a base module without any protocol-specific bits.
I.e., this adds a basic implementation that almost entirely falls under
the first category.

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 drivers/net/qede/base/bcm_osal.c|  171 ++
 drivers/net/qede/base/bcm_osal.h|  389 +++
 drivers/net/qede/base/common_hsi.h  |  714 ++
 drivers/net/qede/base/ecore.h   |  742 ++
 drivers/net/qede/base/ecore_chain.h |  718 ++
 drivers/net/qede/base/ecore_cxt.c   | 1961 +++
 drivers/net/qede/base/ecore_cxt.h   |  157 ++
 drivers/net/qede/base/ecore_cxt_api.h   |   79 +
 drivers/net/qede/base/ecore_dev.c   | 3442 +++
 drivers/net/qede/base/ecore_dev_api.h   |  497 
 drivers/net/qede/base/ecore_gtt_reg_addr.h  |   42 +
 drivers/net/qede/base/ecore_gtt_values.h|   33 +
 drivers/net/qede/base/ecore_hsi_common.h| 1912 +++
 drivers/net/qede/base/ecore_hsi_eth.h   | 1912 +++
 drivers/net/qede/base/ecore_hsi_tools.h | 1081 +
 drivers/net/qede/base/ecore_hw.c|  905 +++
 drivers/net/qede/base/ecore_hw.h|  269 +++
 drivers/net/qede/base/ecore_hw_defs.h   |   49 +
 drivers/net/qede/base/ecore_init_fw_funcs.c | 1275 ++
 drivers/net/qede/base/ecore_init_fw_funcs.h |  263 ++
 drivers/net/qede/base/ecore_init_ops.c  |  595 +
 drivers/net/qede/base/ecore_init_ops.h  |  103 +
 drivers/net/qede/base/ecore_int.c   | 1069 +
 drivers/net/qede/base/ecore_int.h   |  234 ++
 drivers/net/qede/base/ecore_int_api.h   |  277 +++
 drivers/net/qede/base/ecore_iro.h   |  115 +
 drivers/net/qede/base/ecore_iro_values.h|   59 +
 drivers/net/qede/base/ecore_mcp.c   | 1882 +++
 drivers/net/qede/base/ecore_mcp.h   |  304 +++
 drivers/net/qede/base/ecore_mcp_api.h   |  611 +
 drivers/net/qede/base/ecore_proto_if.h  |   28 +
 drivers/net/qede/base/ecore_rt_defs.h   |  446 
 drivers/net/qede/base/ecore_sp_api.h|   42 +
 drivers/net/qede/base/ecore_sp_commands.c   |  521 
 drivers/net/qede/base/ecore_sp_commands.h   |  137 ++
 drivers/net/qede/base/ecore_spq.c   |  937 
 drivers/net/qede/base/ecore_spq.h   |  284 +++
 drivers/net/qede/base/ecore_status.h|   30 +
 drivers/net/qede/base/ecore_utils.h |   31 +
 drivers/net/qede/base/eth_common.h  |  526 
 drivers/net/qede/base/mcp_public.h  |  995 
 drivers/net/qede/base/nvm_cfg.h |  913 +++
 drivers/net/qede/base/reg_addr.h| 1107 +
 43 files changed, 27857 insertions(+)
 create mode 100644 drivers/net/qede/base/bcm_osal.c
 create mode 100644 drivers/net/qede/base/bcm_osal.h
 create mode 100644 drivers/net/qede/base/common_hsi.h
 create mode 100644 drivers/net/qede/base/ecore.h
 create mode 100644 drivers/net/qede/base/ecore_chain.h
 create mode 100644 drivers/net/qede/base/ecore_cxt.c
 create mode 100644 drivers/net/qede/base/ecore_cxt.h
 create mode 100644 drivers/net/qede/base/ecore_cxt_api.h
 create mode 100644 drivers/net/qede/base/ecore_dev.c
 create mode 100644 drivers/net/qede/base/ecore_dev_api.h
 create mode 100644 drivers/net/qede/base/ecore_gtt_reg_addr.h
 create mode 100644 drivers/net/qede/base/ecore_gtt_values.h
 create mode 100644 drivers/net/qede/base/ecore_hsi_common.h
 create mode 100644 drivers/net/qede/base/ecore_hsi_eth.h
 create mode 100644 drivers/net/qede/base/ecore_hsi_tools.h
 create mode 100644 drivers/net/qede/base/ecore_hw.c
 create mode 100644 drivers/net/qede/base/ecore_hw.h
 create mode 100644 drivers/net/qede/base/ecore_hw_defs.h
 create mode 100644 drivers/net/qede/base/ecore_init_fw_funcs.c
 create mode 100644 drivers/net/qede/base/ecore_init_fw_funcs.h
 create mode 100644 drivers/net/qede/base/ecore_init_ops.c
 create mode 100644 drivers/net/qede/base/ecore_init_ops.h
 create mode 100644 drivers/net/qede/base/ecore_int.c
 create mode 100644 drivers/net/qede/base/ecore_int.h
 create mode 100644 drivers/net/qede/base/ecore_int_api.h
 create mode 100644 drivers/net/qede/base/ecore_iro.h
 create mode 100644 drivers/net/qede/base/ecore_iro_values.h
 create mode 100644 

[dpdk-dev] [PATCH v4 03/10] qede: Add license file

[Rasesh Mody]

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 drivers/net/qede/LICENSE.qede_pmd |   28 
 1 file changed, 28 insertions(+)
 create mode 100644 drivers/net/qede/LICENSE.qede_pmd

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.
+ */
-- 
1.7.10.3

[dpdk-dev] [PATCH v4 02/10] qede: Add documentation

[Rasesh Mody]

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
Signed-off-by: Sony Chacko 
---
 doc/guides/nics/index.rst|1 +
 doc/guides/nics/overview.rst |   78 +-
 doc/guides/nics/qede.rst |  340 ++
 3 files changed, 380 insertions(+), 39 deletions(-)
 create mode 100644 doc/guides/nics/qede.rst

diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 0b353a8..5fa4972 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -51,6 +51,7 @@ Network Interface Controller Drivers
 virtio
 vmxnet3
 pcap_ring
+qede

 **Figures**

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 2d4f014..9df5d8e 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -74,38 +74,38 @@ Most of these differences are summarized below.

 .. table:: Features availability in networking drivers

-    = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = =
-   Feature  a b b b c e e i i i i i i i i i i f f m m m n n p r s 
v v v x
-f n n o x 1 n 4 4 4 4 g g x x x x m m l l p f u c i z 
i i m e
-p x x n g 0 i 0 0 0 0 b b g g g g 1 1 x x i p l a n e 
r r x n
-a 2 2 d b 0 c e e e e   v b b b b 0 0 4 5 p   l p g d 
t t n v
-c x x i e 0 . v v   f e e e e k k e a 
i i e i
-k   v n . f f   . v v   .   t 
o o t r
-e   f g .   .   . f f   .   a  
 . 3 t
-t   v   v   v   v   v   2  
 v
-e   e   e   e   e  
 e
-c   c   c   c   c  
 c
-    = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = =
-   link status  X X X   X
-   link status event  X X
+    = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = = = =
+   Feature  a b b b c e e i i i i i i i i i i f f m m m n n p q q 
r s v v v x
+f n n o x 1 n 4 4 4 4 g g x x x x m m l l p f u c e e 
i z i i m e
+p x x n g 0 i 0 0 0 0 b b g g g g 1 1 x x i p l a d d 
n e r r x n
+a 2 2 d b 0 c e e e e   v b b b b 0 0 4 5 p   l p e e 
g d t t n v
+c x x i e 0 . v v   f e e e e k k e v  
 a i i e i
+k   v n . f f   . v v   .   f  
 t o o t r
+e   f g .   .   . f f   .  
 a   . 3 t
+t   v   v   v   v   v  
 2   v
+e   e   e   e   e  
 e
+c   c   c   c   c  
 c
+    = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = = = =
+   link status  X X X X X  
 X
+   link status event  X X X X
Rx interrupt   X X X X
-   queue start/stop X X X X X   X
+   queue start/stop X X X X X  
 X
MTU update   X
-   jumbo frame  X X X X X
-   scattered Rx X X X X X   X
+   jumbo frame  X X X X X X X
+   scattered Rx X X X X X  
 X
LRO
TSO  X X X X X
-   promiscuous mode X X X X X   X
-   allmulticast modeX X X X X   X
-   unicast MAC filter X X X X
-   multicast MAC filter   X X X X
-   RSS hash X X X X X
+   promiscuous mode X X X X X X X  
 X
+   allmulticast modeX X X X X X X  
 X
+   unicast MAC filter X X X X X X
+   multicast MAC filter   X X X X X X
+   RSS hash X X X X X X X
RSS key update X X X X
RSS reta updateX X X X
VMDq   X X
-   SR-IOV X X
+   SR-IOV X X   X
DCBX X
-   VLAN filterX X X X

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

[Rasesh Mody]

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 c7e9fe4..2dbd716 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -357,6 +357,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
+
 Intel AES-NI Multi-Buffer
 M: Declan Doherty 
 F: drivers/crypto/aesni_mb/
-- 
1.7.10.3

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

[Rasesh Mody]

Hi Bruce, Thomas,

The v4 series of QEDE PMD patches addresses all the comments received.
Patches are generated and tested against latest dpdk-next-net.

Compile tested on Linux and FreeBSD using gcc and clang compilers on
x86i_64 and gcc on i586.
 - Linux:
 i686
   gcc version 4.3.4
 x86_64
   clang version 3.8.0
   gcc version 4.8.3
 - FreeBSD:
   x86_64
 clang version 3.6.1
 gcc version 4.8.5

These patches were checked using checkpatch.sh with following additional
ignore options:
   options="$options --ignore=BIT_MACRO,CONCATENATED_STRING"

Please apply.

Rasesh Mody (10):
  qede: Add maintainers
  qede: Add documentation
  qede: Add license file
  qede: Add base driver
  qede: Add core driver
  qede: Add L2 support
  qede: Add SRIOV support
  qede: Add attention support
  qede: Add DCBX support
  qede: Enable PMD build

 MAINTAINERS |7 +
 config/common_base  |   14 +
 doc/guides/nics/index.rst   |1 +
 doc/guides/nics/overview.rst|   78 +-
 doc/guides/nics/qede.rst|  340 +
 drivers/net/Makefile|1 +
 drivers/net/qede/LICENSE.qede_pmd   |   28 +
 drivers/net/qede/Makefile   |   95 +
 drivers/net/qede/base/bcm_osal.c|  180 +
 drivers/net/qede/base/bcm_osal.h|  395 +
 drivers/net/qede/base/common_hsi.h  |  714 ++
 drivers/net/qede/base/ecore.h   |  745 ++
 drivers/net/qede/base/ecore_attn_values.h   |13287 +++
 drivers/net/qede/base/ecore_chain.h |  724 ++
 drivers/net/qede/base/ecore_cxt.c   | 1961 
 drivers/net/qede/base/ecore_cxt.h   |  157 +
 drivers/net/qede/base/ecore_cxt_api.h   |   79 +
 drivers/net/qede/base/ecore_dcbx.c  |  887 ++
 drivers/net/qede/base/ecore_dcbx.h  |   55 +
 drivers/net/qede/base/ecore_dcbx_api.h  |  160 +
 drivers/net/qede/base/ecore_dev.c   | 3597 
 drivers/net/qede/base/ecore_dev_api.h   |  497 +
 drivers/net/qede/base/ecore_gtt_reg_addr.h  |   42 +
 drivers/net/qede/base/ecore_gtt_values.h|   33 +
 drivers/net/qede/base/ecore_hsi_common.h| 1912 
 drivers/net/qede/base/ecore_hsi_eth.h   | 1912 
 drivers/net/qede/base/ecore_hsi_tools.h | 1081 +++
 drivers/net/qede/base/ecore_hw.c|  910 ++
 drivers/net/qede/base/ecore_hw.h|  269 +
 drivers/net/qede/base/ecore_hw_defs.h   |   49 +
 drivers/net/qede/base/ecore_init_fw_funcs.c | 1275 +++
 drivers/net/qede/base/ecore_init_fw_funcs.h |  263 +
 drivers/net/qede/base/ecore_init_ops.c  |  599 ++
 drivers/net/qede/base/ecore_init_ops.h  |  103 +
 drivers/net/qede/base/ecore_int.c   | 2225 +
 drivers/net/qede/base/ecore_int.h   |  234 +
 drivers/net/qede/base/ecore_int_api.h   |  277 +
 drivers/net/qede/base/ecore_iov_api.h   |  933 ++
 drivers/net/qede/base/ecore_iro.h   |  115 +
 drivers/net/qede/base/ecore_iro_values.h|   59 +
 drivers/net/qede/base/ecore_l2.c| 1798 
 drivers/net/qede/base/ecore_l2.h|  151 +
 drivers/net/qede/base/ecore_l2_api.h|  401 +
 drivers/net/qede/base/ecore_mcp.c   | 1928 
 drivers/net/qede/base/ecore_mcp.h   |  304 +
 drivers/net/qede/base/ecore_mcp_api.h   |  611 ++
 drivers/net/qede/base/ecore_proto_if.h  |   28 +
 drivers/net/qede/base/ecore_rt_defs.h   |  446 +
 drivers/net/qede/base/ecore_sp_api.h|   42 +
 drivers/net/qede/base/ecore_sp_commands.c   |  525 ++
 drivers/net/qede/base/ecore_sp_commands.h   |  137 +
 drivers/net/qede/base/ecore_spq.c   |  943 ++
 drivers/net/qede/base/ecore_spq.h   |  284 +
 drivers/net/qede/base/ecore_sriov.c | 3422 +++
 drivers/net/qede/base/ecore_sriov.h |  390 +
 drivers/net/qede/base/ecore_status.h|   30 +
 drivers/net/qede/base/ecore_utils.h |   31 +
 drivers/net/qede/base/ecore_vf.c| 1322 +++
 drivers/net/qede/base/ecore_vf.h|  415 +
 drivers/net/qede/base/ecore_vf_api.h|  186 +
 drivers/net/qede/base/ecore_vfpf_if.h   |  590 ++
 drivers/net/qede/base/eth_common.h  |  526 ++
 drivers/net/qede/base/mcp_public.h  | 1200 +++
 drivers/net/qede/base/nvm_cfg.h |  919 ++
 drivers/net/qede/base/reg_addr.h| 1107 +++
 drivers/net/qede/qede_eth_if.c  |  455 +
 drivers/net/qede/qede_eth_if.h  |  173 +
 drivers/net/qede/qede_ethdev.c  |  986 ++
 drivers/net/qede/qede_ethdev.h  |  159 +
 drivers/net/qede/qede_if.h  |  164 +
 drivers/net/qede/qede_logs.h|   93 +
 drivers/net/qede/qede_main.c|  601 ++
 drivers/net/qede/qede_rxtx.c| 1364 +++
 drivers/net/qede/qede_rxtx.h 

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

[Rasesh Mody]

Hi Bruce,

> From: Bruce Richardson [mailto:bruce.richardson at intel.com]
> Sent: Tuesday, March 22, 2016 4:30 AM
> 
> On Tue, Mar 22, 2016 at 11:21:25AM +, Richardson, Bruce wrote:
> > I've had a quick scan over this patchset, and as you've probably seen I've
> made some public comments on it. General comments on the whole
> patchset are:
> > * Please run checkpatch on the patchset and clear up as many issues as
> > you can. There are a number of typos called out which especially must
> > be fixed. Both myself and Thomas always run checkpatch against patches
> > before applying them. [I suggest using Thomas's checkpatches.sh script
> > to do the checks as it disables many unnecessary warnings from
> > checkpatch]
> > * Please put in commit descriptions for all patches bar those doing trivial
> things. The first three patches probably don't need a commit message, but
> the rest do.
> >
> > /Bruce
> >
> > > -Original Message-
> > > From: Rasesh Mody [mailto:rasesh.mody at qlogic.com]
> > > Sent: Saturday, March 19, 2016 12:53 AM
> > > To: thomas.monjalon at 6wind.com; Richardson, Bruce
> > > 
> > > Cc: dev at dpdk.org; ameen.rahman at qlogic.com; harish.patil at 
> > > qlogic.com;
> > > sony.chacko at qlogic.com; Rasesh Mody 
> > > Subject: [PATCH v3 00/10] qede: Add qede PMD
> > >
> > > Submitting v3 patch series for QEDE PMD. There is no code change
> > > from v2 series except PMD version change. Earlier we had generated
> > > and tested the
> > > v2 series against dpdk tree then latest.
> > >
> > > The v3 series includes:
> > >  - Patches generated and tested against latest dpdk-next-net
> > >  - Reworked MAINTAINERS patch to make it apply cleanly
> > >  - Incorporated Overview.rst update in the documentation patch
> > >
> > > Please Apply.
> > >
> > > Thanks!
> > > Rasesh
> > >
> > > Rasesh Mody (10):
> > >   qede: Add maintainers
> > >   qede: Add documentation
> > >   qede: Add license file
> > >   qede: Add base driver
> > >   qede: Add core driver
> > >   qede: Add L2 support
> > >   qede: Add SRIOV support
> > >   qede: Add attention support
> > >   qede: Add DCBX support
> > >   qede: Enable PMD build
> > >
> Clang gives a compile error after applying this patchset. Please investigate.
> 
> == Build drivers/net/qede
>   CC base/ecore_dev.o
> fatal error: unknown warning option '-Wno-shift-negative-value'; did you
> mean
>   '-Wno-shift-sign-overflow'? [-Wunknown-warning-option]
> /home/bruce/next-net/dpdk-next-net/mk/internal/rte.compile-
> pre.mk:126: recipe for target 'base/ecore_dev.o' failed
> 
> This is seen with clang 3.6 on Fedora 23.
>   "clang version 3.6.0 (tags/RELEASE_360/final)"

We had compiled all our previously submitted driver patches against clang v3.8 
on  RH7.1 and didn't see a similar error. The '-Wno-shift-negative-value' 
option got introduced after 3.6.0 release.  Pls. let us know if we need to 
support a minimum version of clang. 
"clang version 3.8.0 (trunk 249596) (llvm/trunk 249595)"

> Similarly, 32-bit (i686) build fails:
> 
> == Build drivers/net/qede
>   CC base/ecore_dev.o
> /home/bruce/next-net/dpdk-next-
> net/drivers/net/qede/base/ecore_dev.c: In function
> ?ecore_chain_alloc_sanity_check?:
> /home/bruce/next-net/dpdk-next-
> net/drivers/net/qede/base/ecore_dev.c:2571:32: error: format ?%lx?
> expects argument of type ?long unsigned int?, but argument 6 has type ?u64
> {aka long long unsigned int}? [-Werror=format=] compilation terminated due
> to -Wfatal-errors.
> cc1: all warnings being treated as errors
> 
> This is seen with gcc 5.3.1 on Fedora 23.

For 32-bit, we are preparing our driver to compile against gcc version 4.3.4.

Similary, we had compile tested all our previously submitted driver patches on 
FreeBSD using:
FreeBSD clang version 3.6.1 and
gcc version 4.8.5

Thanks!
Rasesh

> Regards,
> /Bruce

[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

[Lazaros Koromilas]

On Tue, Mar 29, 2016 at 7:04 PM, Bruce Richardson
 wrote:
>
> On Tue, Mar 29, 2016 at 05:29:12PM +0200, Olivier MATZ wrote:
> > Hi,
> >
> >
> > On 03/29/2016 10:54 AM, Bruce Richardson wrote:
> > >On Mon, Mar 28, 2016 at 06:48:07PM +0300, Lazaros Koromilas wrote:
> > >>Hi Olivier,
> > >>
> > >>We could have two threads (running on different cores in the general
> > >>case) that both succeed the cmpset operation. In the dequeue path,
> > >>when n == 0, then cons_next == cons_head, and cmpset will always
> > >>succeed. Now, if they both see an old r->cons.tail value from a
> > >>previous dequeue, they can get stuck in the while
> > >
> > >Hi,
> > >
> > >I don't see how threads reading an "old r->cons.tail" value is even 
> > >possible.
> > >The head and tail pointers on the ring are marked in the code as volatile, 
> > >so
> > >all reads and writes to those values are always done from memory and not 
> > >cached
> > >in registers. No deadlock should be possible on that while loop, unless a
> > >process crashes in the middle of a ring operation. Each thread which 
> > >updates
> > >the head pointer from x to y, is responsible for updating the tail pointer 
> > >in
> > >a similar manner. The loop ensures the tail updates are in the same order 
> > >as the
> > >head updates.
> > >
> > >If you believe deadlock is possible, can you outline the sequence of 
> > >operations
> > >which would lead to such a state, because I cannot see how it could occur 
> > >without
> > >a crash inside one of the threads.
> >
> > I think the deadlock Lazaros describes could occur in the following
> > condition:
> >
> > current ring state
> >  r->prod.head = 0
> >  r->prod.tail = 0
> >
> > core 0   core 1
> > 
> > enqueue 0 object
> >  cmpset(>prod.head, 0, 0)
> >  core 0 is interrupted here
> >  enqueue 1 object
> >   cmpset(>prod.head, 0, 1)
> >   copy the objects in box 0
> >   while (r->prod.tail != prod_head))
> >   r->prod.tail = prod_next
> >  copy 0 object (-> nothing to do)
> >  while (r->prod.tail != prod_head))
> > 
> >
> >
> > I think this issue is indeed fixed by Lazaros' patch (I missed it
> > in previous review). However, I don't think this deadlock could
> > happen once we avoided the (n == 0) case.
> >
> Yes, I agree with your scenario. However, I thought the issue was occuring 
> with
> non-zero updates, but I may well be mistaken.
> If it's fixed now, all good... :-)
>
> /Bruce

Hi all,

Bruce, I thought it could be still possible because of my threads
being stuck inside two dequeue(32) calls.  But haven't been able to
reproduce it with non-zero dequeues.  And by trying to find a scenario
of my own, it seems that at least one dequeue(0) is needed, similarly
to Olivier's example on the enqueue path.

Thanks,
Lazaros.

[dpdk-dev] [PATCH] dpdk_qat: fix error message in Makefile

[Pablo de Lara]

When compiling dpdk_qat app with an i686 target on a x86_64 OS,
an error message was shown, saying that it can only be built
on a 32-bit OS, which should be i686 OS, as other 32-bit OS
are not supported.

Fixes: commit 3460012bcce6 ("examples/qat: update")

Signed-off-by: Pablo de Lara 
---
 examples/dpdk_qat/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/dpdk_qat/Makefile b/examples/dpdk_qat/Makefile
index f1e06a1..01d61bc 100644
--- a/examples/dpdk_qat/Makefile
+++ b/examples/dpdk_qat/Makefile
@@ -53,7 +53,7 @@ ifeq ($(CROSS_COMPILE),)
 ifneq ($(LBITS),i686)
 $(error The RTE_TARGET chosen is not compatible with this environment \
 (x86_64), for this application. Please change the definition of the \
-RTE_TARGET environment variable, or run the application on a 32-bit OS)
+RTE_TARGET environment variable, or run the application on a i686 OS)
 endif
 endif
 endif
-- 
2.5.5

[dpdk-dev] DPDK: receive single packet at a time

[Mohan Prasad]

Even I am using "82599ES 10-Gigabit SFI/SFP+ Network Connection" card only.

I am able to send single packet but not able to receive single packets, I
can receive burst only.

I am just building an application for tcp connection on dpdk. Anyways will
try disabling vector PMD and give it a try

Thanks,
Mohan

On Tue, Mar 29, 2016 at 6:38 PM, Wiles, Keith  wrote:

> From:  Mohan Prasad 
> Date:  Tuesday, March 29, 2016 at 8:01 AM
> To:  Keith Wiles 
> Cc:  "dev at dpdk.org" 
> Subject:  Re: [dpdk-dev] DPDK: receive single packet at a time
>
>
> >Hi,
> >I have tried this and it does not work
>
> Then something else is wrong as this work in Pktgen-DPDK, I can send one
> packet and receive one packet even when I ask for 32 packets at a time. Are
> you receiving any packets?
>
> I am using a 82599 NIC and if you are using some other type of NIC, I will
> not be able to help much.
>
> >Thanks,
> >Mohan
> >On Mar 29, 2016 6:26 PM, "Wiles, Keith"  wrote:
> >
> >>Hi,
> >>
> >>Is there any option to receive single packet at a time with dpdk?
> >
> >Not sure if this is the answer you are looking for, but if you just
> request a single packet with
> >
> >struct rte_mbuf *mbuf;
> >rte_eth_rx_burst(port_id, queue_id, , 1);
> >
> >will return only one packet as a time.
> >>
> >>Thanks,
> >>Mohan
> >>
> >
> >
> >Regards,
> >Keith
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> Regards,
> Keith
>
>
>

[dpdk-dev] [PATCH v2] hash: fix typo in Doxygen comment

[Pablo de Lara]

rte_hash_set_cmp_func() had an incorrect Doxygen comment
for one of its parameters.

Fixes: 95da2f8e9c61 ("hash: customize compare function")

Signed-off-by: Pablo de Lara 
---

Changes in v2:
- Reworded Doxygen comment

 lib/librte_hash/rte_hash.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index 85fc416..ae00b65 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -114,7 +114,7 @@ rte_hash_create(const struct rte_hash_parameters *params);
  * in multi-process mode.
  *
  * @param h
- *   Hash table to reset
+ *   Hash table for which the function is to be changed
  * @param func
  *   New compare function
  */
-- 
2.5.5

[dpdk-dev] DPDK: receive single packet at a time

[Mohan Prasad]

Hi,

I have tried this and it does not work

Thanks,
Mohan
On Mar 29, 2016 6:26 PM, "Wiles, Keith"  wrote:

> >Hi,
> >
> >Is there any option to receive single packet at a time with dpdk?
>
> Not sure if this is the answer you are looking for, but if you just
> request a single packet with
>
> struct rte_mbuf *mbuf;
> rte_eth_rx_burst(port_id, queue_id, , 1);
>
> will return only one packet as a time.
> >
> >Thanks,
> >Mohan
> >
>
>
> Regards,
> Keith
>
>
>
>
>

[dpdk-dev] [PATCH 8/8] scripts: add verbose test build option

[Thomas Monjalon]

The option -v enables the verbose mode when testing a build.

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index 808e8e4..a486244 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -74,11 +74,13 @@ print_help () {

 J=$DPDK_MAKE_JOBS
 short=false
+unset verbose
 maxerr=-Wfatal-errors
-while getopts hj:s ARG ; do
+while getopts hj:sv ARG ; do
case $ARG in
j ) J=$OPTARG ;;
s ) short=true ;;
+   v ) verbose='V=1' ;;
h ) print_help ; exit 0 ;;
? ) print_usage ; exit 1 ;;
esac
@@ -193,17 +195,17 @@ for conf in $configs ; do

echo "== Build $dir"
make -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
-   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" O=$dir
+   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose O=$dir
! $short || break
echo "== Build examples for $dir"
export RTE_SDK=$(pwd)
export RTE_TARGET=$dir
make -j$J -sC examples \
-   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" \
+   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose \
O=$(readlink -m $dir/examples)
! echo $target | grep -q '^x86_64' || \
make -j$J -sC examples/performance-thread \
-   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" \
+   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose \
O=$(readlink -m $dir/examples/performance-thread)
unset RTE_TARGET
echo "## $dir done."
-- 
2.7.0

[dpdk-dev] [PATCH 7/8] scripts: hook build test config

[Thomas Monjalon]

Insert a hook at the end of the config procedure, after having
adapted the configuration to the environment variables and the options
passed to the script.
It allows to better tune the automatic configuration of the build tests
in a function located in the devel config file.

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index bd4b501..808e8e4 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -160,6 +160,7 @@ config () #   
sed -ri's,(KNI_VHOST.*=)n,\1y,' $1/.config
sed -ri   's,(SCHED_.*=)n,\1y,' $1/.config
sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config
+   build_config_hook $1 $2 $3

# Explicit enabler/disabler (uppercase)
for option in $(echo $3 | sed 's,[~+], &,g') ; do
@@ -173,6 +174,12 @@ config () #   
fi
 }

+# default empty hook to override in devel config
+build_config_hook () #   
+{
+   :
+}
+
 for conf in $configs ; do
target=$(echo $conf | sed 's,[~+].*,,')
# reload config with DPDK_TARGET set
-- 
2.7.0

[dpdk-dev] [PATCH 6/8] scripts: allow tuning any test build option

[Thomas Monjalon]

Any build option can be enabled or disabled by appending the end
of its name to the config name.
Examples:
+INTRINSICS to enable CONFIG_RTE_FORCE_INTRINSICS
~RXTX_CALLBACKS to disable CONFIG_RTE_ETHDEV_RXTX_CALLBACKS

These builtin (lowercase) options are also added for convenience:
+debug to enable every debug options
+default to set target machine as default

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 46 --
 1 file changed, 32 insertions(+), 14 deletions(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index f28c289..bd4b501 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -34,7 +34,7 @@ default_path=$PATH

 # Load config options:
 # - AESNI_MULTI_BUFFER_LIB_PATH
-# - DPDK_BUILD_TEST_CONFIGS (target1+option1+option2 target2)
+# - DPDK_BUILD_TEST_CONFIGS (defconfig1+option1+option2 defconfig2)
 # - DPDK_DEP_CFLAGS
 # - DPDK_DEP_LDFLAGS
 # - DPDK_DEP_MOFED (y/[n])
@@ -61,10 +61,14 @@ print_help () {
-jX   use X parallel jobs in "make"
-sshort test with only first config without examples/doc

-   config: defconfig name followed by switches delimited with "+" sign
-   Example: x86_64-native-linuxapp-gcc+next+shared
-   Default is to enable most of the options.
+   config: defconfig[[~][+]option1[[~][+]option2...]]
+   Example: x86_64-native-linuxapp-gcc+debug~RXTX_CALLBACKS
+   The lowercase options are defined inside $(basename $0).
+   The uppercase options can be the end of a defconfig option
+   to enable if prefixed with '+' or to disable if prefixed with 
'~'.
+   Default is to automatically enable most of the options.
The external dependencies are setup with DPDK_DEP_* variables.
+   If no config on command line, DPDK_BUILD_TEST_CONFIGS is used.
END_OF_HELP
 }

@@ -120,10 +124,19 @@ config () #   
if [ ! -e $1/.config ] ; then
echo "== Configure $1"
make T=$2 O=$1 config
-   echo $3 | grep -q next || \
+
+   echo 'Customize configuration'
+   # Built-in options (lowercase)
+   ! echo $3 | grep -q '+default' || \
+   sed -ri 's,(RTE_MACHINE=")native,\1default,' $1/.config
+   echo $3 | grep -q '+next' || \
sed -ri   's,(NEXT_ABI=)y,\1n,' $1/.config
-   ! echo $3 | grep -q shared || \
+   ! echo $3 | grep -q '+shared' || \
sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
+   ! echo $3 | grep -q '+debug' || \
+   sed -ri's,(DEBUG.*=)n,\1y,' $1/.config
+
+   # Automatic configuration
! echo $2 | grep -q '^x86_64' || \
sed -ri   's,(NUMA=)n,\1y,' $1/.config
sed -ri 's,(PCI_CONFIG=)n,\1y,' $1/.config
@@ -147,23 +160,28 @@ config () #   
sed -ri's,(KNI_VHOST.*=)n,\1y,' $1/.config
sed -ri   's,(SCHED_.*=)n,\1y,' $1/.config
sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config
-   sed -ri's,(DEBUG.*=)n,\1y,' $1/.config
+
+   # Explicit enabler/disabler (uppercase)
+   for option in $(echo $3 | sed 's,[~+], &,g') ; do
+   pattern=$(echo $option | cut -c2-)
+   if echo $option | grep -q '^~' ; then
+   sed -ri "s,($pattern=)y,\1n," $1/.config
+   elif echo $option | grep -q '^+' ; then
+   sed -ri "s,($pattern=)n,\1y," $1/.config
+   fi
+   done
fi
 }

 for conf in $configs ; do
-   target=$(echo $conf | cut -d'+' -f1)
+   target=$(echo $conf | sed 's,[~+].*,,')
# reload config with DPDK_TARGET set
DPDK_TARGET=$target
reset_env
. $(dirname $(readlink -e $0))/load-devel-config.sh

-   options=$(echo $conf | cut -d'+' -sf2- --output-delimiter='-')
-   if [ -z "$options" ] ; then
-   dir=$target
-   else
-   dir=$target-$options
-   fi
+   options=$(echo $conf | sed 's,[^~+]*,,')
+   dir=$conf
config $dir $target $options

echo "== Build $dir"
-- 
2.7.0

[dpdk-dev] [PATCH 5/8] scripts: allow tuning build options per test target

[Thomas Monjalon]

The global variables are reloaded between each build to allow
having different config options based on DPDK_TARGET.

Some checks can now be removed from the script as they can
be done in the devel config file.

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index ffa7bea..f28c289 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -30,6 +30,8 @@
 # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

+default_path=$PATH
+
 # Load config options:
 # - AESNI_MULTI_BUFFER_LIB_PATH
 # - DPDK_BUILD_TEST_CONFIGS (target1+option1+option2 target2)
@@ -37,6 +39,10 @@
 # - DPDK_DEP_LDFLAGS
 # - DPDK_DEP_MOFED (y/[n])
 # - DPDK_DEP_PCAP (y/[n])
+# - DPDK_DEP_SSL (y/[n])
+# - DPDK_DEP_SZE (y/[n])
+# - DPDK_DEP_ZLIB (y/[n])
+# - DPDK_MAKE_JOBS (int)
 # - DPDK_NOTIFY (notify-send)
 . $(dirname $(readlink -e $0))/load-devel-config.sh

@@ -94,6 +100,21 @@ trap on_exit EXIT

 cd $(dirname $(readlink -m $0))/..

+reset_env ()
+{
+   export PATH=$default_path
+   unset CROSS
+   unset DPDK_DEP_CFLAGS
+   unset DPDK_DEP_LDFLAGS
+   unset DPDK_DEP_MOFED
+   unset DPDK_DEP_PCAP
+   unset DPDK_DEP_SSL
+   unset DPDK_DEP_SZE
+   unset DPDK_DEP_ZLIB
+   unset AESNI_MULTI_BUFFER_LIB_PATH
+   unset PQOS_INSTALL_PATH
+}
+
 config () #   
 {
if [ ! -e $1/.config ] ; then
@@ -103,16 +124,14 @@ config () #   
sed -ri   's,(NEXT_ABI=)y,\1n,' $1/.config
! echo $3 | grep -q shared || \
sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
-   echo $2 | grep -q '^i686' || \
+   ! echo $2 | grep -q '^x86_64' || \
sed -ri   's,(NUMA=)n,\1y,' $1/.config
sed -ri 's,(PCI_CONFIG=)n,\1y,' $1/.config
sed -ri's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
sed -ri 's,(BYPASS=)n,\1y,' $1/.config
test "$DPDK_DEP_MOFED" != y || \
-   echo $2 | grep -q '^clang$' || \
sed -ri   's,(MLX._PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_SZE" != y || \
-   echo $2 | grep -q '^i686' || \
sed -ri   's,(PMD_SZEDATA2=)n,\1y,' $1/.config
test "$DPDK_DEP_ZLIB" != y || \
sed -ri  's,(BNX2X_PMD=)n,\1y,' $1/.config
@@ -120,17 +139,13 @@ config () #   
test "$DPDK_DEP_PCAP" != y || \
sed -ri   's,(PCAP=)n,\1y,' $1/.config
test -z "$AESNI_MULTI_BUFFER_LIB_PATH" || \
-   ! echo $2 | grep -q '^x86_64' || \
sed -ri   's,(PMD_AESNI_MB=)n,\1y,' $1/.config
test -z "$AESNI_MULTI_BUFFER_LIB_PATH" || \
-   ! echo $2 | grep -q '^x86_64' || \
sed -ri  's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
test "$DPDK_DEP_SSL" != y || \
sed -ri's,(PMD_QAT=)n,\1y,' $1/.config
sed -ri's,(KNI_VHOST.*=)n,\1y,' $1/.config
sed -ri   's,(SCHED_.*=)n,\1y,' $1/.config
-   ! echo $2 | grep -q '^i686' || \
-   sed -ri  's,(POWER=)y,\1n,' $1/.config
sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config
sed -ri's,(DEBUG.*=)n,\1y,' $1/.config
fi
@@ -138,6 +153,11 @@ config () #   

 for conf in $configs ; do
target=$(echo $conf | cut -d'+' -f1)
+   # reload config with DPDK_TARGET set
+   DPDK_TARGET=$target
+   reset_env
+   . $(dirname $(readlink -e $0))/load-devel-config.sh
+
options=$(echo $conf | cut -d'+' -sf2- --output-delimiter='-')
if [ -z "$options" ] ; then
dir=$target
-- 
2.7.0

[dpdk-dev] [PATCH 4/8] scripts: stop build test after first error

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index ffad7ee..ffa7bea 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -64,6 +64,7 @@ print_help () {

 J=$DPDK_MAKE_JOBS
 short=false
+maxerr=-Wfatal-errors
 while getopts hj:s ARG ; do
case $ARG in
j ) J=$OPTARG ;;
@@ -146,7 +147,7 @@ for conf in $configs ; do
config $dir $target $options

echo "== Build $dir"
-   make -j$J EXTRA_CFLAGS="$DPDK_DEP_CFLAGS" \
+   make -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" O=$dir
! $short || break
echo "== Build examples for $dir"
-- 
2.7.0

[dpdk-dev] [PATCH 3/8] scripts: test build of performance-thread example

[Thomas Monjalon]

This example is not part of the baseline because of its
experimental state. That's why it must be tested separately.

Fixes: b700090c8cec ("examples/performance-thread: mark as experimental")

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index b23d6c8..ffad7ee 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -155,6 +155,10 @@ for conf in $configs ; do
make -j$J -sC examples \
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" \
O=$(readlink -m $dir/examples)
+   ! echo $target | grep -q '^x86_64' || \
+   make -j$J -sC examples/performance-thread \
+   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" \
+   O=$(readlink -m $dir/examples/performance-thread)
unset RTE_TARGET
echo "## $dir done."
 done
-- 
2.7.0

[dpdk-dev] [PATCH 2/8] scripts: remove legacy build method test

[Thomas Monjalon]

Building with "make install T=" is now deprecated.
The script will test only the standard "make" command.

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index be8275e..b23d6c8 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -96,7 +96,7 @@ cd $(dirname $(readlink -m $0))/..
 config () #   
 {
if [ ! -e $1/.config ] ; then
-   echo Custom configuration
+   echo "== Configure $1"
make T=$2 O=$1 config
echo $3 | grep -q next || \
sed -ri   's,(NEXT_ABI=)y,\1n,' $1/.config
@@ -140,21 +140,23 @@ for conf in $configs ; do
options=$(echo $conf | cut -d'+' -sf2- --output-delimiter='-')
if [ -z "$options" ] ; then
dir=$target
-   config $dir $target
-   # Use install rule
-   make -j$J T=$target install EXTRA_CFLAGS="$DPDK_DEP_CFLAGS" 
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS"
-   $short || make -j$J T=$target examples O=$dir/examples 
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS"
else
dir=$target-$options
-   config $dir $target $options
-   echo "== Build $dir"
-   # Use O variable without install
-   make -j$J O=$dir EXTRA_CFLAGS="$DPDK_DEP_CFLAGS" 
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS"
-   echo "== Build examples for $dir"
-   make -j$J -sC examples RTE_SDK=$(pwd) RTE_TARGET=$dir 
O=$(readlink -m $dir/examples) EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS"
fi
-   echo "## $dir done."
+   config $dir $target $options
+
+   echo "== Build $dir"
+   make -j$J EXTRA_CFLAGS="$DPDK_DEP_CFLAGS" \
+   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" O=$dir
! $short || break
+   echo "== Build examples for $dir"
+   export RTE_SDK=$(pwd)
+   export RTE_TARGET=$dir
+   make -j$J -sC examples \
+   EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" \
+   O=$(readlink -m $dir/examples)
+   unset RTE_TARGET
+   echo "## $dir done."
 done

 if ! $short ; then
-- 
2.7.0

[dpdk-dev] [PATCH 1/8] scripts: fix run in any directory

[Thomas Monjalon]

The path to load-devel-config.sh must be relative to the script.

Signed-off-by: Thomas Monjalon 
---
 scripts/checkpatches.sh | 2 +-
 scripts/test-build.sh   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
index fcb24fd..5c58a20 100755
--- a/scripts/checkpatches.sh
+++ b/scripts/checkpatches.sh
@@ -33,7 +33,7 @@
 # Load config options:
 # - DPDK_CHECKPATCH_PATH
 # - DPDK_CHECKPATCH_LINE_LENGTH
-. scripts/load-devel-config.sh
+. $(dirname $(readlink -e $0))/load-devel-config.sh

 length=${DPDK_CHECKPATCH_LINE_LENGTH:-80}

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index 5f3cab5..be8275e 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -38,7 +38,7 @@
 # - DPDK_DEP_MOFED (y/[n])
 # - DPDK_DEP_PCAP (y/[n])
 # - DPDK_NOTIFY (notify-send)
-. scripts/load-devel-config.sh
+. $(dirname $(readlink -e $0))/load-devel-config.sh

 print_usage () {
echo "usage: $(basename $0) [-h] [-jX] [-s] [config1 [config2] ...]]"
-- 
2.7.0

[dpdk-dev] [PATCH 0/8] simpler and better build test

[Thomas Monjalon]

These are some improvements to the script test-build.sh which
makes compilation testing easier in various environments with
different dependencies.

Thomas Monjalon (8):
  scripts: fix run in any directory
  scripts: remove legacy build method test
  scripts: test build of performance-thread example
  scripts: stop build test after first error
  scripts: allow tuning build options per test target
  scripts: allow tuning any test build option
  scripts: hook build test config
  scripts: add verbose test build option

 scripts/checkpatches.sh |   2 +-
 scripts/test-build.sh   | 124 ++--
 2 files changed, 90 insertions(+), 36 deletions(-)

-- 
2.7.0

[dpdk-dev] [PATCH] qat: Fix for crash when nb_ops=0 on enqueue_burst

[Fiona Trahe]

Crash seen in qat pmd when nb_ops=0 on rte_cryptodev_enqueue_burst() API

Signed-off-by: Fiona Trahe 
---
 drivers/crypto/qat/qat_crypto.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 5c41a89..90b5e6c 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -570,6 +570,9 @@ qat_pmd_enqueue_op_burst(void *qp, struct rte_crypto_op 
**ops,
register uint32_t tail;
int overflow;

+   if (unlikely(nb_ops == 0))
+   return 0;
+
/* read params used a lot in main loop into registers */
queue = &(tmp_qp->tx_q);
base_addr = (uint8_t *)queue->base_addr;
-- 
1.7.0.7

[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

[Olivier MATZ]

Hi,


On 03/29/2016 10:54 AM, Bruce Richardson wrote:
> On Mon, Mar 28, 2016 at 06:48:07PM +0300, Lazaros Koromilas wrote:
>> Hi Olivier,
>>
>> We could have two threads (running on different cores in the general
>> case) that both succeed the cmpset operation. In the dequeue path,
>> when n == 0, then cons_next == cons_head, and cmpset will always
>> succeed. Now, if they both see an old r->cons.tail value from a
>> previous dequeue, they can get stuck in the while
>
> Hi,
>
> I don't see how threads reading an "old r->cons.tail" value is even possible.
> The head and tail pointers on the ring are marked in the code as volatile, so
> all reads and writes to those values are always done from memory and not 
> cached
> in registers. No deadlock should be possible on that while loop, unless a
> process crashes in the middle of a ring operation. Each thread which updates
> the head pointer from x to y, is responsible for updating the tail pointer in
> a similar manner. The loop ensures the tail updates are in the same order as 
> the
> head updates.
>
> If you believe deadlock is possible, can you outline the sequence of 
> operations
> which would lead to such a state, because I cannot see how it could occur 
> without
> a crash inside one of the threads.

I think the deadlock Lazaros describes could occur in the following
condition:

current ring state
  r->prod.head = 0
  r->prod.tail = 0

core 0   core 1

enqueue 0 object
  cmpset(>prod.head, 0, 0)
  core 0 is interrupted here
  enqueue 1 object
   cmpset(>prod.head, 0, 1)
   copy the objects in box 0
   while (r->prod.tail != prod_head))
   r->prod.tail = prod_next
  copy 0 object (-> nothing to do)
  while (r->prod.tail != prod_head))
 


I think this issue is indeed fixed by Lazaros' patch (I missed it
in previous review). However, I don't think this deadlock could
happen once we avoided the (n == 0) case.


Olivier

[dpdk-dev] Issue with binding NIC of type 82545EM to dpdk

[Ferruh Yigit]

On 3/29/2016 3:11 PM, Al Patel wrote:
> Hi,
> 
> I am having an issue with binding a nic of type 82545EM to dpdk. I am using
> a
> fedoracore23 VM on MAC with VMFusion.
> 
> ./dpdk_nic_bind.py -b uio_pci_generic :02:02.0
> Error: bind failed for :02:02.0 - Cannot bind to driver uio_pci_generic
> Error: unbind failed for :02:02.0 - Cannot open
> /sys/bus/pci/drivers//unbind
> 
> it is unbound from e1000, repeating the command:
> 
> ./dpdk_nic_bind.py -b uio_pci_generic :02:02.0
> Error: bind failed for :02:02.0 - Cannot bind to driver uio_pci_generic
> 
> I repeated the same test on a ubuntu vm running on Virtualbox with
> NIC type 82450EM
> 
> In this case, the device is able to bind successfully to uio_pci_generic
> driver.
> 
> There is a igb_uio module that present. The device cannot be bound to the
> igb_uio
> driver.

Hi Al,

You are trying to bind to the driver "uio_pci_generic" not to the
"igb_uio", is it typo? If not, can you please double check if
"uio_pci_generic" module inserted.
Or bind device to "igb_uio":
"./dpdk_nic_bind.py -b igb_uio :02:02.0"

Regards,
ferruh

[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

[Bruce Richardson]

On Tue, Mar 29, 2016 at 05:29:12PM +0200, Olivier MATZ wrote:
> Hi,
> 
> 
> On 03/29/2016 10:54 AM, Bruce Richardson wrote:
> >On Mon, Mar 28, 2016 at 06:48:07PM +0300, Lazaros Koromilas wrote:
> >>Hi Olivier,
> >>
> >>We could have two threads (running on different cores in the general
> >>case) that both succeed the cmpset operation. In the dequeue path,
> >>when n == 0, then cons_next == cons_head, and cmpset will always
> >>succeed. Now, if they both see an old r->cons.tail value from a
> >>previous dequeue, they can get stuck in the while
> >
> >Hi,
> >
> >I don't see how threads reading an "old r->cons.tail" value is even possible.
> >The head and tail pointers on the ring are marked in the code as volatile, so
> >all reads and writes to those values are always done from memory and not 
> >cached
> >in registers. No deadlock should be possible on that while loop, unless a
> >process crashes in the middle of a ring operation. Each thread which updates
> >the head pointer from x to y, is responsible for updating the tail pointer in
> >a similar manner. The loop ensures the tail updates are in the same order as 
> >the
> >head updates.
> >
> >If you believe deadlock is possible, can you outline the sequence of 
> >operations
> >which would lead to such a state, because I cannot see how it could occur 
> >without
> >a crash inside one of the threads.
> 
> I think the deadlock Lazaros describes could occur in the following
> condition:
> 
> current ring state
>  r->prod.head = 0
>  r->prod.tail = 0
> 
> core 0   core 1
> 
> enqueue 0 object
>  cmpset(>prod.head, 0, 0)
>  core 0 is interrupted here
>  enqueue 1 object
>   cmpset(>prod.head, 0, 1)
>   copy the objects in box 0
>   while (r->prod.tail != prod_head))
>   r->prod.tail = prod_next
>  copy 0 object (-> nothing to do)
>  while (r->prod.tail != prod_head))
> 
> 
> 
> I think this issue is indeed fixed by Lazaros' patch (I missed it
> in previous review). However, I don't think this deadlock could
> happen once we avoided the (n == 0) case.
>
Yes, I agree with your scenario. However, I thought the issue was occuring with
non-zero updates, but I may well be mistaken.
If it's fixed now, all good... :-)

/Bruce

[dpdk-dev] [PATCH] hash: fix typo in Doxygen comment

[Bruce Richardson]

On Thu, Mar 24, 2016 at 02:27:46PM +, Pablo de Lara wrote:
> rte_hash_set_cmp_func() had an incorrect Doxygen comment
> for one of its parameters.
> 
> Fixes: 95da2f8e9c61 ("hash: customize compare function")
> 
> Signed-off-by: Pablo de Lara 
> ---
>  lib/librte_hash/rte_hash.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
> index 85fc416..add3414 100644
> --- a/lib/librte_hash/rte_hash.h
> +++ b/lib/librte_hash/rte_hash.h
> @@ -114,7 +114,7 @@ rte_hash_create(const struct rte_hash_parameters *params);
>   * in multi-process mode.
>   *
>   * @param h
> - *   Hash table to reset
> + *   Hash table to change the function

Good idea to change this. However, to read correctly, I think it might need to
be adjusted slightly. E.g.

* Hash table for which the function is to be changed
* Hash table to update

Regards,
/Bruce

>   * @param func
>   *   New compare function
>   */
> -- 
> 2.5.5
> 

[dpdk-dev] DPDK: receive single packet at a time

[Mohan Prasad]

Hi,

Is there any option to receive single packet at a time with dpdk?

Thanks,
Mohan

[dpdk-dev] [PATCH v2 2/2] ethdev: add ETH_RSS_RETA_SIZE_256

[Jerin Jacob]

Signed-off-by: Jerin Jacob 
---
 lib/librte_ether/rte_ethdev.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index a4eeeba..d93f85a 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -470,6 +470,7 @@ struct rte_eth_rss_conf {
  */
 #define ETH_RSS_RETA_SIZE_64  64
 #define ETH_RSS_RETA_SIZE_128 128
+#define ETH_RSS_RETA_SIZE_256 256
 #define ETH_RSS_RETA_SIZE_512 512
 #define RTE_RETA_GROUP_SIZE   64

-- 
2.1.0

[dpdk-dev] [PATCH v2 1/2] ethdev: add tunnel and port RSS offload types

[Jerin Jacob]

- added VXLAN, GENEVE and NVGRE tunnel flow types
- added PORT flow type for accounting physical/virtual
port or channel number in flow creation

Signed-off-by: Jerin Jacob 
---
 app/test-pmd/cmdline.c  | 18 +++---
 app/test-pmd/config.c   |  9 +
 lib/librte_ether/rte_eth_ctrl.h |  6 +-
 lib/librte_ether/rte_ethdev.h   | 16 +++-
 4 files changed, 44 insertions(+), 5 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 93203f4..5fe8239 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -565,7 +565,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"Set crc-strip/rx-checksum/hardware-vlan/drop_en"
" for ports.\n\n"

-   "port config all rss (all|ip|tcp|udp|sctp|ether|none)\n"
+   "port config all rss 
(all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)\n"
"Set the RSS mode.\n\n"

"port config port-id rss reta 
(hash,queue)[,(hash,queue)]\n"
@@ -1545,6 +1545,14 @@ cmd_config_rss_parsed(void *parsed_result,
rss_conf.rss_hf = ETH_RSS_SCTP;
else if (!strcmp(res->value, "ether"))
rss_conf.rss_hf = ETH_RSS_L2_PAYLOAD;
+   else if (!strcmp(res->value, "port"))
+   rss_conf.rss_hf = ETH_RSS_PORT;
+   else if (!strcmp(res->value, "vxlan"))
+   rss_conf.rss_hf = ETH_RSS_VXLAN;
+   else if (!strcmp(res->value, "geneve"))
+   rss_conf.rss_hf = ETH_RSS_GENEVE;
+   else if (!strcmp(res->value, "nvgre"))
+   rss_conf.rss_hf = ETH_RSS_NVGRE;
else if (!strcmp(res->value, "none"))
rss_conf.rss_hf = 0;
else {
@@ -1566,12 +1574,12 @@ cmdline_parse_token_string_t cmd_config_rss_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss, name, "rss");
 cmdline_parse_token_string_t cmd_config_rss_value =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss, value,
-   "all#ip#tcp#udp#sctp#ether#none");
+   "all#ip#tcp#udp#sctp#ether#port#vxlan#geneve#nvgre#none");

 cmdline_parse_inst_t cmd_config_rss = {
.f = cmd_config_rss_parsed,
.data = NULL,
-   .help_str = "port config all rss all|ip|tcp|udp|sctp|ether|none",
+   .help_str = "port config all rss 
all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none",
.tokens = {
(void *)_config_rss_port,
(void *)_config_rss_keyword,
@@ -9304,6 +9312,10 @@ flowtype_to_str(uint16_t ftype)
{"ipv6-sctp", RTE_ETH_FLOW_NONFRAG_IPV6_SCTP},
{"ipv6-other", RTE_ETH_FLOW_NONFRAG_IPV6_OTHER},
{"l2_payload", RTE_ETH_FLOW_L2_PAYLOAD},
+   {"port", RTE_ETH_FLOW_PORT},
+   {"vxlan", RTE_ETH_FLOW_VXLAN},
+   {"geneve", RTE_ETH_FLOW_GENEVE},
+   {"nvgre", RTE_ETH_FLOW_NVGRE},
};

for (i = 0; i < RTE_DIM(ftype_table); i++) {
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index b1bbec6..0b3619d 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -137,6 +137,11 @@ static const struct rss_type_info rss_type_table[] = {
{ "ipv6-ex", ETH_RSS_IPV6_EX },
{ "ipv6-tcp-ex", ETH_RSS_IPV6_TCP_EX },
{ "ipv6-udp-ex", ETH_RSS_IPV6_UDP_EX },
+   { "port", ETH_RSS_PORT },
+   { "vxlan", ETH_RSS_VXLAN },
+   { "geneve", ETH_RSS_GENEVE },
+   { "nvgre", ETH_RSS_NVGRE },
+
 };

 static void
@@ -2028,6 +2033,10 @@ flowtype_to_str(uint16_t flow_type)
{"ipv6-sctp", RTE_ETH_FLOW_NONFRAG_IPV6_SCTP},
{"ipv6-other", RTE_ETH_FLOW_NONFRAG_IPV6_OTHER},
{"l2_payload", RTE_ETH_FLOW_L2_PAYLOAD},
+   {"port", RTE_ETH_FLOW_PORT},
+   {"vxlan", RTE_ETH_FLOW_VXLAN},
+   {"geneve", RTE_ETH_FLOW_GENEVE},
+   {"nvgre", RTE_ETH_FLOW_NVGRE},
};

for (i = 0; i < RTE_DIM(flowtype_str_table); i++) {
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index aabd724..d57e967 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -74,7 +74,11 @@ extern "C" {
 #define RTE_ETH_FLOW_IPV6_EX15
 #define RTE_ETH_FLOW_IPV6_TCP_EX16
 #define RTE_ETH_FLOW_IPV6_UDP_EX17
-#define RTE_ETH_FLOW_MAX18
+#define RTE_ETH_FLOW_PORT   18
+#define RTE_ETH_FLOW_VXLAN  19
+#define RTE_ETH_FLOW_GENEVE 20
+#define RTE_ETH_FLOW_NVGRE  21
+#define RTE_ETH_FLOW_MAX22

 /**
  * Feature filter types
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index e7de34a..a4eeeba 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -406,6 +406,10 @@ struct rte_eth_rss_conf {
 #define ETH_RSS_IPV6_EX(1ULL 

[dpdk-dev] [PATCH v2 0/2] New RSS offload flags

[Jerin Jacob]

v1..v2
- Added cover letter
- Corrected typo in RET_ETH_FLOW_VXLAN name
- Updated test-pmd application to access newly defined RSS offload flags

Jerin Jacob (2):
  ethdev: add tunnel and port RSS offload types
  ethdev: add ETH_RSS_RETA_SIZE_256

 app/test-pmd/cmdline.c  | 18 +++---
 app/test-pmd/config.c   |  9 +
 lib/librte_ether/rte_eth_ctrl.h |  6 +-
 lib/librte_ether/rte_ethdev.h   | 17 -
 4 files changed, 45 insertions(+), 5 deletions(-)

-- 
2.1.0

[dpdk-dev] [PATCH v2 2/2] app/test: added test for out-of-place symmetric operations

[Fiona Trahe]

From: Arek Kusztal 

Added AES and snow3g Authenticated encryption and decryption tests for 
out-of-place operations.

Signed-off-by: Arek Kusztal 
---
 app/test/test_cryptodev.c |  495 -
 1 files changed, 491 insertions(+), 4 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 2494bae..0c26804 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -101,12 +101,27 @@ setup_test_string(struct rte_mempool *mpool,
rte_pktmbuf_free(m);
return NULL;
}
-
-   rte_memcpy(dst, string, t_len);
+   if (string != NULL)
+   rte_memcpy(dst, string, t_len);
+   else
+   memset(dst, 0, t_len);
}

return m;
 }
+static int
+setup_oop_test_mbufs(struct rte_mbuf **ibuf, struct rte_mbuf **obuf,
+   struct rte_mempool *mpool,  const char *string, size_t len,
+   uint8_t blocksize) {
+   *ibuf = setup_test_string(mpool, string, len, blocksize);
+   if (*ibuf == NULL)
+   return -(EFAULT);
+   *obuf = setup_test_string(mpool, NULL, len, blocksize);
+   if (*obuf == NULL)
+   return -(EFAULT);
+
+   return 0;
+}

 #if HEX_DUMP
 static void
@@ -907,6 +922,241 @@ test_AES_CBC_HMAC_SHA1_encrypt_digest(void)
return TEST_SUCCESS;
 }

+
+static int
+test_AES_CBC_HMAC_SHA1_encrypt_digest_oop(void)
+{
+   struct crypto_testsuite_params *ts_params = _params;
+   struct crypto_unittest_params *ut_params = _params;
+
+   /* Generate test mbuf data and space for digest */
+
+   TEST_ASSERT_EQUAL(setup_oop_test_mbufs(_params->ibuf,
+   _params->obuf, ts_params->mbuf_pool, catch_22_quote,
+   QUOTE_512_BYTES, 0), 0,
+   "Allocation of rte_mbuf failed");
+
+   ut_params->digest = (uint8_t *)rte_pktmbuf_append(ut_params->obuf,
+   DIGEST_BYTE_LENGTH_SHA1);
+
+   TEST_ASSERT_NOT_NULL(ut_params->digest, "no room to append digest");
+
+   ut_params->cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
+   ut_params->cipher_xform.next = _params->auth_xform;
+
+   ut_params->cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_AES_CBC;
+   ut_params->cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
+   ut_params->cipher_xform.cipher.key.data = aes_cbc_key;
+   ut_params->cipher_xform.cipher.key.length = CIPHER_KEY_LENGTH_AES_CBC;
+
+   ut_params->auth_xform.type = RTE_CRYPTO_SYM_XFORM_AUTH;
+   ut_params->auth_xform.next = NULL;
+
+   ut_params->auth_xform.auth.op = RTE_CRYPTO_AUTH_OP_GENERATE;
+   ut_params->auth_xform.auth.algo = RTE_CRYPTO_AUTH_SHA1_HMAC;
+   ut_params->auth_xform.auth.key.length = HMAC_KEY_LENGTH_SHA1;
+   ut_params->auth_xform.auth.key.data = hmac_sha1_key;
+   ut_params->auth_xform.auth.digest_length = DIGEST_BYTE_LENGTH_SHA1;
+
+   ut_params->sess = rte_cryptodev_sym_session_create(
+   ts_params->valid_devs[0],
+   _params->cipher_xform);
+
+   TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
+
+   ut_params->op = rte_crypto_op_alloc(ts_params->op_mpool,
+   RTE_CRYPTO_OP_TYPE_SYMMETRIC);
+
+
+   TEST_ASSERT_NOT_NULL(ut_params->op,
+   "Failed to allocate symmetric crypto operation struct");
+
+   rte_crypto_op_attach_sym_session(ut_params->op, ut_params->sess);
+
+   struct rte_crypto_sym_op *sym_op = ut_params->op->sym;
+
+   /* set crypto operation source mbuf */
+   sym_op->m_src = ut_params->ibuf;
+   sym_op->m_dst = ut_params->obuf;
+
+   sym_op->auth.digest.data = ut_params->digest;
+
+   sym_op->auth.digest.phys_addr = rte_pktmbuf_mtophys_offset(
+   ut_params->obuf, QUOTE_512_BYTES);
+
+   sym_op->auth.digest.length = DIGEST_BYTE_LENGTH_SHA1;
+   sym_op->auth.data.length = QUOTE_512_BYTES;
+
+   /* Set crypto operation cipher parameters */
+   sym_op->cipher.iv.data = (uint8_t *)rte_pktmbuf_prepend(ut_params->ibuf,
+   CIPHER_IV_LENGTH_AES_CBC);
+
+   TEST_ASSERT_NOT_NULL(sym_op->cipher.iv.data,
+   "Failed to prepend place for iv input");
+
+   TEST_ASSERT_NOT_NULL(rte_pktmbuf_prepend(ut_params->obuf,
+   CIPHER_IV_LENGTH_AES_CBC),
+   "Failed to prepend place for iv output");
+
+   sym_op->auth.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+
+   sym_op->cipher.iv.phys_addr = rte_pktmbuf_mtophys(ut_params->ibuf);
+   sym_op->cipher.iv.length = CIPHER_IV_LENGTH_AES_CBC;
+
+   rte_memcpy(sym_op->cipher.iv.data, aes_cbc_iv,
+   CIPHER_IV_LENGTH_AES_CBC);
+
+   sym_op->cipher.data.offset = CIPHER_IV_LENGTH_AES_CBC;

[dpdk-dev] [PATCH v2 1/2] driver/crypto: out-of-place symmetric operations

[Fiona Trahe]

From: Arek Kusztal 

This patch adds out-of-place operations to qat symmetric crypto PMD,
i.e. the result of the operation can be written to the destination buffer
instead of overwriting the source buffer as done in "in-place" operation.
Both buffers can be of different sizes.
Previously the qat PMD assumed that m_src and m_dst in rte_crypto_sym_op 
were identical.

Signed-off-by: Arek Kusztal 
---
 doc/guides/cryptodevs/qat.rst   |1 -
 drivers/crypto/qat/qat_crypto.c |   22 +-
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index af90b46..4b8f782 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -62,7 +62,6 @@ Limitations
 * Chained mbufs are not supported.
 * Hash only is not supported except Snow3G UIA2.
 * Cipher only is not supported except Snow3G UEA2.
-* Only in-place is currently supported (destination address is the same as 
source address).
 * Only supports the session-oriented API implementation (session-less APIs are 
not supported).
 * Not performance tuned.
 * Snow3g(UEA2) supported only if cipher length, cipher offset fields are 
byte-aligned.
diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 29c1fe5..55884d6 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -689,17 +689,21 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t 
*out_msg)
*qat_req = ctx->fw_req;
qat_req->comn_mid.opaque_data = (uint64_t)(uintptr_t)op;

-   /*
-* The following code assumes:
-* - single entry buffer.
-* - always in place.
-*/
qat_req->comn_mid.dst_length =
-   qat_req->comn_mid.src_length =
-   rte_pktmbuf_data_len(op->sym->m_src);
+   qat_req->comn_mid.src_length =
+   rte_pktmbuf_data_len(op->sym->m_src);
+
qat_req->comn_mid.dest_data_addr =
-   qat_req->comn_mid.src_data_addr =
-   rte_pktmbuf_mtophys(op->sym->m_src);
+   qat_req->comn_mid.src_data_addr =
+   rte_pktmbuf_mtophys(op->sym->m_src);
+
+   if (unlikely(op->sym->m_dst != NULL)) {
+   qat_req->comn_mid.dest_data_addr =
+   rte_pktmbuf_mtophys(op->sym->m_dst);
+   qat_req->comn_mid.dst_length =
+   rte_pktmbuf_data_len(op->sym->m_dst);
+   }
+
cipher_param = (void *)_req->serv_specif_rqpars;
auth_param = (void *)((uint8_t *)cipher_param + sizeof(*cipher_param));

-- 
1.7.0.7

[dpdk-dev] [PATCH v2 0/2] Out of place operations for symmetric crypto

[Fiona Trahe]

From: Arek Kusztal 

This patch adds out of place operations for qat symmetric crypto PMD,
i.e. the result of the operation can be written to the destination buffer 
instead of overwriting the source buffer as done in "in-place" operation.

v2:
 - updated commit message to clarify out-of-place meaning


Arek Kusztal (2):
  driver/crypto: out-of-place symmetric operations
  app/test: added test for out-of-place symmetric operations

 app/test/test_cryptodev.c   |  495 ++-
 doc/guides/cryptodevs/qat.rst   |1 -
 drivers/crypto/qat/qat_crypto.c |   22 +-
 3 files changed, 504 insertions(+), 14 deletions(-)

[dpdk-dev] [PATCH 2/2] ena: Fix Compilation for freebsd

[Daniel Mrzyglod]

FreeBSD was not defined in ena_plat.h
ETIME is not defined in FreeBSD.

In file included from DPDK/drivers/net/ena/base/ena_com.h:37:0,
 from DPDK/drivers/net/ena/ena_ethdev.h:39,
 from DPDK/drivers/net/ena/ena_ethdev.c:41:
DPDK/drivers/net/ena/base/ena_plat.h:48:2: error: #error "Invalid platform"
 #error "Invalid platform"
  ^
compilation terminated due to -Wfatal-errors.

Signed-off-by: Daniel Mrzyglod 
---
 drivers/net/ena/base/ena_plat.h  | 2 ++
 drivers/net/ena/base/ena_plat_dpdk.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/ena/base/ena_plat.h b/drivers/net/ena/base/ena_plat.h
index 278175f..b5b6454 100644
--- a/drivers/net/ena/base/ena_plat.h
+++ b/drivers/net/ena/base/ena_plat.h
@@ -42,6 +42,8 @@
 #else
 #include "ena_plat_dpdk.h"
 #endif
+#elif defined(__FreeBSD__)
+#include "ena_plat_dpdk.h"
 #elif defined(_WIN32)
 #include "ena_plat_windows.h"
 #else
diff --git a/drivers/net/ena/base/ena_plat_dpdk.h 
b/drivers/net/ena/base/ena_plat_dpdk.h
index e245e34..aab2ac8 100644
--- a/drivers/net/ena/base/ena_plat_dpdk.h
+++ b/drivers/net/ena/base/ena_plat_dpdk.h
@@ -57,6 +57,9 @@ typedef uint16_t u16;
 typedef uint8_t u8;

 typedef uint64_t dma_addr_t;
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif

 #define ena_atomic32_t rte_atomic32_t
 #define ena_mem_handle_t void *
-- 
2.5.5

[dpdk-dev] [PATCH 1/2] ena: icc fix compilation errors

[Daniel Mrzyglod]

Fix for multiple compilation errors for ICC
error #188: enumerated type mixed with another type
error #592: variable "flags" is used before its value is set

In file included from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.h(39),
 from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.c(41):
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.h(982): error 
#188: enumerated type mixed with another type
curr_moder_idx = *moder_tbl_idx;
   ^

In file included from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.h(39),
 from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.c(41):
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.h(994): error 
#188: enumerated type mixed with another type
new_moder_idx = curr_moder_idx + 1;
  ^

In file included from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.h(39),
 from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.c(41):
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.h(1000): error 
#188: enumerated type mixed with another type
new_moder_idx = curr_moder_idx - 1;
  ^

In file included from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.h(39),
 from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.c(41):
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.h(1004): error 
#188: enumerated type mixed with another type
new_moder_idx = curr_moder_idx + 1;
  ^

compilation aborted for 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/ena_ethdev.c (code 2)
/mnt/shared/dtmrzglx/hubabuba-ena/mk/internal/rte.compile-pre.mk:126: recipe 
for target 'ena_ethdev.o' failed
make[6]: *** [ena_ethdev.o] Error 2
  CC ena_com.o
In file included from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(34):
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.h(982): error 
#188: enumerated type mixed with another type
curr_moder_idx = *moder_tbl_idx;
   ^

In file included from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(34):
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.h(994): error 
#188: enumerated type mixed with another type
new_moder_idx = curr_moder_idx + 1;
  ^

In file included from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(34):
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.h(1000): error 
#188: enumerated type mixed with another type
new_moder_idx = curr_moder_idx - 1;
  ^

In file included from 
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(34):
/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.h(1004): error 
#188: enumerated type mixed with another type
new_moder_idx = curr_moder_idx + 1;
  ^

/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(309): error 
#592: variable "flags" is used before its value is set
ENA_SPINLOCK_LOCK(admin_queue->q_lock, flags);
^

/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(541): error 
#592: variable "flags" is used before its value is set
ENA_SPINLOCK_LOCK(admin_queue->q_lock, flags);
^

/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(584): error 
#592: variable "flags" is used before its value is set
ENA_SPINLOCK_LOCK(mmio_read->lock, flags);
^

/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(1253): error 
#592: variable "flags" is used before its value is set
ENA_SPINLOCK_LOCK(admin_queue->q_lock, flags);
^

/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(1298): error 
#592: variable "flags" is used before its value is set
ENA_SPINLOCK_LOCK(admin_queue->q_lock, flags);
^

/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(2193): error 
#188: enumerated type mixed with another type
rss->hash_func = get_resp.u.flow_hash_func.selected_func;
   ^

/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(2279): error 
#188: enumerated type mixed with another type
rc = ena_com_get_hash_ctrl(ena_dev, 0, NULL);
^

/mnt/shared/dtmrzglx/hubabuba-ena/drivers/net/ena/base/ena_com.c(2326): error 
#188: enumerated type mixed with another type
ena_com_get_hash_ctrl(ena_dev, 0, NULL);
   ^

[dpdk-dev] [PATCH 0/2] Fix multiple build errors for Amazon ENA driver

[Daniel Mrzyglod]

First patch cover multiple error for ICC.
a. mixed enum with other types
b. variable is used uninitialized

Patches for FreeBSD:
a. Target was not setup
b. ETIME is not avaliable in FreeBSD 

Daniel Mrzyglod (2):
  ena: icc fix compilation errors
  ena: Fix Compilation for freebsd

 drivers/net/ena/base/ena_com.c   | 18 +-
 drivers/net/ena/base/ena_com.h   |  8 
 drivers/net/ena/base/ena_eth_com.c   | 10 +-
 drivers/net/ena/base/ena_plat.h  |  2 ++
 drivers/net/ena/base/ena_plat_dpdk.h |  3 +++
 5 files changed, 23 insertions(+), 18 deletions(-)

-- 
2.5.5

[dpdk-dev] [PATCH v13 5/8] ethdev: add speed capabilities

[Alejandro Lucero]

For nfp.c, speed_capa should be ETH_LINK_SPEED_40G instead of
ETH_LINK_SPEED_50G.
By the way, the change in patch 4 sets the right link speed using the new
constants.

Regards

On Sat, Mar 26, 2016 at 1:27 AM, Marc Sune  wrote:

> The speed capabilities of a device can be retrieved with
> rte_eth_dev_info_get().
>
> The new field speed_capa is initialized in the drivers without
> taking care of device characteristics in this patch.
> When the capabilities of a driver are accurate, the table in
> overview.rst must be filled.
>
> Signed-off-by: Marc Sune 
> ---
>  doc/guides/nics/overview.rst   |  1 +
>  doc/guides/rel_notes/release_16_04.rst |  8 
>  drivers/net/bnx2x/bnx2x_ethdev.c   |  1 +
>  drivers/net/cxgbe/cxgbe_ethdev.c   |  1 +
>  drivers/net/e1000/em_ethdev.c  |  4 
>  drivers/net/e1000/igb_ethdev.c |  4 
>  drivers/net/ena/ena_ethdev.c   |  9 +
>  drivers/net/fm10k/fm10k_ethdev.c   |  4 
>  drivers/net/i40e/i40e_ethdev.c |  8 
>  drivers/net/ixgbe/ixgbe_ethdev.c   |  8 
>  drivers/net/mlx4/mlx4.c|  6 ++
>  drivers/net/mlx5/mlx5_ethdev.c |  8 
>  drivers/net/nfp/nfp_net.c  |  2 ++
>  lib/librte_ether/rte_ethdev.h  | 21 +
>  14 files changed, 85 insertions(+)
>
> diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
> index 542479a..62f1868 100644
> --- a/doc/guides/nics/overview.rst
> +++ b/doc/guides/nics/overview.rst
> @@ -86,6 +86,7 @@ Most of these differences are summarized below.
>e   e   e   e   e
>e
>c   c   c   c   c
>c
>  = = = = = = = = = = = = = = = = = = = = = = = = =
> = = = = = = = =
> +   speed capabilities
> link status  X   X X
>  X X
> link status eventX X
>X
> queue status event
>X
> diff --git a/doc/guides/rel_notes/release_16_04.rst
> b/doc/guides/rel_notes/release_16_04.rst
> index 79d76e1..9e7b0b7 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -47,6 +47,11 @@ This section should contain new features added in this
> release. Sample format:
>A new function ``rte_pktmbuf_alloc_bulk()`` has been added to allow the
> user
>to allocate a bulk of mbufs.
>
> +* **Added device link speed capabilities.**
> +
> +  The structure ``rte_eth_dev_info`` has now a ``speed_capa`` bitmap,
> which
> +  allows the application to know the supported speeds of each device.
> +
>  * **Added new poll-mode driver for Amazon Elastic Network Adapters
> (ENA).**
>
>The driver operates variety of ENA adapters through feature negotiation
> @@ -456,6 +461,9 @@ This section should contain API changes. Sample format:
>All drivers are now counting the missed packets only once, i.e. drivers
> will
>not increment ierrors anymore for missed packets.
>
> +* The ethdev structure ``rte_eth_dev_info`` was changed to support device
> +  speed capabilities.
> +
>  * The functions ``rte_eth_dev_udp_tunnel_add`` and
> ``rte_eth_dev_udp_tunnel_delete``
>have been renamed into ``rte_eth_dev_udp_tunnel_port_add`` and
>``rte_eth_dev_udp_tunnel_port_delete``.
> diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c
> b/drivers/net/bnx2x/bnx2x_ethdev.c
> index a3c6c01..897081f 100644
> --- a/drivers/net/bnx2x/bnx2x_ethdev.c
> +++ b/drivers/net/bnx2x/bnx2x_ethdev.c
> @@ -327,6 +327,7 @@ bnx2x_dev_infos_get(struct rte_eth_dev *dev,
> __rte_unused struct rte_eth_dev_inf
> dev_info->min_rx_bufsize = BNX2X_MIN_RX_BUF_SIZE;
> dev_info->max_rx_pktlen  = BNX2X_MAX_RX_PKT_LEN;
> dev_info->max_mac_addrs  = BNX2X_MAX_MAC_ADDRS;
> +   dev_info->speed_capa = ETH_LINK_SPEED_10G | ETH_LINK_SPEED_20G;
>  }
>
>  static void
> diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c
> b/drivers/net/cxgbe/cxgbe_ethdev.c
> index 8845c76..bb134e5 100644
> --- a/drivers/net/cxgbe/cxgbe_ethdev.c
> +++ b/drivers/net/cxgbe/cxgbe_ethdev.c
> @@ -171,6 +171,7 @@ static void cxgbe_dev_info_get(struct rte_eth_dev
> *eth_dev,
>
> device_info->rx_desc_lim = cxgbe_desc_lim;
> device_info->tx_desc_lim = cxgbe_desc_lim;
> +   device_info->speed_capa = ETH_LINK_SPEED_10G | ETH_LINK_SPEED_40G;
>  }
>
>  static void cxgbe_dev_promiscuous_enable(struct rte_eth_dev *eth_dev)
> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
> index 473d77f..d5f8c7f 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -1054,6 +1054,10 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *dev_info)
> .nb_min = E1000_MIN_RING_DESC,
> .nb_align = EM_TXD_ALIGN,
> };
> +
> +   dev_info->speed_capa = ETH_LINK_SPEED_10M_HD | ETH_LINK_SPEED_10M |
> +

[dpdk-dev] DPDK: receive single packet at a time

[Bruce Richardson]

On Tue, Mar 29, 2016 at 06:31:58PM +0530, Mohan Prasad wrote:
> Hi,
> 
> I have tried this and it does not work
> 

What type of NIC are you using. If you are using ixgbe or i40e, try disabling
the vector PMD in your build-time configuration to see if it makes a difference.

However, why do you want to receive just a single packet at a time. Why not just
receive a burst of packets and then process them one at a time? It's much more
efficient that way, and you should get better performance from your application.

/Bruce


> Thanks,
> Mohan
> On Mar 29, 2016 6:26 PM, "Wiles, Keith"  wrote:
> 
> > >Hi,
> > >
> > >Is there any option to receive single packet at a time with dpdk?
> >
> > Not sure if this is the answer you are looking for, but if you just
> > request a single packet with
> >
> > struct rte_mbuf *mbuf;
> > rte_eth_rx_burst(port_id, queue_id, , 1);
> >
> > will return only one packet as a time.
> > >
> > >Thanks,
> > >Mohan
> > >
> >
> >
> > Regards,
> > Keith
> >
> >
> >
> >
> >

[dpdk-dev] [PATCH 2/2] ena: Fix Compilation for freebsd

[Bruce Richardson]

On Tue, Mar 29, 2016 at 02:43:54PM +0200, Daniel Mrzyglod wrote:
> FreeBSD was not defined in ena_plat.h
> ETIME is not defined in FreeBSD.
> 
> In file included from DPDK/drivers/net/ena/base/ena_com.h:37:0,
>  from DPDK/drivers/net/ena/ena_ethdev.h:39,
>  from DPDK/drivers/net/ena/ena_ethdev.c:41:
> DPDK/drivers/net/ena/base/ena_plat.h:48:2: error: #error "Invalid platform"
>  #error "Invalid platform"
>   ^
> compilation terminated due to -Wfatal-errors.
> 
> Signed-off-by: Daniel Mrzyglod 
> ---

Acked-by: Bruce Richardson 

[dpdk-dev] [PATCH 1/2] driver/crypto: out-of-place symmetric operations

[Thomas Monjalon]

2016-03-29 10:39, Fiona Trahe:
> From: Arek Kusztal 
> 
> Driver now support out of place crypto operations,
> driver assumes both buffers can be of different size.

Please, could you explain what exactly means "out of place" operations?

[dpdk-dev] Issue with binding NIC of type 82545EM to dpdk

[Al Patel]

Ferruh,

On my fedora23, I don't have igb_uio

# modprobe igb_uio
modprobe: FATAL: Module igb_uio not found in directory
/lib/modules/4.4.6-300.fc23.x86_64


I am trying to bind to uio_pci_generic module

thx
-a

On Tue, Mar 29, 2016 at 12:26 PM, Ferruh Yigit 
wrote:

> On 3/29/2016 3:11 PM, Al Patel wrote:
> > Hi,
> >
> > I am having an issue with binding a nic of type 82545EM to dpdk. I am
> using
> > a
> > fedoracore23 VM on MAC with VMFusion.
> >
> > ./dpdk_nic_bind.py -b uio_pci_generic :02:02.0
> > Error: bind failed for :02:02.0 - Cannot bind to driver
> uio_pci_generic
> > Error: unbind failed for :02:02.0 - Cannot open
> > /sys/bus/pci/drivers//unbind
> >
> > it is unbound from e1000, repeating the command:
> >
> > ./dpdk_nic_bind.py -b uio_pci_generic :02:02.0
> > Error: bind failed for :02:02.0 - Cannot bind to driver
> uio_pci_generic
> >
> > I repeated the same test on a ubuntu vm running on Virtualbox with
> > NIC type 82450EM
> >
> > In this case, the device is able to bind successfully to uio_pci_generic
> > driver.
> >
> > There is a igb_uio module that present. The device cannot be bound to the
> > igb_uio
> > driver.
>
> Hi Al,
>
> You are trying to bind to the driver "uio_pci_generic" not to the
> "igb_uio", is it typo? If not, can you please double check if
> "uio_pci_generic" module inserted.
> Or bind device to "igb_uio":
> "./dpdk_nic_bind.py -b igb_uio :02:02.0"
>
> Regards,
> ferruh
>
>

[dpdk-dev] DPDK: receive single packet at a time

[Wiles, Keith]

From:  Mohan Prasad 
Date:  Tuesday, March 29, 2016 at 8:01 AM
To:  Keith Wiles 
Cc:  "dev at dpdk.org" 
Subject:  Re: [dpdk-dev] DPDK: receive single packet at a time


>Hi,
>I have tried this and it does not work

Then something else is wrong as this work in Pktgen-DPDK, I can send one packet 
and receive one packet even when I ask for 32 packets at a time. Are you 
receiving any packets?

I am using a 82599 NIC and if you are using some other type of NIC, I will not 
be able to help much.

>Thanks,
>Mohan
>On Mar 29, 2016 6:26 PM, "Wiles, Keith"  wrote:
>
>>Hi,
>>
>>Is there any option to receive single packet at a time with dpdk?
>
>Not sure if this is the answer you are looking for, but if you just request a 
>single packet with
>
>struct rte_mbuf *mbuf;
>rte_eth_rx_burst(port_id, queue_id, , 1);
>
>will return only one packet as a time.
>>
>>Thanks,
>>Mohan
>>
>
>
>Regards,
>Keith
>
>
>
>
>
>
>
>
>


Regards,
Keith

[dpdk-dev] DPDK: receive single packet at a time

[Wiles, Keith]

>Hi,
>
>Is there any option to receive single packet at a time with dpdk?

Not sure if this is the answer you are looking for, but if you just request a 
single packet with

struct rte_mbuf *mbuf;
rte_eth_rx_burst(port_id, queue_id, , 1);

will return only one packet as a time.
>
>Thanks,
>Mohan
>


Regards,
Keith

[dpdk-dev] [PATCH 1/2] driver/crypto: out-of-place symmetric operations

[Jain, Deepak K]

Hi,

"Out-of-place" operation means the result of the operation will be written to 
the destination buffer instead of overwriting the source buffer as done in 
"in-place" operation.


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Tuesday, March 29, 2016 1:02 PM
To: Trahe, Fiona ; Kusztal, ArkadiuszX 

Cc: dev at dpdk.org; Doherty, Declan 
Subject: Re: [dpdk-dev] [PATCH 1/2] driver/crypto: out-of-place symmetric 
operations

2016-03-29 10:39, Fiona Trahe:
> From: Arek Kusztal 
> 
> Driver now support out of place crypto operations, driver assumes both 
> buffers can be of different size.

Please, could you explain what exactly means "out of place" operations?

[dpdk-dev] [PATCH v2 1/2] ethdev: add tunnel and port RSS offload types

[De Lara Guarch, Pablo]

Hi Jerin,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
> Sent: Tuesday, March 29, 2016 12:20 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Richardson, Bruce; Jerin Jacob
> Subject: [dpdk-dev] [PATCH v2 1/2] ethdev: add tunnel and port RSS offload
> types
> 
> - added VXLAN, GENEVE and NVGRE tunnel flow types
> - added PORT flow type for accounting physical/virtual
> port or channel number in flow creation
> 
> Signed-off-by: Jerin Jacob 
> ---
>  app/test-pmd/cmdline.c  | 18 +++---
>  app/test-pmd/config.c   |  9 +
>  lib/librte_ether/rte_eth_ctrl.h |  6 +-
>  lib/librte_ether/rte_ethdev.h   | 16 +++-
>  4 files changed, 44 insertions(+), 5 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 93203f4..5fe8239 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -565,7 +565,7 @@ static void cmd_help_long_parsed(void
> *parsed_result,
>   "Set crc-strip/rx-checksum/hardware-
> vlan/drop_en"
>   " for ports.\n\n"
> 
> - "port config all rss
> (all|ip|tcp|udp|sctp|ether|none)\n"
> + "port config all rss
> (all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)\n"

Could you update the testpmd document and extend the options in the command 
line help?

Thanks,
Pablo

[dpdk-dev] [PATCH v2 1/2] ethdev: add tunnel and port RSS offload types

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
> Sent: Tuesday, March 29, 2016 12:20 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Richardson, Bruce
> ; Jerin Jacob  caviumnetworks.com>
> Subject: [dpdk-dev] [PATCH v2 1/2] ethdev: add tunnel and port RSS offload
> types
> 
> ...
>
> - "port config all rss (all|ip|tcp|udp|sctp|ether|none)\n"
> + "port config all rss 
> (all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)\n"

Hi,

Just a reminder that if the testpmd interface is changed you need to update the 
testpmd documentation as well.

John 

[dpdk-dev] [PATCH] maintainers: claim responsibility for Intel i40e PMD

[Jingjing Wu]

Signed-off-by: Jingjing Wu 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e848ffa..498bf4e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -300,8 +300,10 @@ F: doc/guides/nics/intel_vf.rst

 Intel i40e
 M: Helin Zhang 
+M: Jingjing Wu 
 F: drivers/net/i40e/
 F: doc/guides/nics/intel_vf.rst
+F: doc/guides/nics/i40e.rst

 Intel fm10k
 M: Jing Chen 
-- 
2.4.0

[dpdk-dev] [PATCH] librte_ether: fix comments for filters

[Jingjing Wu]

This patch fixes comments for tunnel filters and flow director flows.
e.g. states fields which are in big endian.

Fixes: 7b1312891b69 (ethdev: add IP in GRE tunnel)
Fixes: d69be32d4d78 (ethdev: structures to add or delete flow director)
Signed-off-by: Jingjing Wu 
---
 lib/librte_ether/rte_eth_ctrl.h | 66 ++---
 1 file changed, 35 insertions(+), 31 deletions(-)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index aabd724..b8c7be9 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -283,19 +283,22 @@ enum rte_tunnel_iptype {
  * Tunneling Packet filter configuration.
  */
 struct rte_eth_tunnel_filter_conf {
-   struct ether_addr outer_mac;  /**< Outer MAC address filter. */
-   struct ether_addr inner_mac;  /**< Inner MAC address filter. */
-   uint16_t inner_vlan;   /**< Inner VLAN filter. */
+   struct ether_addr outer_mac;/**< Outer MAC address to match. */
+   struct ether_addr inner_mac;/**< Inner MAC address to match. */
+   uint16_t inner_vlan;/**< Inner VLAN to match. */
enum rte_tunnel_iptype ip_type; /**< IP address type. */
+   /** Outer destination IP address to match if ETH_TUNNEL_FILTER_OIP
+   is set in filter_type, or inner destination IP address to match
+   if ETH_TUNNEL_FILTER_IIP is set in filter_type . */
union {
-   uint32_t ipv4_addr;/**< IPv4 source address to match. */
-   uint32_t ipv6_addr[4]; /**< IPv6 source address to match. */
-   } ip_addr; /**< IPv4/IPv6 source address to match (union of above). */
-
-   uint16_t filter_type;   /**< Filter type. */
+   uint32_t ipv4_addr; /**< IPv4 address in big endian. */
+   uint32_t ipv6_addr[4];  /**< IPv6 address in big endian. */
+   } ip_addr;
+   /** Flags from ETH_TUNNEL_FILTER_XX - see above. */
+   uint16_t filter_type;
enum rte_eth_tunnel_type tunnel_type; /**< Tunnel Type. */
-   uint32_t tenant_id; /**< Tenant number. */
-   uint16_t queue_id;  /**< Queue number. */
+   uint32_t tenant_id; /**< Tenant ID to match. VNI, GRE key... */
+   uint16_t queue_id;  /**< Queue assigned to if match. */
 };

 /**
@@ -403,18 +406,18 @@ struct rte_eth_input_set_conf {
  * A structure used to define the input for L2 flow
  */
 struct rte_eth_l2_flow {
-   uint16_t ether_type;  /**< Ether type to match */
+   uint16_t ether_type;  /**< Ether type in big endian */
 };

 /**
  * A structure used to define the input for IPV4 flow
  */
 struct rte_eth_ipv4_flow {
-   uint32_t src_ip;  /**< IPv4 source address to match. */
-   uint32_t dst_ip;  /**< IPv4 destination address to match. */
+   uint32_t src_ip;  /**< IPv4 source address in big endian. */
+   uint32_t dst_ip;  /**< IPv4 destination address in big endian. */
uint8_t  tos; /**< Type of service to match. */
uint8_t  ttl; /**< Time to live to match. */
-   uint8_t  proto;   /**< Protocol, next header to match. */
+   uint8_t  proto;   /**< Protocol, next header in big endian. */
 };

 /**
@@ -422,8 +425,8 @@ struct rte_eth_ipv4_flow {
  */
 struct rte_eth_udpv4_flow {
struct rte_eth_ipv4_flow ip; /**< IPv4 fields to match. */
-   uint16_t src_port;   /**< UDP source port to match. */
-   uint16_t dst_port;   /**< UDP destination port to match. */
+   uint16_t src_port;   /**< UDP source port in big endian. */
+   uint16_t dst_port;   /**< UDP destination port in big endian. */
 };

 /**
@@ -431,8 +434,8 @@ struct rte_eth_udpv4_flow {
  */
 struct rte_eth_tcpv4_flow {
struct rte_eth_ipv4_flow ip; /**< IPv4 fields to match. */
-   uint16_t src_port;   /**< TCP source port to match. */
-   uint16_t dst_port;   /**< TCP destination port to match. */
+   uint16_t src_port;   /**< TCP source port in big endian. */
+   uint16_t dst_port;   /**< TCP destination port in big endian. */
 };

 /**
@@ -440,17 +443,17 @@ struct rte_eth_tcpv4_flow {
  */
 struct rte_eth_sctpv4_flow {
struct rte_eth_ipv4_flow ip; /**< IPv4 fields to match. */
-   uint16_t src_port;   /**< SCTP source port to match. */
-   uint16_t dst_port;   /**< SCTP destination port to match. */
-   uint32_t verify_tag; /**< Verify tag to match */
+   uint16_t src_port;   /**< SCTP source port in big endian. */
+   uint16_t dst_port;   /**< SCTP destination port in big endian. 
*/
+   uint32_t verify_tag; /**< Verify tag in big endian */
 };

 /**
  * A structure used to define the input for IPV6 flow
  */
 struct rte_eth_ipv6_flow {
-   uint32_t src_ip[4];  /**< IPv6 source address to match. */
-   uint32_t dst_ip[4];  /**< 

[dpdk-dev] [PATCH 2/2] app/test: added test for out-of-place symmetric operations

[Fiona Trahe]

From: Arek Kusztal 

Added AES and snow3g Authenticated encryption and decryption tests

Signed-off-by: Arek Kusztal 
---
 app/test/test_cryptodev.c |  495 -
 1 files changed, 491 insertions(+), 4 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 2494bae..0c26804 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -101,12 +101,27 @@ setup_test_string(struct rte_mempool *mpool,
rte_pktmbuf_free(m);
return NULL;
}
-
-   rte_memcpy(dst, string, t_len);
+   if (string != NULL)
+   rte_memcpy(dst, string, t_len);
+   else
+   memset(dst, 0, t_len);
}

return m;
 }
+static int
+setup_oop_test_mbufs(struct rte_mbuf **ibuf, struct rte_mbuf **obuf,
+   struct rte_mempool *mpool,  const char *string, size_t len,
+   uint8_t blocksize) {
+   *ibuf = setup_test_string(mpool, string, len, blocksize);
+   if (*ibuf == NULL)
+   return -(EFAULT);
+   *obuf = setup_test_string(mpool, NULL, len, blocksize);
+   if (*obuf == NULL)
+   return -(EFAULT);
+
+   return 0;
+}

 #if HEX_DUMP
 static void
@@ -907,6 +922,241 @@ test_AES_CBC_HMAC_SHA1_encrypt_digest(void)
return TEST_SUCCESS;
 }

+
+static int
+test_AES_CBC_HMAC_SHA1_encrypt_digest_oop(void)
+{
+   struct crypto_testsuite_params *ts_params = _params;
+   struct crypto_unittest_params *ut_params = _params;
+
+   /* Generate test mbuf data and space for digest */
+
+   TEST_ASSERT_EQUAL(setup_oop_test_mbufs(_params->ibuf,
+   _params->obuf, ts_params->mbuf_pool, catch_22_quote,
+   QUOTE_512_BYTES, 0), 0,
+   "Allocation of rte_mbuf failed");
+
+   ut_params->digest = (uint8_t *)rte_pktmbuf_append(ut_params->obuf,
+   DIGEST_BYTE_LENGTH_SHA1);
+
+   TEST_ASSERT_NOT_NULL(ut_params->digest, "no room to append digest");
+
+   ut_params->cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
+   ut_params->cipher_xform.next = _params->auth_xform;
+
+   ut_params->cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_AES_CBC;
+   ut_params->cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
+   ut_params->cipher_xform.cipher.key.data = aes_cbc_key;
+   ut_params->cipher_xform.cipher.key.length = CIPHER_KEY_LENGTH_AES_CBC;
+
+   ut_params->auth_xform.type = RTE_CRYPTO_SYM_XFORM_AUTH;
+   ut_params->auth_xform.next = NULL;
+
+   ut_params->auth_xform.auth.op = RTE_CRYPTO_AUTH_OP_GENERATE;
+   ut_params->auth_xform.auth.algo = RTE_CRYPTO_AUTH_SHA1_HMAC;
+   ut_params->auth_xform.auth.key.length = HMAC_KEY_LENGTH_SHA1;
+   ut_params->auth_xform.auth.key.data = hmac_sha1_key;
+   ut_params->auth_xform.auth.digest_length = DIGEST_BYTE_LENGTH_SHA1;
+
+   ut_params->sess = rte_cryptodev_sym_session_create(
+   ts_params->valid_devs[0],
+   _params->cipher_xform);
+
+   TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
+
+   ut_params->op = rte_crypto_op_alloc(ts_params->op_mpool,
+   RTE_CRYPTO_OP_TYPE_SYMMETRIC);
+
+
+   TEST_ASSERT_NOT_NULL(ut_params->op,
+   "Failed to allocate symmetric crypto operation struct");
+
+   rte_crypto_op_attach_sym_session(ut_params->op, ut_params->sess);
+
+   struct rte_crypto_sym_op *sym_op = ut_params->op->sym;
+
+   /* set crypto operation source mbuf */
+   sym_op->m_src = ut_params->ibuf;
+   sym_op->m_dst = ut_params->obuf;
+
+   sym_op->auth.digest.data = ut_params->digest;
+
+   sym_op->auth.digest.phys_addr = rte_pktmbuf_mtophys_offset(
+   ut_params->obuf, QUOTE_512_BYTES);
+
+   sym_op->auth.digest.length = DIGEST_BYTE_LENGTH_SHA1;
+   sym_op->auth.data.length = QUOTE_512_BYTES;
+
+   /* Set crypto operation cipher parameters */
+   sym_op->cipher.iv.data = (uint8_t *)rte_pktmbuf_prepend(ut_params->ibuf,
+   CIPHER_IV_LENGTH_AES_CBC);
+
+   TEST_ASSERT_NOT_NULL(sym_op->cipher.iv.data,
+   "Failed to prepend place for iv input");
+
+   TEST_ASSERT_NOT_NULL(rte_pktmbuf_prepend(ut_params->obuf,
+   CIPHER_IV_LENGTH_AES_CBC),
+   "Failed to prepend place for iv output");
+
+   sym_op->auth.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+
+   sym_op->cipher.iv.phys_addr = rte_pktmbuf_mtophys(ut_params->ibuf);
+   sym_op->cipher.iv.length = CIPHER_IV_LENGTH_AES_CBC;
+
+   rte_memcpy(sym_op->cipher.iv.data, aes_cbc_iv,
+   CIPHER_IV_LENGTH_AES_CBC);
+
+   sym_op->cipher.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+   

[dpdk-dev] [PATCH 1/2] driver/crypto: out-of-place symmetric operations

[Fiona Trahe]

From: Arek Kusztal 

Driver now support out of place crypto operations,
driver assumes both buffers can be of different size.

Signed-off-by: Arek Kusztal 
---
 doc/guides/cryptodevs/qat.rst   |1 -
 drivers/crypto/qat/qat_crypto.c |   22 +-
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index af90b46..4b8f782 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -62,7 +62,6 @@ Limitations
 * Chained mbufs are not supported.
 * Hash only is not supported except Snow3G UIA2.
 * Cipher only is not supported except Snow3G UEA2.
-* Only in-place is currently supported (destination address is the same as 
source address).
 * Only supports the session-oriented API implementation (session-less APIs are 
not supported).
 * Not performance tuned.
 * Snow3g(UEA2) supported only if cipher length, cipher offset fields are 
byte-aligned.
diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 29c1fe5..55884d6 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -689,17 +689,21 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t 
*out_msg)
*qat_req = ctx->fw_req;
qat_req->comn_mid.opaque_data = (uint64_t)(uintptr_t)op;

-   /*
-* The following code assumes:
-* - single entry buffer.
-* - always in place.
-*/
qat_req->comn_mid.dst_length =
-   qat_req->comn_mid.src_length =
-   rte_pktmbuf_data_len(op->sym->m_src);
+   qat_req->comn_mid.src_length =
+   rte_pktmbuf_data_len(op->sym->m_src);
+
qat_req->comn_mid.dest_data_addr =
-   qat_req->comn_mid.src_data_addr =
-   rte_pktmbuf_mtophys(op->sym->m_src);
+   qat_req->comn_mid.src_data_addr =
+   rte_pktmbuf_mtophys(op->sym->m_src);
+
+   if (unlikely(op->sym->m_dst != NULL)) {
+   qat_req->comn_mid.dest_data_addr =
+   rte_pktmbuf_mtophys(op->sym->m_dst);
+   qat_req->comn_mid.dst_length =
+   rte_pktmbuf_data_len(op->sym->m_dst);
+   }
+
cipher_param = (void *)_req->serv_specif_rqpars;
auth_param = (void *)((uint8_t *)cipher_param + sizeof(*cipher_param));

-- 
1.7.0.7

[dpdk-dev] [PATCH 0/2] Out of place operations for symmetric crypto

[Fiona Trahe]

From: Arek Kusztal 

This patch adds out of place operations for qat symmetric crypto operations.

Arek Kusztal (2):
  driver/crypto: out-of-place symmetric operations
  app/test: added test for out-of-place symmetric operations

 app/test/test_cryptodev.c   |  495 ++-
 doc/guides/cryptodevs/qat.rst   |1 -
 drivers/crypto/qat/qat_crypto.c |   22 +-
 3 files changed, 504 insertions(+), 14 deletions(-)

[dpdk-dev] librte_pmd_ixgbe implementation of ixgbe_dev_rx_queue_count

[Bruce Richardson]

On Mon, Mar 28, 2016 at 06:45:26PM -0700, Mohammad El-Shabani wrote:
> Hi,
> Looking into why it hurts performance, I see that ixgbe_dev_rx_queue_count
> is implemented a scan of elements of rx descriptors, which is very
> expensive. I am wondering why its implemented the way it is. Could it not
> just read the head location from the driver?
> 
> Thanks!
> Mohammad El-Shabani

It's likely that reading the head location from the driver will be even slower
than scanning the descriptor rings in memory. Access to PCI is very much slower
than accessing memory - especially since on platforms with DDIO, many memory
accesses will actually be cache reads.

That being said, I haven't actually written a test to prove this out, so feel
free to try out the head pointer read method instead and see if it improves
things. The results may vary depending on how far ahead needs to be scanned,
but certainly for the empty ring case, the descriptor scan method will be far
faster than a head read.

Regards,
/Bruce

[dpdk-dev] Unable to get multi-segment mbuf working for ixgbe

[Bruce Richardson]

On Mon, Mar 28, 2016 at 10:05:40AM -0700, Clarylin L wrote:
> Any pointers to what the issue could be? thanks
> 
> On Fri, Mar 25, 2016 at 4:13 PM, Clarylin L  wrote:
> 
> > Hello,
> >
> > I am trying to use multi-segment mbuf to receive large packet. I enabled
> > jumbo_frame and enable_scatter for the port and was expecting mbuf chaining
> > would be used to receive packets larger than the mbuf size (which was set
> > to 2048).
> >
> > When sending 3000-byte (without fragmentation) packet from another
> > non-dpdk host, I didn't see packet was received by the ixgbe PMD driver.
> >
> > After a quick debugging session I found that the following statement in 
> > ixgbe_recv_scattered_pkts
> > (ixgbe_rxtx.c) is
> > always true and break the loop in case of large packet, while it's not the
> > case for small packet (smaller than mbuf size):
> >
> > if (! staterr & rte_cpu_to_le32(IXGBE_RXDADV_STAT_DD))
> > break;
> >
> > Is enabling jumbo_frame and enable_scatter good enough to get started the
> > mbuf chaining?

What did you configure for the max MTU for jumbo frames? What do the port stats
and extended stats (xstats) report. Is there an error counter there that is
incrementing that could give a hint as to what the problem is.

/Bruce

> >
> > Appreciate any input! Thanks.
> >

[dpdk-dev] Issue with binding NIC of type 82545EM to dpdk

[Al Patel]

Hi,

I am having an issue with binding a nic of type 82545EM to dpdk. I am using
a
fedoracore23 VM on MAC with VMFusion.

./dpdk_nic_bind.py -b uio_pci_generic :02:02.0
Error: bind failed for :02:02.0 - Cannot bind to driver uio_pci_generic
Error: unbind failed for :02:02.0 - Cannot open
/sys/bus/pci/drivers//unbind

it is unbound from e1000, repeating the command:

./dpdk_nic_bind.py -b uio_pci_generic :02:02.0
Error: bind failed for :02:02.0 - Cannot bind to driver uio_pci_generic

I repeated the same test on a ubuntu vm running on Virtualbox with
NIC type 82450EM

In this case, the device is able to bind successfully to uio_pci_generic
driver.

There is a igb_uio module that present. The device cannot be bound to the
igb_uio
driver.

My question is that why is the device being able to be bound to
uio_pci_generic driver on ubuntu and not on fedoracore? (Albeit on fedora
device is 82545EM and on ubuntu it is 82540EM). Both these are reported as
tested by Intel:

? Emulated Intel? 82540EM Gigabit Ethernet Controller [8086:100e]
? Emulated Intel? 82545EM Gigabit Ethernet Controller [8086:100f]
http://www.intel.com/content/dam/www/public/us/en/documents/release-notes/dpdk-release-notes.pdf

Are there any debugs to collect that can shed some light?


Details:

# lspci -v -s 02:02.0
02:02.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet
Controller (Copper) (rev 01)
DeviceName: Ethernet1
Subsystem: VMware PRO/1000 MT Single Port Adapter
Physical Slot: 34
Flags: 66MHz, medium devsel
Memory at fd5a (64-bit, non-prefetchable) [size=128K]
Memory at fdfe (64-bit, non-prefetchable) [size=64K]
I/O ports at 2040 [size=64]
[virtual] Expansion ROM at fd51 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] PCI-X non-bridge device
Kernel modules: e1000

Thx
-a

[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

[Bruce Richardson]

On Mon, Mar 28, 2016 at 06:48:07PM +0300, Lazaros Koromilas wrote:
> Hi Olivier,
> 
> We could have two threads (running on different cores in the general
> case) that both succeed the cmpset operation. In the dequeue path,
> when n == 0, then cons_next == cons_head, and cmpset will always
> succeed. Now, if they both see an old r->cons.tail value from a
> previous dequeue, they can get stuck in the while

Hi,

I don't see how threads reading an "old r->cons.tail" value is even possible.
The head and tail pointers on the ring are marked in the code as volatile, so
all reads and writes to those values are always done from memory and not cached
in registers. No deadlock should be possible on that while loop, unless a 
process crashes in the middle of a ring operation. Each thread which updates
the head pointer from x to y, is responsible for updating the tail pointer in
a similar manner. The loop ensures the tail updates are in the same order as the
head updates.

If you believe deadlock is possible, can you outline the sequence of operations
which would lead to such a state, because I cannot see how it could occur 
without
a crash inside one of the threads.

/Bruce

> (unlikely(r->cons.tail != cons_head)) loop. I tried, however, to
> reproduce (without the patch) and it seems that there is still a
> window for deadlock.
> 
> I'm pasting some debug output below that shows two processes' state.
> It's two receivers doing interleaved mc_dequeue(32)/mc_dequeue(0), and
> one sender doing mp_enqueue(32) on the same ring.
> 
> gdb --args ./ring-test -l0 --proc-type=primary
> gdb --args ./ring-test -l1 --proc-type=secondary
> gdb --args ./ring-test -l2 --proc-type=secondary -- tx
> 
> This is what I would usually see, process 0 and 1 both stuck at the same 
> state:
> 
> 663 while (unlikely(r->cons.tail != cons_head)) {
> (gdb) p n
> $1 = 0
> (gdb) p r->cons.tail
> $2 = 576416
> (gdb) p cons_head
> $3 = 576448
> (gdb) p cons_next
> $4 = 576448
> 
> But now I managed to get the two processes stuck at this state too.
> 
> process 0:
> 663 while (unlikely(r->cons.tail != cons_head)) {
> (gdb) p n
> $1 = 32
> (gdb) p r->cons.tail
> $2 = 254348832
> (gdb) p cons_head
> $3 = 254348864
> (gdb) p cons_next
> $4 = 254348896
> 
> proccess 1:
> 663 while (unlikely(r->cons.tail != cons_head)) {
> (gdb) p n
> $1 = 32
> (gdb) p r->cons.tail
> $2 = 254348832
> (gdb) p cons_head
> $3 = 254348896
> (gdb) p cons_next
> $4 = 254348928
> 

Where is the thread which updated the head pointer from 832 to 864? That thread
was the one which would update the tail pointer to 864 to allow your thread 0
to continue.

/Bruce

> I haven't been able to trigger this with the patch so far, but it
> should be possible.
> 
> Lazaros.
> 
> On Fri, Mar 25, 2016 at 1:15 PM, Olivier Matz  
> wrote:
> > Hi Lazaros,
> >
> > On 03/17/2016 04:49 PM, Lazaros Koromilas wrote:
> >> Issuing a zero objects dequeue with a single consumer has no effect.
> >> Doing so with multiple consumers, can get more than one thread to succeed
> >> the compare-and-set operation and observe starvation or even deadlock in
> >> the while loop that checks for preceding dequeues.  The problematic piece
> >> of code when n = 0:
> >>
> >> cons_next = cons_head + n;
> >> success = rte_atomic32_cmpset(>cons.head, cons_head, cons_next);
> >>
> >> The same is possible on the enqueue path.
> >
> > Just a question about this patch (that has been applied). Thomas
> > retitled the commit from your log message:
> >
> >   ring: fix deadlock in zero object multi enqueue or dequeue
> >   http://dpdk.org/browse/dpdk/commit/?id=d0979646166e
> >
> > I think this patch does not fix a deadlock, or did I miss something?
> >
> > As explained in the following links, the ring may not perform well
> > if several threads running on the same cpu use it:
> >
> >   http://dpdk.org/ml/archives/dev/2013-November/000714.html
> >   http://www.dpdk.org/ml/archives/dev/2014-January/001070.html
> >   http://www.dpdk.org/ml/archives/dev/2014-January/001162.html
> >   http://dpdk.org/ml/archives/dev/2015-July/020659.html
> >
> > A deadlock could occur if the threads running on the same core
> > have different priority.
> >
> > Regards,
> > Olivier

[dpdk-dev] librte_pmd_ixgbe implementation of ixgbe_dev_rx_queue_count

[Stephen Hemminger]

On Tue, 29 Mar 2016 10:31:19 +0100
Bruce Richardson  wrote:

> On Mon, Mar 28, 2016 at 06:45:26PM -0700, Mohammad El-Shabani wrote:
> > Hi,
> > Looking into why it hurts performance, I see that ixgbe_dev_rx_queue_count
> > is implemented a scan of elements of rx descriptors, which is very
> > expensive. I am wondering why its implemented the way it is. Could it not
> > just read the head location from the driver?
> > 
> > Thanks!
> > Mohammad El-Shabani
> 
> It's likely that reading the head location from the driver will be even slower
> than scanning the descriptor rings in memory. Access to PCI is very much 
> slower
> than accessing memory - especially since on platforms with DDIO, many memory
> accesses will actually be cache reads.
> 
> That being said, I haven't actually written a test to prove this out, so feel
> free to try out the head pointer read method instead and see if it improves
> things. The results may vary depending on how far ahead needs to be scanned,
> but certainly for the empty ring case, the descriptor scan method will be far
> faster than a head read.
> 
> Regards,
> /Bruce

Also the most common use case is "is there any more packets ready before
I go to sleep on epoll", and the descriptor done API tells more than
is needed.

[dpdk-dev] is ixgbe supporting multi-segment mbuf?

[Ananyev, Konstantin]

Hi,
yep, it should be supported in dpdk 2.0.
Did you setup rxmode.max_rx_pkt_len inside your rte_eth_conf?
You need to setup both max_rx_pkt_len and jumbo_frame.
You can have a look how dpdk examples doing it.
Konstantin


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Clearasu
> Sent: Tuesday, March 29, 2016 2:38 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] is ixgbe supporting multi-segment mbuf?
> 
> Hi Wenzhuo,
> 
> Thanks. For some reason, we have to stick to dpdk 2.0 for now. Is 
> multi-segment mbuf supported in this version (any known issue
> with multi-seg in this version?) or do we have to upgrade to latest dpdk 
> version for multi-segment support?
> 
> Clarylin
> 
> > On Mar 28, 2016, at 6:10 PM, Lu, Wenzhuo  wrote:
> >
> >
> > Hi  Clarylin,
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Clarylin L
> >> Sent: Tuesday, March 29, 2016 4:24 AM
> >> To: dev at dpdk.org
> >> Subject: [dpdk-dev] is ixgbe supporting multi-segment mbuf?
> >>
> >> ixgbe_recv_scattered_pkts was set to be the rx function. Receiving packets
> > I see this function is already deprecated. Do you use an old version? Would 
> > you like to try the newest code?
> >
> >> smaller than mbuf size works perfectly. However, if an incoming packet is
> >> greater than the maximum acceptable length of one "mbuf" data size, 
> >> receiving
> >> does not work. In this case, isn't it supposed to use mbuf chaining to 
> >> receive?
> >>
> >> The port has both jumbo_frame and enable_scatter being on. are these two
> >> flags good enough to make mbuf chaining going?

[dpdk-dev] Updating bnx2x firmware

[Christian Ehrhardt]

Hi Thiago and Harish,
Ubuntus linux-firmware package has the latest versions of mid and end of
2015 (no newer yet as of today).
And as Harish pointed out any older will likely be untested/unsupported.

I like that you want to stick to the packaged content and I think your FW
in the linux-firmware package is up to date as of now.
The referred FW in the DPDK code is quite old (2012 according to the git).

But I think just changing the defines in the dpdk code to whatever is
current as of today won't solve it in the long term.
Neither for the package to carry a delta just for it (and bnx2 being a
disabled feature).
Nor for upstream-dpdk as it will just change over time and be incorrect
again.

What about a patch to upstream DPDK that detects the latest available FW
and creates a header with matching defines?
If the dpdk project would support such an approach you could create one and
bring it upstream.
Then later on (next dpdk release and it being packaged) it would always
detect and use the latest available - wouldn't that be what everybody would
want?


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Fri, Mar 25, 2016 at 2:31 AM, Martinx - ? 
wrote:

> On 24 March 2016 at 19:03, Harish Patil  wrote:
>
> > >
> > >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
> >
>
> Hi Harish,
>
>  Sure, I can download the firmware files, no problem... I just prefer to
> stick with the packages/files from the distribution that I'm using (Ubuntu
> 16.04) but, on this case, I'll follow your recommendation.
>
>  I don't know why Ubuntu removed the previous firmware files out from
> "linux-firmware" package...
>
>  Thanks for posting the git.kernel.org link!
>
> Best,
> Thiago
>

[dpdk-dev] [PATCH] nfp: copy pci info from pci to ethdev

[Alejandro Lucero]

Hi guys,

Sorry for the delay but I was on a Easter break.

That patch is OK for me. In fact, I had one patch ready for upstreaming
with this change needed for supporting hotplug. I was waiting for some
feedback from one internal project needing this hotplug functionality
before submitting.

Regards


On Fri, Mar 25, 2016 at 12:31 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:

> On Wed, Mar 23, 2016 at 08:51:36AM -0700, Stephen Hemminger wrote:
> > The NFP driver (unlike other PCI devices) was not copying the pci info
> > from the pci_dev to the eth_dev.  This would make the driver_name be
> > null (and other unset fields) when application uses dev_info_get.
> >
> > This was found by code review; do not have the hardware.
> >
> > Signed-off-by: Stephen Hemminger 
> > ---
> Alejandro,
>
> any review or ack on this patch for nfp driver?
>
> Regards,
> /Bruce
>

[dpdk-dev] [PATCH v13 6/8] ethdev: redesign link speed config

[Xing, Beilei]

> -Original Message-
> From: Marc Sune [mailto:marcdevel at gmail.com]
> Sent: Saturday, March 26, 2016 9:27 AM
> To: Thomas Monjalon ; Xu, Qian Q
> ; Xing, Beilei ; dev at 
> dpdk.org;
> Ananyev, Konstantin ; Lu, Wenzhuo
> ; Richardson, Bruce ;
> Glynn, Michael J 
> Cc: Marc Sune 
> Subject: [PATCH v13 6/8] ethdev: redesign link speed config
> 

> a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
> index a98e8eb..6cc2da0 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -2193,32 +2195,21 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
>   if (err)
>   goto error;
> 
> + speed = 0x0;
> + if (*link_speeds & ETH_LINK_SPEED_10G)
> + speed |= IXGBE_LINK_SPEED_10GB_FULL;
> + if (*link_speeds & ETH_LINK_SPEED_1G)
> + speed |= IXGBE_LINK_SPEED_1GB_FULL;
> + if (*link_speeds & ETH_LINK_SPEED_100M)
> + speed |= IXGBE_LINK_SPEED_100_FULL;
> +
>   err = ixgbe_setup_link(hw, speed, link_up);
>   if (err)
>   goto error;

Hi Marc,
According to ixgbe HW, link speed shouldn't be 0 when setting up, 
Otherwise device will start fail. So we need to set speed if link_speed 
is ETH_LINK_SPEED_AUTONEG. Following code is for reference.

speed = 0x0;
if ((*link_speeds & 0x1) == ETH_LINK_SPEED_AUTONEG)
speed = (hw->mac.type != ixgbe_mac_82598EB) ?
IXGBE_LINK_SPEED_82599_AUTONEG :
IXGBE_LINK_SPEED_82598_AUTONEG;
else {
if (*link_speeds & ETH_LINK_SPEED_10G)
speed |= IXGBE_LINK_SPEED_10GB_FULL;
if (*link_speeds & ETH_LINK_SPEED_1G)
speed |= IXGBE_LINK_SPEED_1GB_FULL;
if (*link_speeds & ETH_LINK_SPEED_100M)
speed |= IXGBE_LINK_SPEED_100_FULL;
}

Beilei Xing
Thanks

[dpdk-dev] [PATCH] maintainers: claim responsibility for Intel i40e PMD

[Zhang, Helin]

> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, March 29, 2016 11:22 AM
> To: dev at dpdk.org
> Cc: Wu, Jingjing ; Zhang, Helin  intel.com>
> Subject: [PATCH] maintainers: claim responsibility for Intel i40e PMD
> 
> Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 

[dpdk-dev] is ixgbe supporting multi-segment mbuf?

[Lu, Wenzhuo]

Hi Clarylin,


> -Original Message-
> From: Clearasu [mailto:clearasu at gmail.com]
> Sent: Tuesday, March 29, 2016 9:38 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] is ixgbe supporting multi-segment mbuf?
> 
> Hi Wenzhuo,
> 
> Thanks. For some reason, we have to stick to dpdk 2.0 for now. Is 
> multi-segment
> mbuf supported in this version (any known issue with multi-seg in this 
> version?)
> or do we have to upgrade to latest dpdk version for multi-segment support?
Yes, I suggest to try at least 2.1.  It should help.
And to my opinion, the newer the better. As you know there'll be more functions 
and less bugs :)

> 
> Clarylin
> 
> > On Mar 28, 2016, at 6:10 PM, Lu, Wenzhuo  wrote:
> >
> >
> > Hi  Clarylin,
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Clarylin L
> >> Sent: Tuesday, March 29, 2016 4:24 AM
> >> To: dev at dpdk.org
> >> Subject: [dpdk-dev] is ixgbe supporting multi-segment mbuf?
> >>
> >> ixgbe_recv_scattered_pkts was set to be the rx function. Receiving
> >> packets
> > I see this function is already deprecated. Do you use an old version? Would
> you like to try the newest code?
> >
> >> smaller than mbuf size works perfectly. However, if an incoming
> >> packet is greater than the maximum acceptable length of one "mbuf"
> >> data size, receiving does not work. In this case, isn't it supposed to use 
> >> mbuf
> chaining to receive?
> >>
> >> The port has both jumbo_frame and enable_scatter being on. are these
> >> two flags good enough to make mbuf chaining going?

[dpdk-dev] librte_pmd_ixgbe implementation of ixgbe_dev_rx_queue_count

[Lu, Wenzhuo]

Hi Mohammad,


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mohammad El-Shabani
> Sent: Tuesday, March 29, 2016 9:45 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] librte_pmd_ixgbe implementation of
> ixgbe_dev_rx_queue_count
> 
> Hi,
> Looking into why it hurts performance, I see that ixgbe_dev_rx_queue_count is
> implemented a scan of elements of rx descriptors, which is very expensive. I 
> am
> wondering why its implemented the way it is. Could it not just read the head
> location from the driver?
Not sure about the history. But to my opinion it's a control plane ops not a 
data plane ops. Maybe the reason is the author doesn't care about the 
performance too much.
As you have a good idea, would you like to share it with us? Thanks in advance:)

> 
> Thanks!
> Mohammad El-Shabani

[dpdk-dev] e1000: randomly loosing link change events triggered by the peer

[Lu, Wenzhuo]

Hi Marc,

From: marc.sune at gmail.com [mailto:marc.s...@gmail.com] On Behalf Of Marc
Sent: Monday, March 28, 2016 7:03 PM
To: Lu, Wenzhuo
Cc: dev at dpdk.org
Subject: Re: e1000: randomly loosing link change events triggered by the peer



On 28 March 2016 at 03:54, Lu, Wenzhuo mailto:wenzhuo.lu at intel.com>> wrote:
Hi Marc

From: Marc Sune [mailto:marcdevel at gmail.com]
Sent: Saturday, March 26, 2016 9:43 AM
To: dev at dpdk.org; Lu, Wenzhuo
Subject: e1000: randomly loosing link change events triggered by the peer

I found that in the current HEAD in master testing it with an I218-LM in 
autoneg mode, when link is forced to be renegociated by the peer (e.g. via 
ethtool on a peer Linux box) _some_ change events are lost.

It is quite random, but it seems to happen more while changing the speed than 
when changing the duplex mode.

However, when one or more link change events have been lost and the phy medium 
is disconnected and reconnected, the link speed and duplex mode are then 
correctly updated.

Marc

[Wenzhuo] Thanks for let us know this issue. May I ask some questions? Do you 
mean this NIC 0x155A?

0x15A2,  I218-LM (rev 03)

EAL: PCI device :00:19.0 on NUMA socket -1
EAL:   probe driver: 8086:15a2 rte_em_pmd
EAL:   PCI memory mapped at 0x7f85cf40
EAL:   PCI memory mapped at 0x7f85cf42
PMD: eth_em_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x15a2

I think this is not a NIC issue, but a general problem of the driver (or em 
code).
[Wenzhuo] I don?t have a 15a2 on hand. I?m using i350. I haven?t hit the same 
problem.  As you said it?s random. Would you like to let me know why you think 
it?s general not NIC specific? Thanks.

About how to reproduce this problem, you mean use these CLIs, ethtool ?s xxx 
advertise xxx, ethtool ?s xxx duplex half/full, to change the peer port?s 
configuration?

Correct. I modified l2fwd to check link status and print it on each port stats 
print iteration. Then from the peer I modified the link properties via ethtool.
[Wenzhuo] Would you like to give me a patch of your change? Thanks.

The result is that transitions from autoneg speeds and/or duplex mode settings 
are randomly not detected (rte_eth_link in rte_eth_dev_data is not updated), 
and it prints not-up-to-date state.

Marc

[dpdk-dev] is ixgbe supporting multi-segment mbuf?

[Lu, Wenzhuo]

Hi  Clarylin,


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Clarylin L
> Sent: Tuesday, March 29, 2016 4:24 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] is ixgbe supporting multi-segment mbuf?
> 
> ixgbe_recv_scattered_pkts was set to be the rx function. Receiving packets
I see this function is already deprecated. Do you use an old version? Would you 
like to try the newest code?

> smaller than mbuf size works perfectly. However, if an incoming packet is
> greater than the maximum acceptable length of one ?mbuf? data size, receiving
> does not work. In this case, isn't it supposed to use mbuf chaining to 
> receive?
> 
> The port has both jumbo_frame and enable_scatter being on. are these two
> flags good enough to make mbuf chaining going?