[dpdk-dev] [PATCH] fm10k: fix a crash bug when quit from testpmd

[Thomas Monjalon]

2015-11-12 12:57, Chen Jing D:
> From: "Chen Jing D(Mark)" 
> 
> When the fm10k port is closed, both func tx_queue_clean() and
> fm10k_tx_queue_release_mbufs_vec() will try to release buffer in
> SW ring. The latter func won't do sanity check on those pointers
> and cause crash.
> 
> The fix include 2 parts.
> 1. Remove Vector TX buffer release func since it can share the
>release functions with regular TX.
> 2. Add log to print out what actual Rx/Tx func is used.

2 parts mean 2 patches.

[...]
> + if (rx_using_sse)
> + PMD_INIT_LOG(ERR, "Use vector Rx func");
> + else
> + PMD_INIT_LOG(ERR, "Use regular Rx func");

Why using en error log level?

[dpdk-dev] [PATCH] ring: Fix memory leakage in rte_pmd_ring_devuninit

[Thomas Monjalon]

2015-11-20 19:24, Mauricio Vasquez B:
> When freeing the device it is also neccesary to free
> rx_queues and tx_queues
> 
> Signed-off-by: Mauricio Vasquez B  studenti.polito.it>

Applied with spacing fix, thanks

[dpdk-dev] [PATCH v3 11/11] bnx2x: Add BNX2X PMD versioning

[Rasesh Mody]

Add BNX2X PMD version, print it as part of adapter info.
Adjusted print adapter info output formatting.

This patch versions BNX2X PMD at 1.0.0.

Signed-off-by: Rasesh Mody 
---
 drivers/net/bnx2x/bnx2x.c |  101 +
 1 file changed, 65 insertions(+), 36 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 088c041..423a9bf 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -21,6 +21,7 @@
 #include "ecore_init.h"
 #include "ecore_init_ops.h"

+#include "rte_version.h"
 #include "rte_pci_dev_ids.h"

 #include 
@@ -28,6 +29,26 @@
 #include 
 #include 

+#define BNX2X_PMD_VER_PREFIX "BNX2X PMD"
+#define BNX2X_PMD_VERSION_MAJOR 1
+#define BNX2X_PMD_VERSION_MINOR 0
+#define BNX2X_PMD_VERSION_PATCH 0
+
+static inline const char *
+bnx2x_pmd_version(void)
+{
+   static char version[32];
+
+   snprintf(version, sizeof(version), "%s %s_%d.%d.%d",
+   BNX2X_PMD_VER_PREFIX,
+   BNX2X_DRIVER_VERSION,
+   BNX2X_PMD_VERSION_MAJOR,
+   BNX2X_PMD_VERSION_MINOR,
+   BNX2X_PMD_VERSION_PATCH);
+
+   return version;
+}
+
 static z_stream zlib_stream;

 #define EVL_VLID_MASK 0x0FFF
@@ -11734,87 +11755,95 @@ void bnx2x_print_adapter_info(struct bnx2x_softc *sc)

PMD_INIT_LOG(DEBUG, "\n\n===\n");
/* Hardware chip info. */
-   PMD_INIT_LOG(DEBUG, "%10s : %#08x\n", "ASIC", sc->devinfo.chip_id);
-   PMD_INIT_LOG(DEBUG, "%10s : %c%d\n", "Rev", (CHIP_REV(sc) >> 12) + 'A',
+   PMD_INIT_LOG(DEBUG, "%12s : %#08x", "ASIC", sc->devinfo.chip_id);
+   PMD_INIT_LOG(DEBUG, "%12s : %c%d", "Rev", (CHIP_REV(sc) >> 12) + 'A',
 (CHIP_METAL(sc) >> 4));

/* Bus info. */
-   PMD_INIT_LOG(DEBUG, "%10s : %d, ", "Bus PCIe", 
sc->devinfo.pcie_link_width);
+   PMD_INIT_LOG(DEBUG, "%12s : %d, ", "Bus PCIe", 
sc->devinfo.pcie_link_width);
switch (sc->devinfo.pcie_link_speed) {
case 1:
-   PMD_INIT_LOG(DEBUG, "2.5 Gbps\n");
+   PMD_INIT_LOG(DEBUG, "%23s", "2.5 Gbps");
break;
case 2:
-   PMD_INIT_LOG(DEBUG, "5 Gbps\n");
+   PMD_INIT_LOG(DEBUG, "%21s", "5 Gbps");
break;
case 4:
-   PMD_INIT_LOG(DEBUG, "8 Gbps\n");
+   PMD_INIT_LOG(DEBUG, "%21s", "8 Gbps");
break;
default:
-   PMD_INIT_LOG(DEBUG, "Unknown link speed\n");
+   PMD_INIT_LOG(DEBUG, "%33s", "Unknown link speed");
}

/* Device features. */
-   PMD_INIT_LOG(DEBUG, "%10s : ", "Flags");
+   PMD_INIT_LOG(DEBUG, "%12s : ", "Flags");

/* Miscellaneous flags. */
if (sc->devinfo.pcie_cap_flags & BNX2X_MSI_CAPABLE_FLAG) {
-   PMD_INIT_LOG(DEBUG, "MSI");
+   PMD_INIT_LOG(DEBUG, "%18s", "MSI");
i++;
}

if (sc->devinfo.pcie_cap_flags & BNX2X_MSIX_CAPABLE_FLAG) {
if (i > 0)
PMD_INIT_LOG(DEBUG, "|");
-   PMD_INIT_LOG(DEBUG, "MSI-X");
+   PMD_INIT_LOG(DEBUG, "%20s", "MSI-X");
i++;
}

-   PMD_INIT_LOG(DEBUG, "\n");
-
if (IS_PF(sc)) {
-   PMD_INIT_LOG(DEBUG, "\n%10s : ", "Queues");
+   PMD_INIT_LOG(DEBUG, "%12s : ", "Queues");
switch (sc->sp->rss_rdata.rss_mode) {
case ETH_RSS_MODE_DISABLED:
-   PMD_INIT_LOG(DEBUG, "None\n");
+   PMD_INIT_LOG(DEBUG, "%19s", "None");
break;
case ETH_RSS_MODE_REGULAR:
-   PMD_INIT_LOG(DEBUG, "RSS : %d\n", sc->num_queues);
+   PMD_INIT_LOG(DEBUG, "%18s : %d", "RSS", sc->num_queues);
break;
default:
-   PMD_INIT_LOG(DEBUG, "Unknown\n");
+   PMD_INIT_LOG(DEBUG, "%22s", "Unknown");
break;
}
}

+   /* RTE and Driver versions */
+   PMD_INIT_LOG(DEBUG, "%12s : %s", "DPDK",
+rte_version());
+   PMD_INIT_LOG(DEBUG, "%12s : %s", "Driver",
+bnx2x_pmd_version());
+
/* Firmware versions and device features. */
-   PMD_INIT_LOG(DEBUG, "%10s : %d.%d.%d\n%10s : %s\n",
+   PMD_INIT_LOG(DEBUG, "%12s : %d.%d.%d",
 "Firmware",
 BNX2X_5710_FW_MAJOR_VERSION,
 BNX2X_5710_FW_MINOR_VERSION,
-BNX2X_5710_FW_REVISION_VERSION,
+BNX2X_5710_FW_REVISION_VERSION);
+   PMD_INIT_LOG(DEBUG, "%12s : %s",
 "Bootcode", sc->devinfo.bc_ver_str);

-   PMD_INIT_LOG(DEBUG, "===\n");
-   PMD_INIT_LOG(DEBUG, "%10s : %u\n", "Bnx2

[dpdk-dev] [PATCH v3 10/11] config: Enable BNX2X driver build by default

[Rasesh Mody]

From: Harish Patil 

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
---
 config/common_bsdapp   |4 ++--
 config/common_linuxapp |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/config/common_bsdapp b/config/common_bsdapp
index 7872859..8c7ad50 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -229,9 +229,9 @@ CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
 CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8

 #
-# Compile burst-oriented Broadcom PMD driver
+# Compile burst-oriented QLogic BNX2X PMD
 #
-CONFIG_RTE_LIBRTE_BNX2X_PMD=n
+CONFIG_RTE_LIBRTE_BNX2X_PMD=y
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 04a7f1a..23d94b6 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -227,9 +227,9 @@ CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
 CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8

 #
-# Compile burst-oriented Broadcom PMD driver
+# Compile burst-oriented QLogic BNX2X PMD
 #
-CONFIG_RTE_LIBRTE_BNX2X_PMD=n
+CONFIG_RTE_LIBRTE_BNX2X_PMD=y
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
-- 
1.7.10.3

[dpdk-dev] [PATCH v3 09/11] maintainers: Add maintainers for BNX2X PMD

[Rasesh Mody]

Add maintainers for BNX2X PMD.
Add file path to BNX2X PMD guide.

Signed-off-by: Rasesh Mody 
---
 MAINTAINERS |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 840faeb..1c94a93 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -304,8 +304,12 @@ M: John McNamara 
 F: drivers/net/pcap/
 F: doc/guides/nics/pcap_ring.rst

-QLogic/Broadcom bnx2x
+QLogic bnx2x
+M: Sony Chacko 
+M: Harish Patil 
+M: Rasesh Mody 
 F: drivers/net/bnx2x/
+F: doc/guides/nics/bnx2x.rst

 Ring PMD
 M: Bruce Richardson 
-- 
1.7.10.3

[dpdk-dev] [PATCH v3 08/11] bnx2x: Handle zlib compatibility error

[Rasesh Mody]

Following error will be reported:

PMD: ecore_gunzip(): Newer version of zlib required, 1.2.5.2 or higher
EAL: Error - exiting with code: 1
  Cause: rte_eth_dev_start:err=-1, port=0

Signed-off-by: Rasesh Mody 
---
 doc/guides/nics/bnx2x.rst  |4 
 drivers/net/bnx2x/bnx2x.c  |   10 +-
 drivers/net/bnx2x/ecore_init_ops.h |   18 --
 3 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst
index 85ac1c3..2936d8b 100644
--- a/doc/guides/nics/bnx2x.rst
+++ b/doc/guides/nics/bnx2x.rst
@@ -86,6 +86,10 @@ Prerequisites
   `QLogic Driver Download Center `_
   to get the required firmware.

+- This driver relies on external zlib library for unzipping the firmware image.
+  The zlib library is not part of DPDK and must be installed separately. The
+  minimum version of zlib library required is v1.2.5.2.
+
 Pre-Installation Configuration
 --

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index f125c79..088c041 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -10029,6 +10029,7 @@ static int bnx2x_init_hw_common(struct bnx2x_softc *sc)
 {
uint8_t abs_func_id;
uint32_t val;
+   int ret = 0;

PMD_DRV_LOG(DEBUG, "starting common init for func %d", SC_ABS_FUNC(sc));

@@ -10328,7 +10329,9 @@ static int bnx2x_init_hw_common(struct bnx2x_softc *sc)
DELAY(2);
}

-   ecore_init_block(sc, BLOCK_TSEM, PHASE_COMMON);
+   ret = ecore_init_block(sc, BLOCK_TSEM, PHASE_COMMON);
+   if (ret != 0)
+   return ret;
ecore_init_block(sc, BLOCK_USEM, PHASE_COMMON);
ecore_init_block(sc, BLOCK_CSEM, PHASE_COMMON);
ecore_init_block(sc, BLOCK_XSEM, PHASE_COMMON);
@@ -11567,7 +11570,12 @@ static int ecore_gunzip(struct bnx2x_softc *sc, const 
uint8_t * zbuf, int len)
}

memset(&zlib_stream, 0, sizeof(zlib_stream));
+#if ZLIB_VERNUM < 0x1252
+   PMD_INIT_LOG(ERR, "Newer version of zlib required, 1.2.5.2 or higher");
+   return Z_VERSION_ERROR;
+#else
zlib_stream.next_in = zbuf + data_begin;
+#endif
zlib_stream.avail_in = len - data_begin;
zlib_stream.next_out = sc->gz_buf;
zlib_stream.avail_out = FW_BUF_SIZE;
diff --git a/drivers/net/bnx2x/ecore_init_ops.h 
b/drivers/net/bnx2x/ecore_init_ops.h
index b6f9832..cd042bb 100644
--- a/drivers/net/bnx2x/ecore_init_ops.h
+++ b/drivers/net/bnx2x/ecore_init_ops.h
@@ -150,18 +150,18 @@ static void ecore_wr_64(struct bnx2x_softc *sc, uint32_t 
reg, uint32_t val_lo,
REG_WR_DMAE_LEN(sc, reg, wb_write, 2);
 }

-static void ecore_init_wr_zp(struct bnx2x_softc *sc, uint32_t addr, uint32_t 
len,
+static int ecore_init_wr_zp(struct bnx2x_softc *sc, uint32_t addr, uint32_t 
len,
 uint32_t blob_off)
 {
const uint8_t *data = NULL;
-   int rc;
+   int rc = 0;
uint32_t i;

data = ecore_sel_blob(sc, addr, data) + blob_off*4;

rc = ecore_gunzip(sc, data, len);
if (rc)
-   return;
+   return rc;

/* gunzip_outlen is in dwords */
len = GUNZIP_OUTLEN(sc);
@@ -170,9 +170,11 @@ static void ecore_init_wr_zp(struct bnx2x_softc *sc, 
uint32_t addr, uint32_t len
ECORE_CPU_TO_LE32(((uint32_t 
*)GUNZIP_BUF(sc))[i]);

ecore_write_big_buf_wb(sc, addr, len);
+
+   return rc;
 }

-static void ecore_init_block(struct bnx2x_softc *sc, uint32_t block, uint32_t 
stage)
+static int ecore_init_block(struct bnx2x_softc *sc, uint32_t block, uint32_t 
stage)
 {
uint16_t op_start =
INIT_OPS_OFFSETS(sc)[BLOCK_OPS_IDX(block, stage,
@@ -183,10 +185,11 @@ static void ecore_init_block(struct bnx2x_softc *sc, 
uint32_t block, uint32_t st
const union init_op *op;
uint32_t op_idx, op_type, addr, len;
const uint32_t *data, *data_base;
+   int ret = 0;

/* If empty block */
if (op_start == op_end)
-   return;
+   return ret;

data_base = INIT_DATA(sc);

@@ -221,7 +224,9 @@ static void ecore_init_block(struct bnx2x_softc *sc, 
uint32_t block, uint32_t st
ecore_init_fill(sc, addr, 0, op->zero.len);
break;
case OP_ZP:
-   ecore_init_wr_zp(sc, addr, len, op->arr_wr.data_off);
+   ret = ecore_init_wr_zp(sc, addr, len, 
op->arr_wr.data_off);
+   if (ret != 0)
+   return ret;
break;
case OP_WR_64:
ecore_init_wr_64(sc, addr, data, len);
@@ -254,6 +259,7 @@ static void ecore_init_block(struct bnx2x_softc *sc, 
uint32_t block, uint32_t st
break;
}
}
+   return ret;
 }


--

[dpdk-dev] [PATCH v3 07/11] bnx2x: Linux 32bit enablement

[Rasesh Mody]

Compile tested.

Signed-off-by: Rasesh Mody 
---
 doc/guides/nics/bnx2x.rst|8 
 drivers/net/bnx2x/bnx2x.h|   12 ++--
 drivers/net/bnx2x/bnx2x_ethdev.c |2 +-
 drivers/net/bnx2x/bnx2x_rxtx.c   |   11 +++
 drivers/net/bnx2x/bnx2x_vfpf.c   |4 ++--
 5 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst
index 5647a90..85ac1c3 100644
--- a/doc/guides/nics/bnx2x.rst
+++ b/doc/guides/nics/bnx2x.rst
@@ -143,6 +143,14 @@ command::
cd 
make config T=i686-native-linuxapp-gcc install

+To compile BNX2X PMD for Linux i686 gcc target, run the following "make"
+command:
+
+.. code-block:: console
+
+   cd 
+   make config T=i686-native-linuxapp-gcc install
+
 To compile BNX2X PMD for FreeBSD x86_64 clang target, run the following "gmake"
 command::

diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 0362e4b..55ffbf1 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1457,22 +1457,22 @@ void bnx2x_reg_write16(struct bnx2x_softc *sc, size_t 
offset, uint16_t val);
 void bnx2x_reg_write32(struct bnx2x_softc *sc, size_t offset, uint32_t val);
 #else
 #define bnx2x_reg_write8(sc, offset, val)\
-   *((volatile uint8_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = val
+   *((volatile uint8_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)) = 
val

 #define bnx2x_reg_write16(sc, offset, val)\
-   *((volatile uint16_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = 
val
+   *((volatile uint16_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)) = 
val

 #define bnx2x_reg_write32(sc, offset, val)\
-   *((volatile uint32_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = 
val
+   *((volatile uint32_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)) = 
val

 #define bnx2x_reg_read8(sc, offset)\
-   (*((volatile uint8_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)))
+   (*((volatile uint8_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)))

 #define bnx2x_reg_read16(sc, offset)\
-   (*((volatile uint16_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)))
+   (*((volatile uint16_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)))

 #define bnx2x_reg_read32(sc, offset)\
-   (*((volatile uint32_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)))
+   (*((volatile uint32_t*)((uintptr_t)sc->bar[BAR0].base_addr + offset)))
 #endif

 #define REG_ADDR(sc, offset) (((uint64_t)sc->bar[BAR0].base_addr) + (offset))
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 0117049..69df02e 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -442,7 +442,7 @@ bnx2x_common_dev_init(struct rte_eth_dev *eth_dev, int 
is_vf)
sc->bar[BAR0].base_addr = (void *)pci_dev->mem_resource[0].addr;
if (is_vf)
sc->bar[BAR1].base_addr = (void *)
-   ((uint64_t)pci_dev->mem_resource[0].addr + 
PXP_VF_ADDR_DB_START);
+   ((uintptr_t)pci_dev->mem_resource[0].addr + 
PXP_VF_ADDR_DB_START);
else
sc->bar[BAR1].base_addr = pci_dev->mem_resource[2].addr;

diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index c25a898..0f8b9bd 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
@@ -110,8 +110,10 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,

PMD_INIT_LOG(DEBUG, "fp[%02d] req_bd=%u, thresh=%u, usable_bd=%lu, "
   "total_bd=%lu, rx_pages=%u, cq_pages=%u",
-  queue_idx, nb_desc, rxq->rx_free_thresh, 
USABLE_RX_BD(rxq),
-  TOTAL_RX_BD(rxq), rxq->nb_rx_pages, rxq->nb_cq_pages);
+  queue_idx, nb_desc, rxq->rx_free_thresh,
+  (unsigned long)USABLE_RX_BD(rxq),
+  (unsigned long)TOTAL_RX_BD(rxq), rxq->nb_rx_pages,
+  rxq->nb_cq_pages);

/* Allocate RX ring hardware descriptors */
dma_size = rxq->nb_rx_desc * sizeof(struct eth_rx_bd);
@@ -291,8 +293,9 @@ bnx2x_dev_tx_queue_setup(struct rte_eth_dev *dev,

PMD_INIT_LOG(DEBUG, "fp[%02d] req_bd=%u, thresh=%u, usable_bd=%lu, "
 "total_bd=%lu, tx_pages=%u",
-queue_idx, nb_desc, txq->tx_free_thresh, USABLE_TX_BD(txq),
-TOTAL_TX_BD(txq), txq->nb_tx_pages);
+queue_idx, nb_desc, txq->tx_free_thresh,
+(unsigned long)USABLE_TX_BD(txq),
+(unsigned long)TOTAL_TX_BD(txq), txq->nb_tx_pages);

/* Allocate TX ring hardware descriptors */
tsize = txq->nb_tx_desc * sizeof(union eth_tx_bd_types);
diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index b3fcceb..765cc92 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -66,8 +66,8 @@ bnx2x_check_bull(struct bnx2x_soft

[dpdk-dev] [PATCH v3 06/11] bnx2x: FreeBSD enablement

[Rasesh Mody]

Compile tested.

Signed-off-by: Rasesh Mody 
---
 doc/guides/nics/bnx2x.rst|8 
 drivers/net/bnx2x/bnx2x.c|9 +
 drivers/net/bnx2x/bnx2x.h|   23 +++
 drivers/net/bnx2x/ecore_sp.h |6 ++
 4 files changed, 46 insertions(+)

diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst
index 7a94080..5647a90 100644
--- a/doc/guides/nics/bnx2x.rst
+++ b/doc/guides/nics/bnx2x.rst
@@ -155,6 +155,14 @@ command::
cd 
gmake config T=x86_64-native-bsdapp-gcc install 
-Wl,-rpath=/usr/local/lib/gcc48 CC=gcc48

+To compile BNX2X PMD for FreeBSD x86_64 gcc target, run the following "gmake"
+command:
+
+.. code-block:: console
+
+   cd 
+   gmake config T=x86_64-native-bsdapp-gcc install 
-Wl,-rpath=/usr/local/lib/gcc48 CC=gcc48
+
 Linux
 -

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index c149ac5..f125c79 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -9505,13 +9505,22 @@ static int bnx2x_pci_get_caps(struct bnx2x_softc *sc)
return -ENOMEM;
}

+#ifndef __FreeBSD__
pci_read(sc, PCI_STATUS, &status, 2);
if (!(status & PCI_STATUS_CAP_LIST)) {
+#else
+   pci_read(sc, PCIR_STATUS, &status, 2);
+   if (!(status & PCIM_STATUS_CAPPRESENT)) {
+#endif
PMD_DRV_LOG(NOTICE, "PCIe capability reading failed");
return -1;
}

+#ifndef __FreeBSD__
pci_read(sc, PCI_CAPABILITY_LIST, &pci_cap.next, 1);
+#else
+   pci_read(sc, PCIR_CAP_PTR, &pci_cap.next, 1);
+#endif
while (pci_cap.next) {
cap->addr = pci_cap.next & ~3;
pci_read(sc, pci_cap.next & ~3, &pci_cap, 2);
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index b049bd1..0362e4b 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -16,6 +16,12 @@
 #ifndef __BNX2X_H__
 #define __BNX2X_H__

+#ifdef __FreeBSD__
+#define __LITTLE_ENDIAN _LITTLE_ENDIAN
+#define __BIG_ENDIAN_BIG_ENDIAN
+#define __BYTE_ORDER_BYTE_ORDER
+#endif
+
 #include "bnx2x_ethdev.h"

 #if __BYTE_ORDER == __LITTLE_ENDIAN
@@ -47,6 +53,7 @@

 #include "elink.h"

+#ifndef __FreeBSD__
 #include 

 #define PCIY_PMG   PCI_CAP_ID_PM
@@ -68,11 +75,15 @@
 #define PCIM_PSTAT_PMEENABLE   PCI_PM_CTRL_PME_ENABLE
 #define PCIR_MSIX_CTRL PCI_MSIX_FLAGS
 #define PCIM_MSIXCTRL_TABLE_SIZE   PCI_MSIX_FLAGS_QSIZE
+#else
+#include 
+#endif

 #define IFM_10G_CX420 /* 10GBase CX4 copper */
 #define IFM_10G_TWINAX 22 /* 10GBase Twinax copper */
 #define IFM_10G_T  26 /* 10GBase-T - RJ45 */

+#ifndef __FreeBSD__
 #define PCIR_EXPRESS_DEVICE_STAPCI_EXP_TYPE_RC_EC
 #define PCIM_EXP_STA_TRANSACTION_PND   PCI_EXP_DEVSTA_TRPND
 #define PCIR_EXPRESS_LINK_STA  PCI_EXP_LNKSTA
@@ -81,6 +92,16 @@
 #define PCIR_EXPRESS_DEVICE_CTLPCI_EXP_DEVCTL
 #define PCIM_EXP_CTL_MAX_PAYLOAD   PCI_EXP_DEVCTL_PAYLOAD
 #define PCIM_EXP_CTL_MAX_READ_REQUEST  PCI_EXP_DEVCTL_READRQ
+#else
+#define PCIR_EXPRESS_DEVICE_STAPCIER_DEVICE_STA
+#define PCIM_EXP_STA_TRANSACTION_PND   PCIEM_STA_TRANSACTION_PND
+#define PCIR_EXPRESS_LINK_STA  PCIER_LINK_STA
+#define PCIM_LINK_STA_WIDTHPCIEM_LINK_STA_WIDTH
+#define PCIM_LINK_STA_SPEEDPCIEM_LINK_STA_SPEED
+#define PCIR_EXPRESS_DEVICE_CTLPCIER_DEVICE_CTL
+#define PCIM_EXP_CTL_MAX_PAYLOAD   PCIEM_CTL_MAX_PAYLOAD
+#define PCIM_EXP_CTL_MAX_READ_REQUEST  PCIEM_CTL_MAX_READ_REQUEST
+#endif

 #ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
@@ -148,6 +169,7 @@ struct bnx2x_device_type {
 #endif
 #define MCLBYTES  (1 << MCLSHIFT)

+#if !defined(MJUMPAGESIZE)
 #if BNX2X_PAGE_SIZE < 2048
 #define MJUMPAGESIZEMCLBYTES
 #elif BNX2X_PAGE_SIZE <= 8192
@@ -155,6 +177,7 @@ struct bnx2x_device_type {
 #else
 #define MJUMPAGESIZE(8 * 1024)
 #endif
+#endif
 #define MJUM9BYTES  (9 * 1024)
 #define MJUM16BYTES (16 * 1024)

diff --git a/drivers/net/bnx2x/ecore_sp.h b/drivers/net/bnx2x/ecore_sp.h
index 8e65584..a0b7b75 100644
--- a/drivers/net/bnx2x/ecore_sp.h
+++ b/drivers/net/bnx2x/ecore_sp.h
@@ -16,6 +16,12 @@
 #ifndef ECORE_SP_H
 #define ECORE_SP_H

+#ifdef __FreeBSD__
+#define __LITTLE_ENDIAN _LITTLE_ENDIAN
+#define __BIG_ENDIAN_BIG_ENDIAN
+#define __BYTE_ORDER_BYTE_ORDER
+#endif
+
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #ifndef LITTLE_ENDIAN
 #define LITTLE_ENDIAN
-- 
1.7.10.3

[dpdk-dev] [PATCH v3 05/11] bnx2x: Add LICENSE.bnx2x_pmd and update source files

[Rasesh Mody]

Signed-off-by: Rasesh Mody 
---
 drivers/net/bnx2x/LICENSE.bnx2x_pmd |   28 
 drivers/net/bnx2x/bnx2x.c   |   29 -
 drivers/net/bnx2x/bnx2x.h   |   29 -
 drivers/net/bnx2x/bnx2x_ethdev.c|4 
 drivers/net/bnx2x/bnx2x_ethdev.h|4 
 drivers/net/bnx2x/bnx2x_logs.h  |4 
 drivers/net/bnx2x/bnx2x_rxtx.c  |4 
 drivers/net/bnx2x/bnx2x_rxtx.h  |4 
 drivers/net/bnx2x/bnx2x_stats.c |   27 +++
 drivers/net/bnx2x/bnx2x_stats.h |   27 +++
 drivers/net/bnx2x/bnx2x_vfpf.c  |4 
 drivers/net/bnx2x/bnx2x_vfpf.h  |4 
 drivers/net/bnx2x/debug.c   |   27 +++
 drivers/net/bnx2x/ecore_fw_defs.h   |   27 ---
 drivers/net/bnx2x/ecore_hsi.h   |   27 ---
 drivers/net/bnx2x/ecore_init.h  |   27 +++
 drivers/net/bnx2x/ecore_init_ops.h  |   27 +++
 drivers/net/bnx2x/ecore_mfw_req.h   |   27 ---
 drivers/net/bnx2x/ecore_reg.h   |   27 ---
 drivers/net/bnx2x/ecore_sp.c|   27 +++
 drivers/net/bnx2x/ecore_sp.h|   27 +++
 drivers/net/bnx2x/elink.c   |   29 -
 drivers/net/bnx2x/elink.h   |   29 -
 23 files changed, 109 insertions(+), 360 deletions(-)
 create mode 100644 drivers/net/bnx2x/LICENSE.bnx2x_pmd

diff --git a/drivers/net/bnx2x/LICENSE.bnx2x_pmd 
b/drivers/net/bnx2x/LICENSE.bnx2x_pmd
new file mode 100644
index 000..96c7c1e
--- /dev/null
+++ b/drivers/net/bnx2x/LICENSE.bnx2x_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 Broadcom Corporation nor the name of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written consent.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS'
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
+ * THE POSSIBILITY OF SUCH DAMAGE.
+ */
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 5d41d4f..c149ac5 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -1,37 +1,16 @@
 /*-
- * Copyright (c) 2007-2013 QLogic Corporation. All rights reserved.
+ * Copyright (c) 2007-2013 Broadcom Corporation.
  *
  * Eric Davis
  * David Christensen 
  * Gary Zambrano 
  *
  * Copyright (c) 2013-2015 Brocade Communications Systems, Inc.
+ * Copyright (c) 2015 QLogic Corporation.
  * All rights reserved.
+ * www.qlogic.com
  *
- * 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 Broadcom 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 

[dpdk-dev] [PATCH v3 04/11] doc: Add BNX2X PMD documentationdoc: Add BNX2X PMD documentation

[Rasesh Mody]

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
---
 doc/guides/nics/bnx2x.rst |  314 +
 1 file changed, 314 insertions(+)
 create mode 100644 doc/guides/nics/bnx2x.rst

diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst
new file mode 100644
index 000..7a94080
--- /dev/null
+++ b/doc/guides/nics/bnx2x.rst
@@ -0,0 +1,314 @@
+..  BSD LICENSE
+Copyright (c) 2015 QLogic Corporation
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of QLogic Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+BNX2X Poll Mode Driver
+==
+
+The BNX2X poll mode driver library (**librte_pmd_bnx2x**) implements support
+for **QLogic 578xx** 10/20 Gbps family of adapters as well as their virtual
+functions (VF) in SR-IOV context. It is supported on several standard Linux
+distros like Red Hat 7.x and SLES12 OS. It is compile-tested under FreeBSD OS.
+
+More information can be found at `QLogic Corporation's Official Website
+`_.
+
+Supported Features
+--
+
+BNX2X PMD has support for:
+
+- Base L2 features
+- Unicast/multicast filtering
+- Promiscuous mode
+- Port hardware statistics
+- SR-IOV VF
+
+Non-supported Features
+--
+
+The features not yet supported include:
+
+- TSS (Transmit Side Scaling)
+- RSS (Receive Side Scaling)
+- LRO/TSO offload
+- Checksum offload
+- SR-IOV PF
+
+Co-existence considerations
+---
+
+- BCM578xx being a CNA can have both NIC and Storage personalities.
+  However, coexistence with storage protocol drivers (cnic, bnx2fc and
+  bnx2fi) is not supported on the same adapter. So storage personality
+  has to be disabled on that adapter when used in DPDK applications.
+
+- For SR-IOV case, bnx2x PMD will be used to bind to SR-IOV VF device and
+  Linux native kernel driver (bnx2x) will be attached to SR-IOV PF.
+
+
+Supported QLogic NICs
+-
+
+- 578xx
+
+Prerequisites
+-
+
+- Requires firmware version **7.2.51.0**. It is inbox on most of the
+  standard Linux distros. If it is not available visit
+  `QLogic Driver Download Center `_
+  to get the required firmware.
+
+Pre-Installation Configuration
+--
+
+Config File Options
+~~~
+
+The following options can be modified in the ``.config`` file. Please note that
+enabling debugging options may affect system performance.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_PMD`` (default **y**)
+
+  Toggle compilation of bnx2x driver.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG`` (default **n**)
+
+  Toggle display of generic debugging messages.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT`` (default **n**)
+
+  Toggle display of initialization related messages.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX`` (default **n**)
+
+  Toggle display of transmit fast path run-time messages.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX`` (default **n**)
+
+  Toggle display of receive fast path run-time messages.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC`` (default **n**)
+
+  Toggle display of register reads and writes.
+
+
+.. _bnx2x_driver-compilation:
+
+Driver Compilation
+~~
+
+BNX2X PMD for Linux x86_64 gcc target, run the following "make"
+command::
+
+   cd 
+   make config T=x86_64-native-linuxapp-gcc install
+
+To compile BNX2X PMD for Linux x86_64 clang target, run the following "make"
+command::
+
+   cd 
+   make config T=x86_64-native-linuxapp-clang install
+
+To

[dpdk-dev] [PATCH v3 03/11] bnx2x: Add periodic debug option

[Rasesh Mody]

From: Harish Patil 

The periodic debug option is used to collect periodic
events like statistics, register access etc and won't
interfere with user-level messages.

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
---
 config/common_bsdapp |1 +
 config/common_linuxapp   |1 +
 drivers/net/bnx2x/Makefile   |4 ++--
 drivers/net/bnx2x/bnx2x.c|6 +++---
 drivers/net/bnx2x/bnx2x.h|2 +-
 drivers/net/bnx2x/bnx2x_ethdev.c |2 +-
 drivers/net/bnx2x/bnx2x_logs.h   |8 
 drivers/net/bnx2x/bnx2x_stats.c  |2 +-
 drivers/net/bnx2x/debug.c|   36 
 9 files changed, 38 insertions(+), 24 deletions(-)

diff --git a/config/common_bsdapp b/config/common_bsdapp
index bdf1fcd..7872859 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -237,6 +237,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n

 #
 # Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
diff --git a/config/common_linuxapp b/config/common_linuxapp
index f72c46d..04a7f1a 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -235,6 +235,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
 CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n

 #
 # Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
diff --git a/drivers/net/bnx2x/Makefile b/drivers/net/bnx2x/Makefile
index 87f31b6..13bbc81 100644
--- a/drivers/net/bnx2x/Makefile
+++ b/drivers/net/bnx2x/Makefile
@@ -5,7 +5,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
 #
 LIB = librte_pmd_bnx2x.a

-CFLAGS += -O3 -g
+CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)
 CFLAGS += -DZLIB_CONST

@@ -23,7 +23,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_ethdev.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += ecore_sp.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += elink.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_vfpf.c
-SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_DEBUG) += debug.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC) += debug.c

 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += lib/librte_eal lib/librte_ether 
lib/librte_hash
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index fed7a06..5d41d4f 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -4335,7 +4335,7 @@ static void bnx2x_eq_int(struct bnx2x_softc *sc)
 /* handle eq element */
switch (opcode) {
case EVENT_RING_OPCODE_STAT_QUERY:
-   PMD_DRV_LOG(DEBUG, "got statistics completion event %d",
+   PMD_DEBUG_PERIODIC_LOG(DEBUG, "got statistics 
completion event %d",
sc->stats_comp++);
/* nothing to do with stats comp */
goto next_spqe;
@@ -4486,7 +4486,7 @@ static int bnx2x_handle_sp_tq(struct bnx2x_softc *sc)
/* SP events: STAT_QUERY and others */
if (status & BNX2X_DEF_SB_IDX) {
 /* handle EQ completions */
-   PMD_DRV_LOG(DEBUG, "---> EQ INTR <---");
+   PMD_DEBUG_PERIODIC_LOG(DEBUG, "---> EQ INTR <---");
bnx2x_eq_int(sc);
bnx2x_ack_sb(sc, sc->igu_dsb_id, USTORM_ID,
   le16toh(sc->def_idx), IGU_INT_NOP, 1);
@@ -4559,7 +4559,7 @@ int bnx2x_intr_legacy(struct bnx2x_softc *sc, int scan_fp)
return 0;
}

-   PMD_DRV_LOG(DEBUG, "Interrupt status 0x%04x", status);
+   PMD_DEBUG_PERIODIC_LOG(DEBUG, "Interrupt status 0x%04x", status);
//bnx2x_dump_status_block(sc);

FOR_EACH_ETH_QUEUE(sc, i) {
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 867b92a..a5f9f1d 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1445,7 +1445,7 @@ struct bnx2x_func_init_params {
 #define BAR1 2
 #define BAR2 4

-#ifdef RTE_LIBRTE_BNX2X_DEBUG
+#ifdef RTE_LIBRTE_BNX2X_DEBUG_PERIODIC
 uint8_t bnx2x_reg_read8(struct bnx2x_softc *sc, size_t offset);
 uint16_t bnx2x_reg_read16(struct bnx2x_softc *sc, size_t offset);
 uint32_t bnx2x_reg_read32(struct bnx2x_softc *sc, size_t offset);
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 36779ea..d09c72f 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -52,7 +52,7 @@ bnx2x_interrupt_action(struct rte_eth_dev *dev)
struct bnx2x_softc *sc = dev->data->dev_private;
uint32_t link_status;

-   PMD_DRV_LOG(INFO, "Interrupt handled");
+   PMD_DEBUG_PERIODIC_LOG(INFO, "Interrupt handled");

if (bnx2x_intr_legacy(sc, 0))
DELAY_MS(250);
diff --git a/drivers/net/bnx2x/bnx2x_logs.h b/drivers/net/bnx2x/bnx2x_logs.h
index d31c253..32f8c62 100644
--- a/drivers/net/

[dpdk-dev] [PATCH v3 02/11] bnx2x: Fix x86_64-native-linuxapp-clang build error

[Rasesh Mody]

From: Harish Patil 

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

Signed-off-by: Harish Patil 
---
 drivers/net/bnx2x/ecore_hsi.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/bnx2x/ecore_hsi.h b/drivers/net/bnx2x/ecore_hsi.h
index a4ed9b5..fe72938 100644
--- a/drivers/net/bnx2x/ecore_hsi.h
+++ b/drivers/net/bnx2x/ecore_hsi.h
@@ -2529,7 +2529,7 @@ struct shmem2_region {
#define SHMEM_EEE_SUPPORTED_SHIFT  16
#define SHMEM_EEE_ADV_STATUS_MASK  0x00f0
#define SHMEM_EEE_100M_ADV (1<<0)
-   #define SHMEM_EEE_1G_ADV   (1<<1)
+   #define SHMEM_EEE_1G_ADV   (1U<<1)
#define SHMEM_EEE_10G_ADV  (1<<2)
#define SHMEM_EEE_ADV_STATUS_SHIFT 20
#define SHMEM_EEE_LP_ADV_STATUS_MASK   0x0f00
-- 
1.7.10.3

[dpdk-dev] [PATCH v3 01/11] bnx2x: Update VF to support newer PF drivers

[Rasesh Mody]

From: Harish Patil 

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

Signed-off-by: Harish Patil 
---
 drivers/net/bnx2x/bnx2x_vfpf.c |   11 +--
 drivers/net/bnx2x/bnx2x_vfpf.h |   15 +++
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index 661f0a5..39fd59a 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -257,8 +257,15 @@ int bnx2x_vf_get_resources(struct bnx2x_softc *sc, uint8_t 
tx_count, uint8_t rx_

acq->bulletin_addr = sc->pf2vf_bulletin_mapping.paddr;

-   BNX2X_TLV_APPEND(acq, acq->first_tlv.length, BNX2X_VF_TLV_LIST_END,
-   sizeof(struct channel_list_end_tlv));
+   /* Request physical port identifier */
+   BNX2X_TLV_APPEND(acq, acq->first_tlv.length,
+BNX2X_VF_TLV_PHYS_PORT_ID,
+sizeof(struct channel_tlv));
+
+   BNX2X_TLV_APPEND(acq,
+(acq->first_tlv.length + sizeof(struct channel_tlv)),
+BNX2X_VF_TLV_LIST_END,
+sizeof(struct channel_list_end_tlv));

/* requesting the resources in loop */
obtain_status = bnx2x_loop_obtain_resources(sc);
diff --git a/drivers/net/bnx2x/bnx2x_vfpf.h b/drivers/net/bnx2x/bnx2x_vfpf.h
index 94ce9f0..4f25321 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.h
+++ b/drivers/net/bnx2x/bnx2x_vfpf.h
@@ -34,12 +34,24 @@ struct vf_resource_query {
 #defineBNX2X_VF_Q_FLAG_DHC 0x0200
 #defineBNX2X_VF_Q_FLAG_LEADING_RSS 0x0400

+#define TLV_BUFFER_SIZE1024
+
+/* general tlv header (used for both vf->pf request and pf->vf response) */
+struct channel_tlv {
+   uint16_t type;
+   uint16_t length;
+};
+
 struct vf_first_tlv {
uint16_t type;
uint16_t length;
uint32_t reply_offset;
 };

+struct tlv_buffer_size {
+   uint8_t tlv_buffer[TLV_BUFFER_SIZE];
+};
+
 /* tlv struct for all PF replies except acquire */
 struct vf_common_reply_tlv {
uint16_t type;
@@ -244,12 +256,14 @@ union query_tlvs {
struct vf_release_tlv   release;
struct vf_rss_tlv   update_rss;
struct channel_list_end_tlv list_end;
+   struct tlv_buffer_size  tlv_buf_size;
 };

 union resp_tlvs {
struct vf_common_reply_tlv  common_reply;
struct vf_acquire_resp_tlv  acquire_resp;
struct channel_list_end_tlv list_end;
+   struct tlv_buffer_size  tlv_buf_size;
 };

 /* struct allocated by VF driver, PF sends updates to VF via bulletin */
@@ -300,6 +314,7 @@ enum channel_tlvs {
BNX2X_VF_TLV_PF_SET_MAC,
BNX2X_VF_TLV_PF_SET_VLAN,
BNX2X_VF_TLV_UPDATE_RSS,
+   BNX2X_VF_TLV_PHYS_PORT_ID,
BNX2X_VF_TLV_MAX
 };

-- 
1.7.10.3

[dpdk-dev] [PATCH v3 00/11] bnx2x: Enhancement, fixes, licensing and doumentation

[Rasesh Mody]

Hi Thomas,

  This patch set consists of enhancements, fixes, licensing and
documentation changes for the QLogic bnx2x Poll Mode Driver. The patches
addresses the latets review feedback and have been generated and tested
against latest dpdk tree.

This patch set enables the BNX2X PMD and versions bnx2x PMD driver at 1.0.0.

Thanks!
Rasesh

Harish Patil (4):
  bnx2x: Update VF to support newer PF drivers
  bnx2x: Fix x86_64-native-linuxapp-clang build error
  bnx2x: Add periodic debug option
  config: Enable BNX2X driver build by default

Rasesh Mody (7):
  doc: Add BNX2X PMD documentationdoc: Add BNX2X PMD documentation
  bnx2x: Add LICENSE.bnx2x_pmd and update source files
  bnx2x: FreeBSD enablement
  bnx2x: Linux 32bit enablement
  bnx2x: Handle zlib compatibility error
  maintainers: Add maintainers for BNX2X PMD
  bnx2x: Add BNX2X PMD versioning

 MAINTAINERS |6 +-
 config/common_bsdapp|5 +-
 config/common_linuxapp  |5 +-
 doc/guides/nics/bnx2x.rst   |  334 +++
 drivers/net/bnx2x/LICENSE.bnx2x_pmd |   28 +++
 drivers/net/bnx2x/Makefile  |4 +-
 drivers/net/bnx2x/bnx2x.c   |  155 +---
 drivers/net/bnx2x/bnx2x.h   |   66 +++
 drivers/net/bnx2x/bnx2x_ethdev.c|8 +-
 drivers/net/bnx2x/bnx2x_ethdev.h|4 +
 drivers/net/bnx2x/bnx2x_logs.h  |   12 ++
 drivers/net/bnx2x/bnx2x_rxtx.c  |   15 +-
 drivers/net/bnx2x/bnx2x_rxtx.h  |4 +
 drivers/net/bnx2x/bnx2x_stats.c |   29 +--
 drivers/net/bnx2x/bnx2x_stats.h |   27 +--
 drivers/net/bnx2x/bnx2x_vfpf.c  |   19 +-
 drivers/net/bnx2x/bnx2x_vfpf.h  |   19 ++
 drivers/net/bnx2x/debug.c   |   63 +++
 drivers/net/bnx2x/ecore_fw_defs.h   |   27 +--
 drivers/net/bnx2x/ecore_hsi.h   |   29 +--
 drivers/net/bnx2x/ecore_init.h  |   27 +--
 drivers/net/bnx2x/ecore_init_ops.h  |   45 ++---
 drivers/net/bnx2x/ecore_mfw_req.h   |   27 +--
 drivers/net/bnx2x/ecore_reg.h   |   27 +--
 drivers/net/bnx2x/ecore_sp.c|   27 +--
 drivers/net/bnx2x/ecore_sp.h|   33 +---
 drivers/net/bnx2x/elink.c   |   29 +--
 drivers/net/bnx2x/elink.h   |   29 +--
 28 files changed, 655 insertions(+), 448 deletions(-)
 create mode 100644 doc/guides/nics/bnx2x.rst
 create mode 100644 drivers/net/bnx2x/LICENSE.bnx2x_pmd

-- 
1.7.10.3

[dpdk-dev] [PATCH] ethdev: add a missing sanity check for nb_tx_desc during txq setup

[Thomas Monjalon]

> > Add a sanity check for number of tx descriptors requested during tx
> > queue setup.  Return -EINVAL if the number requested does not meet
> > the tx descriptor requirements of the device.
> > 
> > Fixes: 80a1deb4c77a ("ethdev: add API to retrieve queue information")
> > 
> > Signed-off-by: Rahul Lakkireddy 
> > Signed-off-by: Kumar Sanghvi 
> > ---
> 
>  Acked-by: Konstantin Ananyev 
> Thanks for catching it.

Applied, thanks

[dpdk-dev] [PATCH] i40e: fix the write flush in vf driver

[Thomas Monjalon]

> For i40e vf driver, should use I40EVF_WRITE_FLUSH to flush configuration but 
> not I40E_WRITE_FLUSH. This patch fixed this issue.
> 
> Fixes: be6c228d4da3 (i40evf: support Rx interrupt)
> 
> Reported-by: Qian Xu 
> Signed-off-by: Jingjing Wu 
> Acked-by: Helin Zhang 

Applied, thanks

[dpdk-dev] [PATCH] i40e: fix the issue dcb cannot be configured when FW version is 5.x

[Thomas Monjalon]

> When NVM version is updated to 5.x, DCB can not be configured. This issue is 
> because of the FW version validation is not correct.
> This patch fixed this issue.
> 
> Fixes: c8b9a3e3fe1b (i40e: support DCB mode)
> 
> Signed-off-by: Jingjing Wu 

Tested-by: Yulong Pei 

Applied, thanks

[dpdk-dev] [PATCH] i40e: skip any phy config as a workaround

[Thomas Monjalon]

2015-11-17 15:09, Helin Zhang:
> As firmware does not support any link control from software driver
> side, any phy config should be ignored as a workaround. Otherwise
> the link might not be up again after binding back to kernel driver.
> 
> Signed-off-by: Helin Zhang 
[...]
> +i40e_phy_conf_link(__rte_unused struct i40e_hw *hw,
> +__rte_unused uint8_t abilities,
> +__rte_unused uint8_t force_speed)
> +{
> + /* Skip any phy config on both 10G and 40G interfaces, as a workaround
> +  * for the link control limitation of that all link control should be
> +  * handled by firmware. It should follow up if link control will be
> +  * opened to software driver in future firmware versions.
> +  */
>   return I40E_SUCCESS;
>  }

An error code seems more appropriate.
But I guess you perfectly know what you do, so
Applied, thanks

[dpdk-dev] [PATCH v3] i40e: fix BW info update if no dcb enabled

[Thomas Monjalon]

> > If DCB is not enabled, the BW info is not stored for VSI. This patch fixes 
> > this
> > issue by merging functions i40e_vsi_dump_bw_config and
> > i40e_vsi_get_bw_info together.
> > 
> > Fixes: c8b9a3e3fe1b (i40e: support DCB mode)
> > 
> > Signed-off-by: Jingjing Wu 
> Acked-by: Helin Zhang 
> 
> Thanks for the fix, it makes things clearer and simpler.

Applied, thanks

[dpdk-dev] [PATCH v2] i40e: configure the vector PMD option as no for default for l3fwd undefined ptype issue

[Thomas Monjalon]

2015-11-24 02:47, Zhe Tao:
> PATCH v1: configure the vector PMD option as no for FVL
> PATCH v2: Update the "know issues" for 2.2 release note
> 
> Issue: l3fwd app need the ptype in the mbuf to forwarding the packets 
> properly.
> but now some drivers like virtio driver and FVL vPMD will not set the ptype in
> mbuf, so l3fwd cannot work properly on that kind of drivers.
> 
> Configure the vector PMD option as no for default as a work around for l3fwd.
> After the l3fwd app can handle the undefined ptype or the i40e vPMD can return
> the ptype, the option will be set as yes for default again.
> 
> Signed-off-by: Zhe Tao 

Applied, thanks.

[dpdk-dev] [PATCH v2] i40e: fix issue of reconfigure hash enable flags

[Thomas Monjalon]

> > It fixes the issue of not re-configuring hash enable flags (HENA) if there 
> > is no
> > key.
> > 
> > Fixes: d0a349409bd7 ("i40e: support AQ based RSS config")
> > 
> > Signed-off-by: Helin Zhang 
> Acked-by: Jingjing Wu 

Applied, thanks

[dpdk-dev] [PATCH v2 0/3] Remove CRC from byte counters

[Thomas Monjalon]

> > Harry van Haaren (3):
> >   e1000: remove crc size from all byte counters
> >   ixgbe: remove crc size from all byte counters
> >   i40e: fix rx/tx size mismatch, remove crc bytes
> 
> Acked-by: Konstantin Ananyev 

Applied, thanks

[dpdk-dev] [PATCH] igb/e1000: Copy PCI device info after the rte_eal_process_type() check

[Thomas Monjalon]

> > This fixes a bug added to these two drivers by eeefe73 (drivers: copy PCI
> > device info to ethdev data) which causes the pci info seen by the primary
> > process to become invalidated by secondary process startup.
> > This call was added after the process type check in the other drivers.
> > 
> > Signed-off-by: Jon DeVree 
> 
> Acked-by: Bernard Iremonger 

Applied, thanks.

[dpdk-dev] Mellanox dpdk issues

[Sotiris Salloumis]

Hi all, 

For future reference problem root casue was missing package for the kernel 
version I was using.  

After doing 

zypper install kernel-default-devel-3.12.28-4.6.x86_64

Compilation worked fine.

Thanks Mellanox team for the support.

Regards
Sotiris

-Original Message-
From: Gilad Berman [mailto:gil...@mellanox.com] 
Sent: Monday, November 23, 2015 11:38 AM
To: Olga Shern; Sotiris Salloumis; dev at dpdk.org
Subject: RE: Mellanox dpdk issues

Sotiris, 

I've compiled MLNX_DPDK-2.1_1.1 on SLES12  3.12.28-4-default with OFED 
3.1-1.0.3 with no issues. Also, no modifications were required - simply follow 
the quick start guide here - 
http://www.mellanox.com/page/products_dyn?product_family=209&mtag=pmd_for_dpdk

If you are still having issues please mail me directly and we'll sort it out.

Thx.

Gilad Berman | Staff System Engineer | Business Development | Mellanox 
Technologies Ltd. 
Work: +972 52 2554262| 6 Ha'Barzel St. Tel Aviv 6971010, Israel


-Original Message-
From: Olga Shern 
Sent: Sunday, November 22, 2015 3:45 PM
To: Gilad Berman ; Sotiris Salloumis ; dev at dpdk.org
Subject: RE: Mellanox dpdk issues

Hi Sotiris, 

You can disable compilation of igb_uio, this module is not needed for Mellanox 
PMD.

Let me know if you have any question 

Best Regards,
Olga




-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gilad Berman
Sent: Sunday, November 22, 2015 1:30 PM
To: Sotiris Salloumis ; dev at dpdk.org
Subject: Re: [dpdk-dev] Mellanox dpdk issues

Let us check and get back to you. 


Gilad Berman | Staff System Engineer | Business Development | Mellanox 
Technologies Ltd. 
Work: +972 52 2554262| 6 Ha'Barzel St. Tel Aviv 6971010, Israel


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sotiris Salloumis
Sent: Friday, November 20, 2015 7:35 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Mellanox dpdk issues

Hi all,

I'm trying to build DPDK for Mellanox ( using MLNX_DPDK-2.1_1.1 ) but I get the 
following error following the guidelines i.e. make install 
T=x86_64-native-linuxapp-gcc

== Build lib/librte_eal/linuxapp/igb_uio
make[8]: *** /lib/modules/3.12.28-4-default/build: No such file or directory.  
Stop.
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.module.mk:79: recipe for target 
'igb_uio.ko' failed
make[7]: *** [igb_uio.ko] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'igb_uio' failed
make[6]: *** [igb_uio] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'linuxapp' failed
make[5]: *** [linuxapp] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'librte_eal' failed
make[4]: *** [librte_eal] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkbuild.mk:93: recipe for target 
'lib' failed
make[3]: *** [lib] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:124: recipe for target 
'all' failed
make[2]: *** [all] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkinstall.mk:58: recipe for target 
'x86_64-native-linuxapp-gcc_install' failed
make[1]: *** [x86_64-native-linuxapp-gcc_install] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:102: recipe for target 
'install' failed
make: *** [install] Error 2

The environment is SLES12


-  Linux linux-okj7 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 
2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux

-  3.12.28-4-default

>From Mellanox point of view the only difference I see is related with firmware 
>version

 Performing Adapter Device Self Test  Number of CAs Detected 
. 1 PCI Device Check ... PASS Kernel Arch 
 x86_64 Host Driver Version  
MLNX_OFED_LINUX-3.1-1.0.3 (OFED-3.1-1.0.3): 3.12.28-4-default Host Driver RPM 
Check .. PASS Firmware on CA #0 NIC .. 
v2.35.5130 Firmware Check on CA #0 (NIC) .. PASS
NOTE: The found fw version is higher than the fw included in this package 
(v2.35.5100) Host Driver Initialization . PASS Number of CA Ports 
Active .. 2 Port State of Port #1 on CA #0 (NIC). UP 1X QDR 
(Ethernet) Port State of Port #2 on CA #0 (NIC). UP 1X QDR (Ethernet) Error 
Counter Check on CA #0 (NIC).. NA (Eth ports) Kernel Syslog Check 
 PASS Node GUID on CA #0 (NIC) ... 
a0:1d:48:03:00:b5:a6:17
-- DONE -

Any hints?

Thanks
Sotiris

[dpdk-dev] [PATCH] ethdev: fix missing symbol export for rte_eth_dma_zone_reserve()

[Thomas Monjalon]

> > Fixes: 719dbebceb81 ("xen: allow determining DOM0 at runtime")
> > 
> > Signed-off-by: Panu Matilainen 
> 
> Acked-by: John McNamara 

Applied, thanks

[dpdk-dev] running dpdk 2.1 on openstak causes CPU soft lockup

[Nissim Nisimov]

Hi,

I am running DPDK 2.1.0 based app on OpenStack KVM guest.  OS of guest is 
Ubuntu LTS 14.04 3.13 kernel.
virtio.

After upgrade to dpdk 2.1 (previous version was dpdk 1.8 and it worked fine) we 
are seeing the following issue:

[960.004535] BUG: soft lockup - CPU#3 stuck for 23s! [ip:8419]

The message will be printed in an endless loop and the system won't recover.

Is it a known issue in dpdk 2.1? any patch I can apply in order to overcome 
this?


Thx
Nissim

[dpdk-dev] [PATCH] igb/e1000: Copy PCI device info after the rte_eal_process_type() check

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jon DeVree
> Sent: Monday, November 23, 2015 3:14 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] igb/e1000: Copy PCI device info after the
> rte_eal_process_type() check
> 
> This fixes a bug added to these two drivers by eeefe73 (drivers: copy PCI
> device info to ethdev data) which causes the pci info seen by the primary
> process to become invalidated by secondary process startup.
> This call was added after the process type check in the other drivers.
> 
> Signed-off-by: Jon DeVree 

Acked-by: Bernard Iremonger 

[dpdk-dev] [PATCH] eal: fix plugindir processing to be filesystem agnostic

[Thomas Monjalon]

2015-11-18 08:45, Panu Matilainen:
> Not all filesystems supply struct dirent d_type field, in which case
> everything in the specified directory would go ignored. One such
> filesystem being XFS which RHEL 7 defaults to... stat() the entries
> instead.
> 
> Fixes: 9f8eb1d9ca0f ("eal: support driver loading from directory")
> 
> Signed-off-by: Panu Matilainen 

Applied, thanks

[dpdk-dev] Can't compile DPDK if both CONFIG_RTE_BUILD_COMBINE_LIBS and LIBRTE_PMD_XENVIRT are set to "yes"

[Martinx - ジェームズ]

Hello!

My name is Thiago, I'm trying to compile DPDK 2.0, 2.1 and/or 2.2-rc1,
on Ubuntu with Xen support but, it does not build...

Also, initially, I'm using DPDK sources from Ubuntu APT repository
but, it is also reproducible using upstream DPDK tarball as well,
explained as follows:

Problem:

* It is not possible to use the following DPDK options at the same time:

CONFIG_RTE_BUILD_COMBINE_LIBS
LIBRTE_PMD_XENVIRT

Ubuntu DPDK .deb package uses CONFIG_RTE_BUILD_COMBINE_LIBS and,
without it, it can't build its .deb binary package (step: "make -f
debian/rules binary" doesn't work).

So, if you have the above two options set to "yes", the following
error appear while building DPDK:

http://pastebin.com/xUsQPxh8

--

* Steps to reproduce it on Ubuntu *

You'll need to download, build and package DPDK using 100% Ubuntu
tools... ;-)

1- Install Ubuntu 15.10 64-bit, Server or Desktop (If you're brave, go
for Ubuntu 16.04 Xenial dev branch);

NOTE 1: Make sure you have uncommented some 'source' URIs in your
/etc/apt/sources.list file. You can use the following Regex on vi:

sudo vi /etc/apt/sources.list

:%s/^# deb-src/deb-src/cg

NOTE 2: Install on your Ubuntu:

sudo apt-get install fakeroot libxen-dev


2- Download and build DPDK 2.0

# Install DPDK build dependencies:

sudo apt-get update
sudo apt-get build-dep dpdk

mkdir -p ~/dpdk/ubuntu ; cd ~/dpdk/ubuntu

# Download DPDK:

apt-get source dpdk

cd dpdk-2.0.0

# Build DPDK (without Xen, just defaults from Ubuntu package, it works):

make -f debian/rules build  # to build it
make -f debian/rules binary  # to package it into .deb files

# or

dpkg-buildpackage -rfakeroot -uc -us

It will build okay! Like a charm...

But, now, if you want to enable LIBRTE_PMD_XENVIRT, it fails. To
reproduce this problem, try this:

 vi debian/rules

And bellow the lines (yes, it is duplicated, we know, add twice too):

-e 's,(CONFIG_RTE_LIBNAME=).*,\1"dpdk",' \

Append the following line:

-e 's,(LIBRTE_PMD_XENVIRT=).*,\1y,' \

Then, it fails to build, look:

fakeroot make -f debian/rules build

# Line 486 of:

http://pastebin.com/jjn8Fja1

-

2.1- Download and build DPDK 2.2.0-rc1

 * Steps to reproduce it using most recent DPDK tarball *

So, lets say that you guys wants to test it using upstream DPDK tarball...

If you followed above instructions (step 2), you have everything you
need to build any DPDK version on Ubuntu (thanks to "apt-get build-dep
dpdk" step and sources 'URI' on your sources.list).

Steps:

mkdir -p ~/dpdk/2.2.0-rc1 ; cd ~/dpdk/2.2.0-rc1

wget http://dpdk.org/browse/dpdk/snapshot/dpdk-2.2.0-rc1.tar.gz

tar xf dpdk-2.2.0-rc1.tar.gz

cd dpdk-2.2.0-rc1

make T=x86_64-native-linuxapp-gcc config

sed -ri -e 's,(RTE_MACHINE=).*,\1"default",' \
-e 's,(RTE_APP_TEST=).*,\1n,' \
-e 's,(RTE_BUILD_SHARED_LIB=).*,\1y,' \
-e 's,(RTE_EAL_IGB_UIO=).*,\1n,' \
-e 's,(CONFIG_RTE_LIBRTE_KNI=).*,\1n,' \
-e 's,(CONFIG_RTE_BUILD_COMBINE_LIBS=).*,\1y,' \
-e 's,(CONFIG_RTE_LIBNAME=).*,\1"dpdk",' \
-e 's,(LIBRTE_VHOST=).*,\1y,' \
-e 's,(LIBRTE_PMD_XENVIRT=).*,\1y,' \
-e 's,(LIBRTE_XEN_DOM0=).*,\1y,' \
build/.config

Then, it also fails to build:

 make

Build error:

http://pastebin.com/fuUkpF4w

If you remove "CONFIG_RTE_BUILD_COMBINE_LIBS", then, you can build it
with "LIBRTE_PMD_XENVIRT", and vice-versa. But, without
"...COMBINE_LIBS", Ubuntu .deb package doesn't get builded.

BTW, the option LIBRTE_XEN_DOM0 is fine when also enabling COMBINE_LIBS...

Am I missing something? Is this by design or a DPDK bug?

Thanks in advance!

Best,
Thiago

[dpdk-dev] [PATCH] eal: fix regression of plugins always requiring full path

[Thomas Monjalon]

2015-11-23 14:05, Panu Matilainen:
> The added error checking on plugin initialization in
> commit 9f8eb1d9ca0f56d6292db5858c52e6873d0abe51 broke the ability of
> loading plugins by their basename from default linker locations.
> Only use stat() for directory discovery and leave error handling
> to dlopen() to restore former behavior.
> 
> Fixes: 9f8eb1d9ca0f ("eal: support driver loading from directory")
> Signed-off-by: Panu Matilainen 

Applied, thanks

[dpdk-dev] [PATCH 2/2] eal: move empty declarations to doc

[Thomas Monjalon]

2015-11-13 10:35, David Marchand:
> No need for those forward declarations (which breaks build when asking for
> C++11 or adding pedantic flag).
> 
> Signed-off-by: David Marchand 

Applied, thanks

[dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf

[Declan Doherty]

On 23/11/15 14:46, Thomas Monjalon wrote:
> 2015-11-23 15:17, Thomas Monjalon:
>> Yes, it is a totally new work and it probably needs more time to have a
>> design working well for most of use cases.
>> As I already discussed with Olivier, I think it should be considered as
>> experimental. It means we can try it but do not consider it as a stable
>> API. So the deprecation process would not apply until the experimental
>> flag is removed.
>
> If nobody complains, I'll apply this v7 and will send a patch to add some
> experimental markers.
>
>> For the release 2.2, it would be better to remove the crypto dependency
>> in mbuf. Do you think it is possible?
>
> Sorry, forget it, the dependency is in mbuf_offload.
>

That sounds good to me, thanks Thomas!

[dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf

[Thomas Monjalon]

2015-11-23 15:17, Thomas Monjalon:
> Yes, it is a totally new work and it probably needs more time to have a
> design working well for most of use cases.
> As I already discussed with Olivier, I think it should be considered as
> experimental. It means we can try it but do not consider it as a stable
> API. So the deprecation process would not apply until the experimental
> flag is removed.

If nobody complains, I'll apply this v7 and will send a patch to add some
experimental markers.

> For the release 2.2, it would be better to remove the crypto dependency
> in mbuf. Do you think it is possible?

Sorry, forget it, the dependency is in mbuf_offload.

[dpdk-dev] [PATCH 14/14] mlx5: add environment variables section to documentation

[Adrien Mazarguil]

From: Olga Shern 

Describe how applications can benefit from CQE compression.

Signed-off-by: Olga Shern 
Signed-off-by: Adrien Mazarguil 
---
 doc/guides/nics/mlx5.rst | 13 +
 1 file changed, 13 insertions(+)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 2d68914..eb8c042 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -130,6 +130,19 @@ These options can be modified in the ``.config`` file.

   This value is always 1 for RX queues since they use a single MP.

+Environment variables
+~
+
+- ``MLX5_ENABLE_CQE_COMPRESSION``
+
+  A nonzero value lets ConnectX-4 return smaller completion entries to
+  improve performance when PCI backpressure is detected. It is most useful
+  for scenarios involving heavy traffic on many queues.
+
+  Since the additional software logic necessary to handle this mode can
+  lower performance when there is no backpressure, it is not enabled by
+  default.
+
 Run-time configuration
 ~~

-- 
2.1.0

[dpdk-dev] [PATCH 13/14] mlx5: fix available entries in TX rings

[Adrien Mazarguil]

From: Nelio Laranjeiro 

The number of available entries in TX rings is taken before performing
completion, effectively making rings smaller than they are and causing
TX performance issues under load.

Fixes: 2e22920b85d9 ("mlx5: support non-scattered Tx and Rx")

Signed-off-by: Nelio Laranjeiro 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx5/mlx5_rxtx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index eb6c9f7..fa5e648 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -436,7 +436,6 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
 {
struct txq *txq = (struct txq *)dpdk_txq;
unsigned int elts_head = txq->elts_head;
-   const unsigned int elts_tail = txq->elts_tail;
const unsigned int elts_n = txq->elts_n;
unsigned int elts_comp_cd = txq->elts_comp_cd;
unsigned int elts_comp = 0;
@@ -446,7 +445,7 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, 
uint16_t pkts_n)

assert(elts_comp_cd != 0);
txq_complete(txq);
-   max = (elts_n - (elts_head - elts_tail));
+   max = (elts_n - (elts_head - txq->elts_tail));
if (max > elts_n)
max -= elts_n;
assert(max >= 1);
-- 
2.1.0

[dpdk-dev] [PATCH 12/14] mlx5: fix local protection error when TX MP to MR cache is full

[Adrien Mazarguil]

From: Olga Shern 

When MP to MR cache is full, the last (newest) MR is freed instead of the
first (oldest) one, causing local protection errors during TX.

Fixes: 2e22920b85d9 ("mlx5: support non-scattered Tx and Rx")

Signed-off-by: Olga Shern 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx5/mlx5_rxtx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index c6c167c..eb6c9f7 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -179,7 +179,7 @@ txq_mp2mr(struct txq *txq, const struct rte_mempool *mp)
DEBUG("%p: MR <-> MP table full, dropping oldest entry.",
  (void *)txq);
--i;
-   claim_zero(ibv_dereg_mr(txq->mp2mr[i].mr));
+   claim_zero(ibv_dereg_mr(txq->mp2mr[0].mr));
memmove(&txq->mp2mr[0], &txq->mp2mr[1],
(sizeof(txq->mp2mr) - sizeof(txq->mp2mr[0])));
}
-- 
2.1.0

[dpdk-dev] [PATCH 11/14] mlx5: fix TX packet loss after initialization

[Adrien Mazarguil]

From: Olga Shern 

Pre-registering mbuf memory pools when creating TX queues avoids costly
registrations later in the data path.

Fixes: 2e22920b85d9 ("mlx5: support non-scattered Tx and Rx")

Signed-off-by: Olga Shern 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx5/mlx5_rxtx.c | 85 +---
 drivers/net/mlx5/mlx5_rxtx.h |  3 +-
 drivers/net/mlx5/mlx5_txq.c  |  2 ++
 3 files changed, 85 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 80d0c97..c6c167c 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -146,7 +146,7 @@ txq_mb2mp(struct rte_mbuf *buf)
  *   mr->lkey on success, (uint32_t)-1 on failure.
  */
 static uint32_t
-txq_mp2mr(struct txq *txq, struct rte_mempool *mp)
+txq_mp2mr(struct txq *txq, const struct rte_mempool *mp)
 {
unsigned int i;
struct ibv_mr *mr;
@@ -163,7 +163,8 @@ txq_mp2mr(struct txq *txq, struct rte_mempool *mp)
}
}
/* Add a new entry, register MR first. */
-   DEBUG("%p: discovered new memory pool %p", (void *)txq, (void *)mp);
+   DEBUG("%p: discovered new memory pool \"%s\" (%p)",
+ (void *)txq, mp->name, (const void *)mp);
mr = ibv_reg_mr(txq->priv->pd,
(void *)mp->elt_va_start,
(mp->elt_va_end - mp->elt_va_start),
@@ -186,11 +187,87 @@ txq_mp2mr(struct txq *txq, struct rte_mempool *mp)
txq->mp2mr[i].mp = mp;
txq->mp2mr[i].mr = mr;
txq->mp2mr[i].lkey = mr->lkey;
-   DEBUG("%p: new MR lkey for MP %p: 0x%08" PRIu32,
- (void *)txq, (void *)mp, txq->mp2mr[i].lkey);
+   DEBUG("%p: new MR lkey for MP \"%s\" (%p): 0x%08" PRIu32,
+ (void *)txq, mp->name, (const void *)mp, txq->mp2mr[i].lkey);
return txq->mp2mr[i].lkey;
 }

+struct txq_mp2mr_mbuf_check_data {
+   const struct rte_mempool *mp;
+   int ret;
+};
+
+/**
+ * Callback function for rte_mempool_obj_iter() to check whether a given
+ * mempool object looks like a mbuf.
+ *
+ * @param[in, out] arg
+ *   Context data (struct txq_mp2mr_mbuf_check_data). Contains mempool pointer
+ *   and return value.
+ * @param[in] start
+ *   Object start address.
+ * @param[in] end
+ *   Object end address.
+ * @param index
+ *   Unused.
+ *
+ * @return
+ *   Nonzero value when object is not a mbuf.
+ */
+static void
+txq_mp2mr_mbuf_check(void *arg, void *start, void *end,
+uint32_t index __rte_unused)
+{
+   struct txq_mp2mr_mbuf_check_data *data = arg;
+   struct rte_mbuf *buf =
+   (void *)((uintptr_t)start + data->mp->header_size);
+
+   (void)index;
+   /* Check whether mbuf structure fits element size and whether mempool
+* pointer is valid. */
+   if (((uintptr_t)end >= (uintptr_t)(buf + 1)) &&
+   (buf->pool == data->mp))
+   data->ret = 0;
+   else
+   data->ret = -1;
+}
+
+/**
+ * Iterator function for rte_mempool_walk() to register existing mempools and
+ * fill the MP to MR cache of a TX queue.
+ *
+ * @param[in] mp
+ *   Memory Pool to register.
+ * @param *arg
+ *   Pointer to TX queue structure.
+ */
+void
+txq_mp2mr_iter(const struct rte_mempool *mp, void *arg)
+{
+   struct txq *txq = arg;
+   struct txq_mp2mr_mbuf_check_data data = {
+   .mp = mp,
+   .ret = -1,
+   };
+
+   /* Discard empty mempools. */
+   if (mp->size == 0)
+   return;
+   /* Register mempool only if the first element looks like a mbuf. */
+   rte_mempool_obj_iter((void *)mp->elt_va_start,
+1,
+mp->header_size + mp->elt_size + mp->trailer_size,
+1,
+mp->elt_pa,
+mp->pg_num,
+mp->pg_shift,
+txq_mp2mr_mbuf_check,
+&data);
+   if (data.ret)
+   return;
+   txq_mp2mr(txq, mp);
+}
+
 #if MLX5_PMD_SGE_WR_N > 1

 /**
diff --git a/drivers/net/mlx5/mlx5_rxtx.h b/drivers/net/mlx5/mlx5_rxtx.h
index 15c4bc8..e1e1925 100644
--- a/drivers/net/mlx5/mlx5_rxtx.h
+++ b/drivers/net/mlx5/mlx5_rxtx.h
@@ -209,7 +209,7 @@ typedef uint8_t linear_t[16384];
 struct txq {
struct priv *priv; /* Back pointer to private data. */
struct {
-   struct rte_mempool *mp; /* Cached Memory Pool. */
+   const struct rte_mempool *mp; /* Cached Memory Pool. */
struct ibv_mr *mr; /* Memory Region (for mp). */
uint32_t lkey; /* mr->lkey */
} mp2mr[MLX5_PMD_TX_MP_CACHE]; /* MP to MR translation table. */
@@ -264,6 +264,7 @@ void mlx5_tx_queue_release(void *);

 /* mlx5_rxtx.c */

+void txq_mp2mr_iter(const struct rte_mempool *, void *);
 uint16_t mlx5_tx_burst(void *, struct rte_mbuf **, uint16_t);
 uint

[dpdk-dev] [PATCH 10/14] mlx5: fix TX for scattered mbufs with too many segments

[Adrien Mazarguil]

Buffers with too many segments are linearized to overcome
MLX5_PMD_SGE_WR_N, unfortunately the last segment is never sent.

Fixes: 3ee8444608a9 ("mlx5: support scattered Rx and Tx")

Signed-off-by: Jesper Wramberg 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx5/mlx5_rxtx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 4c6ed32..80d0c97 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -325,6 +325,8 @@ tx_burst_sg(struct txq *txq, unsigned int segs, struct 
txq_elt *elt,
sge->length = size;
sge->lkey = txq->mr_linear->lkey;
sent_size += size;
+   /* Include last segment. */
+   segs++;
}
return (struct tx_burst_sg_ret){
.length = sent_size,
-- 
2.1.0

[dpdk-dev] [PATCH 09/14] mlx5: fix memory registration for indirect mbuf data

[Adrien Mazarguil]

Indirect mbuf data may come from a different mempool which must be
registered separately as another memory region, otherwise such mbufs cannot
be sent.

Fixes: 2e22920b85d9 ("mlx5: support non-scattered Tx and Rx")

Signed-off-by: Jesper Wramberg 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx5/mlx5_rxtx.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index db2ac03..4c6ed32 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -115,6 +115,24 @@ txq_complete(struct txq *txq)
 }

 /**
+ * Get Memory Pool (MP) from mbuf. If mbuf is indirect, the pool from which
+ * the cloned mbuf is allocated is returned instead.
+ *
+ * @param buf
+ *   Pointer to mbuf.
+ *
+ * @return
+ *   Memory pool where data is located for given mbuf.
+ */
+static struct rte_mempool *
+txq_mb2mp(struct rte_mbuf *buf)
+{
+   if (unlikely(RTE_MBUF_INDIRECT(buf)))
+   return rte_mbuf_from_indirect(buf)->pool;
+   return buf->pool;
+}
+
+/**
  * Get Memory Region (MR) <-> Memory Pool (MP) association from txq->mp2mr[].
  * Add MP to txq->mp2mr[] if it's not registered yet. If mp2mr[] is full,
  * remove an entry first.
@@ -254,7 +272,7 @@ tx_burst_sg(struct txq *txq, unsigned int segs, struct 
txq_elt *elt,
uint32_t lkey;

/* Retrieve Memory Region key for this memory pool. */
-   lkey = txq_mp2mr(txq, buf->pool);
+   lkey = txq_mp2mr(txq, txq_mb2mp(buf));
if (unlikely(lkey == (uint32_t)-1)) {
/* MR does not exist. */
DEBUG("%p: unable to get MP <-> MR association",
@@ -410,7 +428,7 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
addr = rte_pktmbuf_mtod(buf, uintptr_t);
length = DATA_LEN(buf);
/* Retrieve Memory Region key for this memory pool. */
-   lkey = txq_mp2mr(txq, buf->pool);
+   lkey = txq_mp2mr(txq, txq_mb2mp(buf));
if (unlikely(lkey == (uint32_t)-1)) {
/* MR does not exist. */
DEBUG("%p: unable to get MP <-> MR"
-- 
2.1.0

[dpdk-dev] [PATCH 08/14] mlx5: fix possible crash when clearing device statistics

[Adrien Mazarguil]

A typo causes TX stats indices to be retrieved from RX queues.

Fixes: 87011737b715 ("mlx5: add software counters")

Reported-by: Nicolas Harnois 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx5/mlx5_stats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_stats.c b/drivers/net/mlx5/mlx5_stats.c
index a51e945..6d1a600 100644
--- a/drivers/net/mlx5/mlx5_stats.c
+++ b/drivers/net/mlx5/mlx5_stats.c
@@ -133,7 +133,7 @@ mlx5_stats_reset(struct rte_eth_dev *dev)
for (i = 0; (i != priv->txqs_n); ++i) {
if ((*priv->txqs)[i] == NULL)
continue;
-   idx = (*priv->rxqs)[i]->stats.idx;
+   idx = (*priv->txqs)[i]->stats.idx;
(*priv->txqs)[i]->stats =
(struct mlx5_txq_stats){ .idx = idx };
}
-- 
2.1.0

[dpdk-dev] [PATCH 07/14] mlx4: allow operation in secondary processes

[Adrien Mazarguil]

From: Or Ami 

Secondary processes are expected to use queues and other resources
allocated by the primary, however Verbs resources can only be shared
between processes when inherited through fork().

This limitation can be worked around for TX by configuring separate queues
from secondary processes.

Signed-off-by: Or Ami 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c | 383 ++--
 1 file changed, 371 insertions(+), 12 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 4f57e2d..207bfe2 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -299,6 +299,46 @@ struct priv {
rte_spinlock_t lock; /* Lock for control functions. */
 };

+/* Local storage for secondary process data. */
+struct mlx4_secondary_data {
+   struct rte_eth_dev_data data; /* Local device data. */
+   struct priv *primary_priv; /* Private structure from primary. */
+   struct rte_eth_dev_data *shared_dev_data; /* Shared device data. */
+   rte_spinlock_t lock; /* Port configuration lock. */
+} mlx4_secondary_data[RTE_MAX_ETHPORTS];
+
+/**
+ * Check if running as a secondary process.
+ *
+ * @return
+ *   Nonzero if running as a secondary process.
+ */
+static inline int
+mlx4_is_secondary(void)
+{
+   return rte_eal_process_type() != RTE_PROC_PRIMARY;
+}
+
+/**
+ * Return private structure associated with an Ethernet device.
+ *
+ * @param dev
+ *   Pointer to Ethernet device structure.
+ *
+ * @return
+ *   Pointer to private structure.
+ */
+static struct priv *
+mlx4_get_priv(struct rte_eth_dev *dev)
+{
+   struct mlx4_secondary_data *sd;
+
+   if (!mlx4_is_secondary())
+   return dev->data->dev_private;
+   sd = &mlx4_secondary_data[dev->data->port_id];
+   return sd->data.dev_private;
+}
+
 /**
  * Lock private structure to protect it from concurrent access in the
  * control path.
@@ -659,6 +699,13 @@ priv_set_flags(struct priv *priv, unsigned int keep, 
unsigned int flags)
 /* Device configuration. */

 static int
+txq_setup(struct rte_eth_dev *dev, struct txq *txq, uint16_t desc,
+ unsigned int socket, const struct rte_eth_txconf *conf);
+
+static void
+txq_cleanup(struct txq *txq);
+
+static int
 rxq_setup(struct rte_eth_dev *dev, struct rxq *rxq, uint16_t desc,
  unsigned int socket, const struct rte_eth_rxconf *conf,
  struct rte_mempool *mp);
@@ -756,6 +803,8 @@ mlx4_dev_configure(struct rte_eth_dev *dev)
struct priv *priv = dev->data->dev_private;
int ret;

+   if (mlx4_is_secondary())
+   return -E_RTE_SECONDARY;
priv_lock(priv);
ret = dev_configure(dev);
assert(ret >= 0);
@@ -763,6 +812,160 @@ mlx4_dev_configure(struct rte_eth_dev *dev)
return -ret;
 }

+static uint16_t mlx4_tx_burst(void *, struct rte_mbuf **, uint16_t);
+static uint16_t removed_rx_burst(void *, struct rte_mbuf **, uint16_t);
+
+/**
+ * Configure secondary process queues from a private data pointer (primary
+ * or secondary) and update burst callbacks. Can take place only once.
+ *
+ * All queues must have been previously created by the primary process to
+ * avoid undefined behavior.
+ *
+ * @param priv
+ *   Private data pointer from either primary or secondary process.
+ *
+ * @return
+ *   Private data pointer from secondary process, NULL in case of error.
+ */
+static struct priv *
+mlx4_secondary_data_setup(struct priv *priv)
+{
+   unsigned int port_id = 0;
+   struct mlx4_secondary_data *sd;
+   void **tx_queues;
+   void **rx_queues;
+   unsigned int nb_tx_queues;
+   unsigned int nb_rx_queues;
+   unsigned int i;
+
+   /* priv must be valid at this point. */
+   assert(priv != NULL);
+   /* priv->dev must also be valid but may point to local memory from
+* another process, possibly with the same address and must not
+* be dereferenced yet. */
+   assert(priv->dev != NULL);
+   /* Determine port ID by finding out where priv comes from. */
+   while (1) {
+   sd = &mlx4_secondary_data[port_id];
+   rte_spinlock_lock(&sd->lock);
+   /* Primary process? */
+   if (sd->primary_priv == priv)
+   break;
+   /* Secondary process? */
+   if (sd->data.dev_private == priv)
+   break;
+   rte_spinlock_unlock(&sd->lock);
+   if (++port_id == RTE_DIM(mlx4_secondary_data))
+   port_id = 0;
+   }
+   /* Switch to secondary private structure. If private data has already
+* been updated by another thread, there is nothing else to do. */
+   priv = sd->data.dev_private;
+   if (priv->dev->data == &sd->data)
+   goto end;
+   /* Sanity checks. Secondary private structure is supposed to point
+* to local eth_dev, itself still pointing to the shared device

[dpdk-dev] [PATCH 06/14] mlx4: fix available entries in TX rings

[Adrien Mazarguil]

From: Nelio Laranjeiro 

The number of available entries in TX rings is taken before performing
completion, effectively making rings smaller than they are and causing
TX performance issues under load.

Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")

Signed-off-by: Nelio Laranjeiro 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 3e05373..4f57e2d 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -1306,7 +1306,6 @@ mlx4_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
 {
struct txq *txq = (struct txq *)dpdk_txq;
unsigned int elts_head = txq->elts_head;
-   const unsigned int elts_tail = txq->elts_tail;
const unsigned int elts_n = txq->elts_n;
unsigned int elts_comp_cd = txq->elts_comp_cd;
unsigned int elts_comp = 0;
@@ -1316,7 +1315,7 @@ mlx4_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, 
uint16_t pkts_n)

assert(elts_comp_cd != 0);
txq_complete(txq);
-   max = (elts_n - (elts_head - elts_tail));
+   max = (elts_n - (elts_head - txq->elts_tail));
if (max > elts_n)
max -= elts_n;
assert(max >= 1);
-- 
2.1.0

[dpdk-dev] [PATCH 05/14] mlx4: fix local protection error when TX MP to MR cache is full

[Adrien Mazarguil]

From: Olga Shern 

When MP to MR cache is full, the last (newest) MR is freed instead of the
first (oldest) one, causing local protection errors during TX.

Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")

Signed-off-by: Olga Shern 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 4bd0ecd..3e05373 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -1049,7 +1049,7 @@ txq_mp2mr(struct txq *txq, const struct rte_mempool *mp)
DEBUG("%p: MR <-> MP table full, dropping oldest entry.",
  (void *)txq);
--i;
-   claim_zero(ibv_dereg_mr(txq->mp2mr[i].mr));
+   claim_zero(ibv_dereg_mr(txq->mp2mr[0].mr));
memmove(&txq->mp2mr[0], &txq->mp2mr[1],
(sizeof(txq->mp2mr) - sizeof(txq->mp2mr[0])));
}
-- 
2.1.0

[dpdk-dev] [PATCH 04/14] mlx4: fix TX packet loss after initialization

[Adrien Mazarguil]

From: Olga Shern 

Pre-registering mbuf memory pools when creating TX queues avoids costly
registrations later in the data path.

Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")

Signed-off-by: Olga Shern 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c | 89 ++---
 1 file changed, 84 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 75543bb..4bd0ecd 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -229,7 +229,7 @@ typedef uint8_t linear_t[16384];
 struct txq {
struct priv *priv; /* Back pointer to private data. */
struct {
-   struct rte_mempool *mp; /* Cached Memory Pool. */
+   const struct rte_mempool *mp; /* Cached Memory Pool. */
struct ibv_mr *mr; /* Memory Region (for mp). */
uint32_t lkey; /* mr->lkey */
} mp2mr[MLX4_PMD_TX_MP_CACHE]; /* MP to MR translation table. */
@@ -1016,7 +1016,7 @@ txq_mb2mp(struct rte_mbuf *buf)
  *   mr->lkey on success, (uint32_t)-1 on failure.
  */
 static uint32_t
-txq_mp2mr(struct txq *txq, struct rte_mempool *mp)
+txq_mp2mr(struct txq *txq, const struct rte_mempool *mp)
 {
unsigned int i;
struct ibv_mr *mr;
@@ -1033,7 +1033,8 @@ txq_mp2mr(struct txq *txq, struct rte_mempool *mp)
}
}
/* Add a new entry, register MR first. */
-   DEBUG("%p: discovered new memory pool %p", (void *)txq, (void *)mp);
+   DEBUG("%p: discovered new memory pool \"%s\" (%p)",
+ (void *)txq, mp->name, (const void *)mp);
mr = ibv_reg_mr(txq->priv->pd,
(void *)mp->elt_va_start,
(mp->elt_va_end - mp->elt_va_start),
@@ -1056,11 +1057,87 @@ txq_mp2mr(struct txq *txq, struct rte_mempool *mp)
txq->mp2mr[i].mp = mp;
txq->mp2mr[i].mr = mr;
txq->mp2mr[i].lkey = mr->lkey;
-   DEBUG("%p: new MR lkey for MP %p: 0x%08" PRIu32,
- (void *)txq, (void *)mp, txq->mp2mr[i].lkey);
+   DEBUG("%p: new MR lkey for MP \"%s\" (%p): 0x%08" PRIu32,
+ (void *)txq, mp->name, (const void *)mp, txq->mp2mr[i].lkey);
return txq->mp2mr[i].lkey;
 }

+struct txq_mp2mr_mbuf_check_data {
+   const struct rte_mempool *mp;
+   int ret;
+};
+
+/**
+ * Callback function for rte_mempool_obj_iter() to check whether a given
+ * mempool object looks like a mbuf.
+ *
+ * @param[in, out] arg
+ *   Context data (struct txq_mp2mr_mbuf_check_data). Contains mempool pointer
+ *   and return value.
+ * @param[in] start
+ *   Object start address.
+ * @param[in] end
+ *   Object end address.
+ * @param index
+ *   Unused.
+ *
+ * @return
+ *   Nonzero value when object is not a mbuf.
+ */
+static void
+txq_mp2mr_mbuf_check(void *arg, void *start, void *end,
+uint32_t index __rte_unused)
+{
+   struct txq_mp2mr_mbuf_check_data *data = arg;
+   struct rte_mbuf *buf =
+   (void *)((uintptr_t)start + data->mp->header_size);
+
+   (void)index;
+   /* Check whether mbuf structure fits element size and whether mempool
+* pointer is valid. */
+   if (((uintptr_t)end >= (uintptr_t)(buf + 1)) &&
+   (buf->pool == data->mp))
+   data->ret = 0;
+   else
+   data->ret = -1;
+}
+
+/**
+ * Iterator function for rte_mempool_walk() to register existing mempools and
+ * fill the MP to MR cache of a TX queue.
+ *
+ * @param[in] mp
+ *   Memory Pool to register.
+ * @param *arg
+ *   Pointer to TX queue structure.
+ */
+static void
+txq_mp2mr_iter(const struct rte_mempool *mp, void *arg)
+{
+   struct txq *txq = arg;
+   struct txq_mp2mr_mbuf_check_data data = {
+   .mp = mp,
+   .ret = -1,
+   };
+
+   /* Discard empty mempools. */
+   if (mp->size == 0)
+   return;
+   /* Register mempool only if the first element looks like a mbuf. */
+   rte_mempool_obj_iter((void *)mp->elt_va_start,
+1,
+mp->header_size + mp->elt_size + mp->trailer_size,
+1,
+mp->elt_pa,
+mp->pg_num,
+mp->pg_shift,
+txq_mp2mr_mbuf_check,
+&data);
+   if (data.ret)
+   return;
+   txq_mp2mr(txq, mp);
+}
+
 #if MLX4_PMD_SGE_WR_N > 1

 /**
@@ -1571,6 +1648,8 @@ txq_setup(struct rte_eth_dev *dev, struct txq *txq, 
uint16_t desc,
txq_cleanup(txq);
*txq = tmpl;
DEBUG("%p: txq updated with %p", (void *)txq, (void *)&tmpl);
+   /* Pre-register known mempools. */
+   rte_mempool_walk(txq_mp2mr_iter, txq);
assert(ret == 0);
return 0;
 error:
-- 
2.1.0

[dpdk-dev] [PATCH 03/14] mlx4: fix TX for scattered mbufs with too many segments

[Adrien Mazarguil]

Buffers with too many segments are linearized to overcome
MLX4_PMD_SGE_WR_N, unfortunately the last segment is never sent.

Fixes: be11b35817e0 ("mlx4: move scattered Tx processing to helper function")

Signed-off-by: Jesper Wramberg 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index f46a09e..75543bb 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -1195,6 +1195,8 @@ tx_burst_sg(struct txq *txq, unsigned int segs, struct 
txq_elt *elt,
sge->length = size;
sge->lkey = txq->mr_linear->lkey;
sent_size += size;
+   /* Include last segment. */
+   segs++;
}
return (struct tx_burst_sg_ret){
.length = sent_size,
-- 
2.1.0

[dpdk-dev] [PATCH 02/14] mlx4: fix memory registration for indirect mbuf data

[Adrien Mazarguil]

Indirect mbuf data may come from a different mempool which must be
registered separately as another memory region, otherwise such mbufs cannot
be sent.

Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")

Signed-off-by: Jesper Wramberg 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index d961a8a..f46a09e 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -985,6 +985,24 @@ txq_complete(struct txq *txq)
 }

 /**
+ * Get Memory Pool (MP) from mbuf. If mbuf is indirect, the pool from which
+ * the cloned mbuf is allocated is returned instead.
+ *
+ * @param buf
+ *   Pointer to mbuf.
+ *
+ * @return
+ *   Memory pool where data is located for given mbuf.
+ */
+static struct rte_mempool *
+txq_mb2mp(struct rte_mbuf *buf)
+{
+   if (unlikely(RTE_MBUF_INDIRECT(buf)))
+   return rte_mbuf_from_indirect(buf)->pool;
+   return buf->pool;
+}
+
+/**
  * Get Memory Region (MR) <-> Memory Pool (MP) association from txq->mp2mr[].
  * Add MP to txq->mp2mr[] if it's not registered yet. If mp2mr[] is full,
  * remove an entry first.
@@ -1124,7 +1142,7 @@ tx_burst_sg(struct txq *txq, unsigned int segs, struct 
txq_elt *elt,
uint32_t lkey;

/* Retrieve Memory Region key for this memory pool. */
-   lkey = txq_mp2mr(txq, buf->pool);
+   lkey = txq_mp2mr(txq, txq_mb2mp(buf));
if (unlikely(lkey == (uint32_t)-1)) {
/* MR does not exist. */
DEBUG("%p: unable to get MP <-> MR association",
@@ -1280,7 +1298,7 @@ mlx4_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
addr = rte_pktmbuf_mtod(buf, uintptr_t);
length = DATA_LEN(buf);
/* Retrieve Memory Region key for this memory pool. */
-   lkey = txq_mp2mr(txq, buf->pool);
+   lkey = txq_mp2mr(txq, txq_mb2mp(buf));
if (unlikely(lkey == (uint32_t)-1)) {
/* MR does not exist. */
DEBUG("%p: unable to get MP <-> MR"
-- 
2.1.0

[dpdk-dev] [PATCH 01/14] mlx4: fix possible crash when clearing device statistics

[Adrien Mazarguil]

A typo causes TX stats indices to be retrieved from RX queues.

Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")

Reported-by: Nicolas Harnois 
Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 4198c04..d961a8a 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -3958,7 +3958,7 @@ mlx4_stats_reset(struct rte_eth_dev *dev)
for (i = 0; (i != priv->txqs_n); ++i) {
if ((*priv->txqs)[i] == NULL)
continue;
-   idx = (*priv->rxqs)[i]->stats.idx;
+   idx = (*priv->txqs)[i]->stats.idx;
(*priv->txqs)[i]->stats =
(struct mlx4_txq_stats){ .idx = idx };
}
-- 
2.1.0

[dpdk-dev] [PATCH 00/14] Fixes for mlx4 and mlx5

[Adrien Mazarguil]

Here is a set of fixes for mlx4 and mlx5. Since mlx5 derives from mlx4,
most patches apply to both PMDs.

Besides bugfixes, there is a documentation commit for mlx5 (undocumented
environment variables) and another commit that addresses secondary process
operation with mlx4 (does not work at all).

Adrien Mazarguil (6):
  mlx4: fix possible crash when clearing device statistics
  mlx4: fix memory registration for indirect mbuf data
  mlx4: fix TX for scattered mbufs with too many segments
  mlx5: fix possible crash when clearing device statistics
  mlx5: fix memory registration for indirect mbuf data
  mlx5: fix TX for scattered mbufs with too many segments

Nelio Laranjeiro (2):
  mlx4: fix available entries in TX rings
  mlx5: fix available entries in TX rings

Olga Shern (5):
  mlx4: fix TX packet loss after initialization
  mlx4: fix local protection error when TX MP to MR cache is full
  mlx5: fix TX packet loss after initialization
  mlx5: fix local protection error when TX MP to MR cache is full
  mlx5: add environment variables section to documentation

Or Ami (1):
  mlx4: allow operation in secondary processes

 doc/guides/nics/mlx5.rst  |  13 ++
 drivers/net/mlx4/mlx4.c   | 503 --
 drivers/net/mlx5/mlx5_rxtx.c  | 114 +-
 drivers/net/mlx5/mlx5_rxtx.h  |   3 +-
 drivers/net/mlx5/mlx5_stats.c |   2 +-
 drivers/net/mlx5/mlx5_txq.c   |   2 +
 6 files changed, 603 insertions(+), 34 deletions(-)

-- 
2.1.0

[dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check for nb_tx_desc during txq setup

[Yuanhan Liu]

On Mon, Nov 23, 2015 at 07:36:38AM +, Liu, Yong wrote:
> Yuanhan,
> The validation system is based on dpkdk.org patchwork, all patch sets 
> recorded by patchwork should be validated.
> Can you supply the patch Id or just patch name? Thus, we can check out what 
> happened. 

Sure, here you go:

 589   T Nov 18 sys_stv at intel.c (  19) |SUCCESS| pw 8988 vhost: avoid buffer 
overflow in update_secure_len   
  
 733 r T Nov 17 sys_stv at intel.c (  19) |SUCCESS| pw 8965 vhost: avoid buffer 
overflow in update_secure_len   
  
 863   T Nov 17 sys_stv at intel.c (  19) |SUCCESS| pw 8960 vhost: avoid buffer 
overflow in update_secure_len   
  
1230 r T Nov 11 sys_stv at intel.c (  87) |ERROR| pw 8870  vhost: reset device 
properly
   

--yliu

> 
> > -Original Message-
> > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> > Sent: Monday, November 23, 2015 3:27 PM
> > To: Liu, Yong
> > Cc: dev at dpdk.org; Felix Marti; Kumar Sanghvi; Nirranjan Kirubaharan
> > Subject: Re: [dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check
> > for nb_tx_desc during txq setup
> > 
> > On Mon, Nov 23, 2015 at 07:06:45AM +, Liu, Yong wrote:
> > > Hi Rahul,
> > > Your patch passed "checksum_offload_with_vlan" after rerun this case.
> > Please ignore this error report.
> > 
> > I got a same report few weeks ago. And my patch was very vhost-user
> > specific, touching nothing else. Even though, I sent a report for
> > double check, and got no reply.
> > 
> > I also got several "report" while replying to the same patch (not from
> > me). I sent another report, yet no reply received.
> > 
> > 
> > --yliu
> > 
> > >
> > > > -Original Message-
> > > > From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com]
> > > > Sent: Friday, November 20, 2015 9:37 PM
> > > > To: dev at dpdk.org
> > > > Cc: Liu, Yong; Kumar Sanghvi; Nirranjan Kirubaharan; Felix Marti
> > > > Subject: Re: |ERROR| pw 9018 ethdev: add a missing sanity check for
> > > > nb_tx_desc during txq setup
> > > >
> > > > Hi all,
> > > >
> > > > I received this auto email regarding 'Unexpected Packets Drop' and
> > > > it is referring to my patch.  I don't think I've changed anything that
> > > > could cause this.  Kindly advise.
> > > >
> > > > Thanks,
> > > > Rahul
> > > >
> > > > On Friday, November 11/20/15, 2015 at 03:14:51 -0800,
> > sys_stv at intel.com
> > > > wrote:
> > > > > Test-Label: Intel Niantic on Fedora
> > > > > Test-Status: ERROR
> > > > > Patchwork: http://www.dpdk.org/dev/patchwork/patch/9018/
> > > > >
> > > > > DPDK git baseline: e64833f2273ac67becbca10d9f2f1598872dc99e
> > > > > Patchwork ID: 9018
> > > > > http://www.dpdk.org/dev/patchwork/patch/9018/
> > > > > Submitter: Rahul Lakkireddy 
> > > > > Date: Fri, 20 Nov 2015 15:56:37 +0530
> > > > >
> > > > > Source Compilation:
> > > > > OS: fedora
> > > > > Nic: niantic
> > > > > i686-native-linuxapp-gcc: compile pass
> > > > > x86_64-native-linuxapp-gcc: compile pass
> > > > >
> > > > > DTS validation:
> > > > > OS: fedora
> > > > > Nic: Niantic
> > > > > TestType: auto
> > > > > GCC: 4
> > > > > x86_64-native-linuxapp-gcc:  total 79, passed 78, failed 1.
> > > > > Failed Case List:
> > > > > Target: x86_64-native-linuxapp-gcc
> > > > > OS: fedora
> > > > > Failed DTS case:
> > > > > checksum_offload_with_vlan:
> > > >
> > http://dpdk.org/browse/tools/dts/tree/test_plans/checksum_offload_test_pla
> > > > n.rst
> > > > >
> > > > > DTS Validation Error:
> > > > >
> > > >
> > ==
> > > > ==
> > > > >
> > > >
> > ==
> > > > ==
> > > > > TEST SUITE : TestChecksumOffload
> > > > >
> > > > > 
> > 
> > > > ---
> > > > > Begin: Test Casetest_checksum_offload_with_vlan
> > > > > --
> > > > > FAILED  'Unexpected Packets Drop'
> > > > > --
> > > > > [   SUITE_DUT_CMD]  ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x6
> > -n 4
> > > > -- -i --portmask=0x3 --disable-hw-vlan --enable-rx-cksum --crc-strip -
> > -
> > > > txqflags=0
> > > > > [   SUITE_DUT_CMD]  set verbose 1
> > > > > [   SUITE_DUT_CMD]  set fwd csum
> > > > > [   SUITE_DUT_CMD]  csum set ip hw 0
> > > > > [   SUITE_DUT_CMD]  csum set udp hw 0
> > > > > [   SUITE_DUT_CMD]  csum set t

[dpdk-dev] max MEMZONEs allowed

[Nissim Nisimov]

Hi all,

We are working on a system which requires allocating a big number of mem zones.

We are now reaching the max limit of MEMZONEs allowed (RTE_MAX_MEMZONE). 

I see today dpdk limit the above number to 2560. 
Is there any specific reason for that? can I increase it in case needed. What 
may be the side effects of such changes?


Thx
Nissim

[dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check for nb_tx_desc during txq setup

[Yuanhan Liu]

On Mon, Nov 23, 2015 at 07:06:45AM +, Liu, Yong wrote:
> Hi Rahul,
> Your patch passed "checksum_offload_with_vlan" after rerun this case. Please 
> ignore this error report.

I got a same report few weeks ago. And my patch was very vhost-user
specific, touching nothing else. Even though, I sent a report for
double check, and got no reply.

I also got several "report" while replying to the same patch (not from
me). I sent another report, yet no reply received.


--yliu

> 
> > -Original Message-
> > From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com]
> > Sent: Friday, November 20, 2015 9:37 PM
> > To: dev at dpdk.org
> > Cc: Liu, Yong; Kumar Sanghvi; Nirranjan Kirubaharan; Felix Marti
> > Subject: Re: |ERROR| pw 9018 ethdev: add a missing sanity check for
> > nb_tx_desc during txq setup
> > 
> > Hi all,
> > 
> > I received this auto email regarding 'Unexpected Packets Drop' and
> > it is referring to my patch.  I don't think I've changed anything that
> > could cause this.  Kindly advise.
> > 
> > Thanks,
> > Rahul
> > 
> > On Friday, November 11/20/15, 2015 at 03:14:51 -0800, sys_stv at intel.com
> > wrote:
> > > Test-Label: Intel Niantic on Fedora
> > > Test-Status: ERROR
> > > Patchwork: http://www.dpdk.org/dev/patchwork/patch/9018/
> > >
> > > DPDK git baseline: e64833f2273ac67becbca10d9f2f1598872dc99e
> > > Patchwork ID: 9018
> > > http://www.dpdk.org/dev/patchwork/patch/9018/
> > > Submitter: Rahul Lakkireddy 
> > > Date: Fri, 20 Nov 2015 15:56:37 +0530
> > >
> > > Source Compilation:
> > > OS: fedora
> > > Nic: niantic
> > > i686-native-linuxapp-gcc: compile pass
> > > x86_64-native-linuxapp-gcc: compile pass
> > >
> > > DTS validation:
> > > OS: fedora
> > > Nic: Niantic
> > > TestType: auto
> > > GCC: 4
> > > x86_64-native-linuxapp-gcc:  total 79, passed 78, failed 1.
> > > Failed Case List:
> > > Target: x86_64-native-linuxapp-gcc
> > > OS: fedora
> > > Failed DTS case:
> > > checksum_offload_with_vlan:
> > http://dpdk.org/browse/tools/dts/tree/test_plans/checksum_offload_test_pla
> > n.rst
> > >
> > > DTS Validation Error:
> > >
> > ==
> > ==
> > >
> > ==
> > ==
> > > TEST SUITE : TestChecksumOffload
> > >
> > > 
> > ---
> > > Begin: Test Casetest_checksum_offload_with_vlan
> > > --
> > > FAILED  'Unexpected Packets Drop'
> > > --
> > > [   SUITE_DUT_CMD]  ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x6 -n 4
> > -- -i --portmask=0x3 --disable-hw-vlan --enable-rx-cksum --crc-strip --
> > txqflags=0
> > > [   SUITE_DUT_CMD]  set verbose 1
> > > [   SUITE_DUT_CMD]  set fwd csum
> > > [   SUITE_DUT_CMD]  csum set ip hw 0
> > > [   SUITE_DUT_CMD]  csum set udp hw 0
> > > [   SUITE_DUT_CMD]  csum set tcp hw 0
> > > [   SUITE_DUT_CMD]  csum set sctp hw 0
> > > [   SUITE_DUT_CMD]  csum set ip hw 1
> > > [   SUITE_DUT_CMD]  csum set udp hw 1
> > > [   SUITE_DUT_CMD]  csum set tcp hw 1
> > > [   SUITE_DUT_CMD]  csum set sctp hw 1
> > > [   SUITE_DUT_CMD]  start
> > > [SUITE_TESTER_CMD]  scapy
> > > [SUITE_TESTER_CMD]  sys.path.append("./")
> > > [SUITE_TESTER_CMD]  from sctp import *
> > > [SUITE_TESTER_CMD]  p =
> > Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::2")/UDP()/("X"*46)
> > > [SUITE_TESTER_CMD]  p.show2()
> > > [SUITE_TESTER_CMD]  p =
> > Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/SCTP()/("X"*48)
> > > [SUITE_TESTER_CMD]  p.show2()
> > > [SUITE_TESTER_CMD]  p =
> > Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::2")/TCP()/("X"*46)
> > > [SUITE_TESTER_CMD]  p.show2()
> > > [SUITE_TESTER_CMD]  p =
> > Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/UDP()/("X"*46)
> > > [SUITE_TESTER_CMD]  p.show2()
> > > [SUITE_TESTER_CMD]  p =
> > Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/TCP()/("X"*46)
> > > [SUITE_TESTER_CMD]  p.show2()
> > > [SUITE_TESTER_CMD]  exit()
> > > [SUITE_TESTER_CMD]  echo -n '' >  scapyResult.txt
> > > [SUITE_TESTER_CMD]  scp sniff.py root at 10.239.128.80:~/
> > > [SUITE_TESTER_CMD]  SCAPY Receive setup:
> > > [SUITE_TESTER_CMD]  scapy
> > > [SUITE_TESTER_CMD]  subprocess.call("scapy -c sniff.py &", shell=True)
> > > [SUITE_TESTER_CMD]  sys.path.append("./")
> > > [SUITE_TESTER_CMD]  import sctp
> > > [SUITE_TESTER_CMD]  from sctp import *
> > > [SUITE_TESTER_CMD]
> > sendp([Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::1")/UDP(chksum=0xf)/("X"
> > *46)], iface="p785p2")
> > > [SUITE_TESTER_CMD]
> > sendp([Ether(dst="90:e2:ba:4a:54:81")/IP(chksum=0x0)/SCTP(chksum=0xf)/("X"
> > *48)], iface="p785p2")
> > > [SUITE_TESTER_CMD]
> > sendp([Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::1")/TCP(chksum=0xf)/("X"
> > *46)], iface="p785p2")
> > > [SUITE_TEST

[dpdk-dev] [PATCH 1/1] app/test: create ring and ethdevs in pmd_ring_autotest

[Bernard Iremonger]

Use command line option --vdev=eth_ring0 to create port 0.
Create two rings and five ethdevs in test_pmd_ring for ports 1 to 5.
Improve test output by adding the port number to printf statements,
and adding a printf describing each test.

revise ring-based PMD doc to match latest ring PMD code.

Signed-off-by: Bernard Iremonger 
---
 app/test/test_pmd_ring.c  | 360 +-
 doc/guides/nics/pcap_ring.rst |  28 ++--
 2 files changed, 235 insertions(+), 153 deletions(-)

diff --git a/app/test/test_pmd_ring.c b/app/test/test_pmd_ring.c
index a555db8..5568759 100644
--- a/app/test/test_pmd_ring.c
+++ b/app/test/test_pmd_ring.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -38,108 +38,104 @@
 #include 

 static struct rte_mempool *mp;
+static int tx_porta, rx_portb, rxtx_portc, rxtx_portd, rxtx_porte;

-#define TX_PORT 0
-#define RX_PORT 1
-#define RXTX_PORT 2
-#define RXTX_PORT2 3
-#define RXTX_PORT3 4
 #define SOCKET0 0
-
 #define RING_SIZE 256
+#define NUM_RINGS 2
+#define NB_MBUF 512

-#define NB_MBUF   512

 static int
-test_ethdev_configure(void)
+test_ethdev_configure_port(int port)
 {
struct rte_eth_conf null_conf;
struct rte_eth_link link;

memset(&null_conf, 0, sizeof(struct rte_eth_conf));

-   if ((TX_PORT >= RTE_MAX_ETHPORTS) || (RX_PORT >= RTE_MAX_ETHPORTS)\
-   || (RXTX_PORT >= RTE_MAX_ETHPORTS)) {
-   printf(" TX/RX port exceed max eth ports\n");
-   return -1;
-   }
-   if (rte_eth_dev_configure(TX_PORT, 1, 2, &null_conf) < 0) {
-   printf("Configure failed for TX port\n");
+   if (rte_eth_dev_configure(port, 1, 2, &null_conf) < 0) {
+   printf("Configure failed for port %d\n", port);
return -1;
}

/* Test queue release */
-   if (rte_eth_dev_configure(TX_PORT, 1, 1, &null_conf) < 0) {
-   printf("Configure failed for TX port\n");
-   return -1;
-   }
-   if (rte_eth_dev_configure(RX_PORT, 1, 1, &null_conf) < 0) {
-   printf("Configure failed for RX port\n");
-   return -1;
-   }
-   if (rte_eth_dev_configure(RXTX_PORT, 1, 1, &null_conf) < 0) {
-   printf("Configure failed for RXTX port\n");
+   if (rte_eth_dev_configure(port, 1, 1, &null_conf) < 0) {
+   printf("Configure failed for port %d\n", port);
return -1;
}

-   if (rte_eth_tx_queue_setup(TX_PORT, 0, RING_SIZE, SOCKET0, NULL) < 0) {
-   printf("TX queue setup failed\n");
-   return -1;
-   }
-   if (rte_eth_rx_queue_setup(RX_PORT, 0, RING_SIZE, SOCKET0,
-   NULL, mp) < 0) {
-   printf("RX queue setup failed\n");
-   return -1;
-   }
-   if (rte_eth_tx_queue_setup(RXTX_PORT, 0, RING_SIZE, SOCKET0, NULL) < 0) 
{
-   printf("TX queue setup failed\n");
+   if (rte_eth_tx_queue_setup(port, 0, RING_SIZE, SOCKET0, NULL) < 0) {
+   printf("TX queue setup failed port %d\n", port);
return -1;
}
-   if (rte_eth_rx_queue_setup(RXTX_PORT, 0, RING_SIZE, SOCKET0,
+
+   if (rte_eth_rx_queue_setup(port, 0, RING_SIZE, SOCKET0,
NULL, mp) < 0) {
-   printf("RX queue setup failed\n");
+   printf("RX queue setup failed port %d\n", port);
return -1;
}

-   if (rte_eth_dev_start(TX_PORT) < 0) {
-   printf("Error starting TX port\n");
+   if (rte_eth_dev_start(port) < 0) {
+   printf("Error starting port %d\n", port);
return -1;
}
-   if (rte_eth_dev_start(RX_PORT) < 0) {
-   printf("Error starting RX port\n");
+
+   rte_eth_link_get(port, &link);
+
+   return 0;
+}
+
+static int
+test_send_basic_packets(void)
+{
+   struct rte_mbuf  bufs[RING_SIZE];
+   struct rte_mbuf *pbufs[RING_SIZE];
+   int i;
+
+   printf("Testing send and receive RING_SIZE/2 packets (tx_porta -> 
rx_portb)\n");
+
+   for (i = 0; i < RING_SIZE/2; i++)
+   pbufs[i] = &bufs[i];
+
+   if (rte_eth_tx_burst(tx_porta, 0, pbufs, RING_SIZE/2) < RING_SIZE/2) {
+   printf("Failed to transmit packet burst port %d\n", tx_porta);
return -1;
}
-   if (rte_eth_dev_start(RXTX_PORT) < 0) {
-   printf("Error starting RX port\n");
+
+   if (rte_eth_rx_burst(rx_portb, 0, pbufs, RING_SIZE) != RING_SIZE/2) {
+   printf("Failed to receive packet burst on port %d\n", rx_portb);
return -1;
}

-   rte_eth_link_get(TX_PORT, &link);
-   rte_eth_link_get(RX_PORT, &li

[dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf

[Thomas Monjalon]

2015-11-23 14:08, Olivier MATZ:
> 2015-11-23 12:16, Declan Doherty:
> > 2015-11-23 11:52, Ananyev, Konstantin:
> >> I understand that current API is probably not perfect and might need
> >> to be revised in future.
> 
> The problem is that it's not easy to change the dpdk API now.
[...]
> > Just to re-iterate Konstantin's point above. I'm aware that a number of
> > mbuf operations currently are not supported and are not aware of the
> > rte_mbuf_offload, but we will be continuing development throughout 2.3
> > and beyond to address this. Also I hope we will get much more community
> > feedback and interaction so we can get a more definite feature set for
> > the library, and  by minimizing the features in this release, it will
> > allow more flexibility on how we can develop this part of handling
> > offloaded operations and it will limit the ABI issues we will face if it
> > turns out we need to change this going forwards.
> 
> I can see the amount of work you've done for making the cryptodev
> happen in dpdk. I also recognize that I didn't make comments very early.
> 
> If we really want to have this feature in the next release, maybe there
> is a way to mark it as experimental, meaning that the API is subject to
> change? What do you think?
> 
> Thomas, any comment?

Yes, it is a totally new work and it probably needs more time to have a
design working well for most of use cases.
As I already discussed with Olivier, I think it should be considered as
experimental. It means we can try it but do not consider it as a stable
API. So the deprecation process would not apply until the experimental
flag is removed.

For the release 2.2, it would be better to remove the crypto dependency
in mbuf. Do you think it is possible?

[dpdk-dev] [PATCH] eal: fix plugindir processing to be filesystem agnostic

[Thomas Monjalon]

2015-11-23 13:42, Panu Matilainen:
> On 11/23/2015 12:41 PM, Thomas Monjalon wrote:
> > 2015-11-23 08:04, Panu Matilainen:
> >> On 11/20/2015 06:38 PM, David Marchand wrote:
> >>> It looks like you would skip the symbolic links while you were not before.
> >>> Intended ?
> >>
> >> Intended. We want to accept symlinks in the driver directory, but the
> >> actual drivers are always regular files.
> >
> > No we use symbolic links:
> > http://dpdk.org/browse/dpdk/commit/mk/rte.lib.mk?id=133b75923
> > http://dpdk.org/browse/dpdk/tree/mk/rte.lib.mk#n170
> 
> Those symlinks eventually point to the actual drivers which are always 
> regular files (and not for example directories), that is the point. 
> Please apply.

Yes

> > On the same topic, you've added a check in 9f8eb1d9:
> > +   if (stat(solib->name, &sb) == -1) {
> > +   RTE_LOG(ERR, EAL, "Invalid plugin specified: %s: %s\n",
> > +   solib->name, strerror(errno));
> >
> > It is a regression because we cannot anymore load a plugin from
> > LD_LIBRARY_PATH without specifying its full path.
> > It can be tested with scripts/test-null.sh.
> > How do you suggest to fix it?
> 
> My first and foremost thought is regret over messing with -d at all, 
> instead of keeping with the original plan of a new -D option for 
> directories. Supporting directories with -d opened up all these annoying 
> little issues that did not exist in the original plan, and lost the 
> ability to disable/override the default plugindir.

I keep thinking having an unique option is a good thing.
If disabling the default directory is needed, we can imagine a special
syntax like -d-
Thanks for your work.

> I suppose the fix is to only use a successful stat to determine if 
> something is a directory and feed everything else to dlopen() which will 
> then fail on its own if file is not existent.

Yes sounds good.

> I'll send a separate patch for the regression.

Thanks

[dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf

[Declan Doherty]

On 23/11/15 13:08, Olivier MATZ wrote:
> Hi,
>
> On 11/23/2015 01:16 PM, Declan Doherty wrote:
>>> I don't think we should start to re-use userdata.
>>> Userdata was intended for the upper layer app to pass/store it's
>>> private data associated with mbuf, and we probably should keep it this
>>> way.
>
> If the crypto API PMD takes both mbuf and crypto instead of just the
> mbuf, the mbuf_offload and the userdata wouldn't be very different,
> as the metadata would stay inside the application.
>
> So, if it's application private (the dpdk does not know how to handle
> it in case of mbuf free, dup, ...), the content of it should be
> app-specific.
>
>>> While mbuf_offload (or whatever we'll name it) supposed to keep data
>>> necessary for crypto (and other future type of devices) to operate
>>> with mbuf.
>
> Any idea of future devices?

Well the QAT hardware supports compression, so I guess that might be a 
likely candidate for future work.

>
>>> All your comments above about that this new field is just ignored by
>>> most mbuf
>>> operations (copy/attach/append/free, etc) are valid.
>>> By I suppose for now we can just state that for mbuf_offload is not
>>> supported by
>>> all these mbuf ops.
>
> So, who is responsible of freeing the mbuf offload metadata?
> The crypto pmd ?
>
> It means that as soon as the mbuf offload is added to the mbuf, it is
> not possible to call any other dpdk function that would process the
> mbuf... if we cannot call anything else before, why not just passing
> the crypto argument as a parameter?
>
> Managing offload data would even be more complex in the future if there
> are more than one mbuf_offload attached to the mbuf.
>
>>> I understand that current API is probably not perfect and might need
>>> to be revised in future.
>
> The problem is that it's not easy to change the dpdk API now.
>
>>> Again, as it is completely new feature, I suspect it would be a lot of
>>> change requests for it anyway.
>>> But we need some generic way to pass other (not ethdev) specific
>>> information within mbuf
>>> between user-level and PMDs for non-ethernet devices (and probably
>>> between different PMDs too).
>
> If a crypto PMD needs a crypto info, why not adding a crypto argument?
> I feel it's clearer from a user point of view.
>
> About PMD to PMD metadata, do you have any use case?

One use case that comes to mind would be the enablement of inline IPsec. 
To enable this you would need a mechanism to attach the IPsec metadata, 
ESP header offsets etc to an mbuf which the PMD can then use to 
correctly complete the tx descriptor.


>
>
>> Just to re-iterate Konstantin's point above. I'm aware that a number of
>> mbuf operations currently are not supported and are not aware of the
>> rte_mbuf_offload, but we will be continuing development throughout 2.3
>> and beyond to address this. Also I hope we will get much more community
>> feedback and interaction so we can get a more definite feature set for
>> the library, and  by minimizing the features in this release, it will
>> allow more flexibility on how we can develop this part of handling
>> offloaded operations and it will limit the ABI issues we will face if it
>> turns out we need to change this going forwards.
>
> I can see the amount of work you've done for making the cryptodev
> happen in dpdk. I also recognize that I didn't make comments very early.
>
> If we really want to have this feature in the next release, maybe there
> is a way to mark it as experimental, meaning that the API is subject to
> change? What do you think?

I wouldn't be against this idea. I think a mechanism for marking new 
libraries / APIs as experimental for their initial release could be very 
useful to allow new features to be introduced with the flexibility to 
make further API changes on user feedback without the overhead of ABI 
management in the subsequent release.

>
> Thomas, any comment?
>
> Regards,
> Olivier
>

[dpdk-dev] [PATCH v2] i40e: fix issue of reconfigure hash enable flags

[Helin Zhang]

It fixes the issue of not re-configuring hash enable flags (HENA)
if there is no key.

Fixes: d0a349409bd7 ("i40e: support AQ based RSS config")

Signed-off-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

v2 changes:
Removed useless checks.

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2c51a0b..4bc258a 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5663,9 +5663,14 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, 
uint8_t key_len)
struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
int ret = 0;

-   if (!key || key_len != ((I40E_PFQF_HKEY_MAX_INDEX + 1) *
-   sizeof(uint32_t)))
+   if (!key || key_len == 0) {
+   PMD_DRV_LOG(DEBUG, "No key to be configured");
+   return 0;
+   } else if (key_len != (I40E_PFQF_HKEY_MAX_INDEX + 1) *
+   sizeof(uint32_t)) {
+   PMD_DRV_LOG(ERR, "Invalid key length %u", key_len);
return -EINVAL;
+   }

if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
struct i40e_aqc_get_set_rss_key_data *key_dw =
-- 
1.9.3

[dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf

[Olivier MATZ]

Hi,

On 11/23/2015 01:16 PM, Declan Doherty wrote:
>> I don't think we should start to re-use userdata.
>> Userdata was intended for the upper layer app to pass/store it's
>> private data associated with mbuf, and we probably should keep it this
>> way.

If the crypto API PMD takes both mbuf and crypto instead of just the
mbuf, the mbuf_offload and the userdata wouldn't be very different,
as the metadata would stay inside the application.

So, if it's application private (the dpdk does not know how to handle
it in case of mbuf free, dup, ...), the content of it should be
app-specific.

>> While mbuf_offload (or whatever we'll name it) supposed to keep data
>> necessary for crypto (and other future type of devices) to operate
>> with mbuf.

Any idea of future devices?

>> All your comments above about that this new field is just ignored by
>> most mbuf
>> operations (copy/attach/append/free, etc) are valid.
>> By I suppose for now we can just state that for mbuf_offload is not
>> supported by
>> all these mbuf ops.

So, who is responsible of freeing the mbuf offload metadata?
The crypto pmd ?

It means that as soon as the mbuf offload is added to the mbuf, it is
not possible to call any other dpdk function that would process the
mbuf... if we cannot call anything else before, why not just passing
the crypto argument as a parameter?

Managing offload data would even be more complex in the future if there
are more than one mbuf_offload attached to the mbuf.

>> I understand that current API is probably not perfect and might need
>> to be revised in future.

The problem is that it's not easy to change the dpdk API now.

>> Again, as it is completely new feature, I suspect it would be a lot of
>> change requests for it anyway.
>> But we need some generic way to pass other (not ethdev) specific
>> information within mbuf
>> between user-level and PMDs for non-ethernet devices (and probably
>> between different PMDs too).

If a crypto PMD needs a crypto info, why not adding a crypto argument?
I feel it's clearer from a user point of view.

About PMD to PMD metadata, do you have any use case?


> Just to re-iterate Konstantin's point above. I'm aware that a number of
> mbuf operations currently are not supported and are not aware of the
> rte_mbuf_offload, but we will be continuing development throughout 2.3
> and beyond to address this. Also I hope we will get much more community
> feedback and interaction so we can get a more definite feature set for
> the library, and  by minimizing the features in this release, it will
> allow more flexibility on how we can develop this part of handling
> offloaded operations and it will limit the ABI issues we will face if it
> turns out we need to change this going forwards.

I can see the amount of work you've done for making the cryptodev
happen in dpdk. I also recognize that I didn't make comments very early.

If we really want to have this feature in the next release, maybe there
is a way to mark it as experimental, meaning that the API is subject to
change? What do you think?

Thomas, any comment?

Regards,
Olivier

[dpdk-dev] [PATCH] eal: fix regression of plugins always requiring full path

[Panu Matilainen]

The added error checking on plugin initialization in
commit 9f8eb1d9ca0f56d6292db5858c52e6873d0abe51 broke the ability of
loading plugins by their basename from default linker locations.
Only use stat() for directory discovery and leave error handling
to dlopen() to restore former behavior.

Fixes: 9f8eb1d9ca0f ("eal: support driver loading from directory")
Signed-off-by: Panu Matilainen 
---
 lib/librte_eal/common/eal_common_options.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index e51fa12..29942ea 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -218,22 +218,15 @@ eal_plugins_init(void)

TAILQ_FOREACH(solib, &solib_list, next) {
struct stat sb;
-   if (stat(solib->name, &sb) == -1) {
-   RTE_LOG(ERR, EAL, "Invalid plugin specified: %s: %s\n",
-   solib->name, strerror(errno));
-   return -1;
-   }

-   switch (sb.st_mode & S_IFMT) {
-   case S_IFDIR:
+   if (stat(solib->name, &sb) == 0 && S_ISDIR(sb.st_mode)) {
if (eal_plugindir_init(solib->name) == -1) {
RTE_LOG(ERR, EAL,
"Cannot init plugin directory %s\n",
solib->name);
return -1;
}
-   break;
-   case S_IFREG:
+   } else {
RTE_LOG(DEBUG, EAL, "open shared lib %s\n",
solib->name);
solib->lib_handle = dlopen(solib->name, RTLD_NOW);
@@ -241,7 +234,6 @@ eal_plugins_init(void)
RTE_LOG(ERR, EAL, "%s\n", dlerror());
return -1;
}
-   break;
}

}
-- 
2.5.0

[dpdk-dev] [PATCH] eal: fix plugindir processing to be filesystem agnostic

[Panu Matilainen]

On 11/23/2015 12:41 PM, Thomas Monjalon wrote:
> Hi Panu,
>
> 2015-11-23 08:04, Panu Matilainen:
>> On 11/20/2015 06:38 PM, David Marchand wrote:
>>> It looks like you would skip the symbolic links while you were not before.
>>> Intended ?
>>
>> Intended. We want to accept symlinks in the driver directory, but the
>> actual drivers are always regular files.
>
> No we use symbolic links:
> http://dpdk.org/browse/dpdk/commit/mk/rte.lib.mk?id=133b75923
> http://dpdk.org/browse/dpdk/tree/mk/rte.lib.mk#n170

Those symlinks eventually point to the actual drivers which are always 
regular files (and not for example directories), that is the point. 
Please apply.

>
> On the same topic, you've added a check in 9f8eb1d9:
> + if (stat(solib->name, &sb) == -1) {
> + RTE_LOG(ERR, EAL, "Invalid plugin specified: %s: %s\n",
> + solib->name, strerror(errno));
>
> It is a regression because we cannot anymore load a plugin from
> LD_LIBRARY_PATH without specifying its full path.
> It can be tested with scripts/test-null.sh.
> How do you suggest to fix it?

My first and foremost thought is regret over messing with -d at all, 
instead of keeping with the original plan of a new -D option for 
directories. Supporting directories with -d opened up all these annoying 
little issues that did not exist in the original plan, and lost the 
ability to disable/override the default plugindir.

I suppose the fix is to only use a successful stat to determine if 
something is a directory and feed everything else to dlopen() which will 
then fail on its own if file is not existent.

I'll send a separate patch for the regression.

- Panu -

> Thanks
>

[dpdk-dev] [PATCH] i40e: fix issue of reconfigure hash enable flags

[Helin Zhang]

It fixes the issue of not re-configuring hash enable flags (HENA)
if there is no key.

Fixes: d0a349409bd7 ("i40e: support AQ based RSS config")

Signed-off-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2c51a0b..e9e07e2 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5663,9 +5663,14 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, 
uint8_t key_len)
struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
int ret = 0;

-   if (!key || key_len != ((I40E_PFQF_HKEY_MAX_INDEX + 1) *
-   sizeof(uint32_t)))
+   if (!key || key_len == 0) {
+   PMD_DRV_LOG(DEBUG, "No key to be configured");
+   return 0;
+   } else if (key && (key_len != (I40E_PFQF_HKEY_MAX_INDEX + 1) *
+   sizeof(uint32_t))) {
+   PMD_DRV_LOG(ERR, "Invalid key length %u", key_len);
return -EINVAL;
+   }

if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
struct i40e_aqc_get_set_rss_key_data *key_dw =
-- 
1.9.3

[dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf

[Declan Doherty]

On 23/11/15 11:52, Ananyev, Konstantin wrote:
> Hi Olivier,
>
>> On 11/20/2015 06:26 PM, Declan Doherty wrote:
 The new files are called rte_mbuf_offload, but from what I understand,
 it is more like a mbuf metadata api. What you call "offload operation"
 is not called because an offload is attached, but because you call
 rte_cryptodev_enqueue_burst() on it.
>>>
>>> Maybe rte_mbuf_offload_metadata would be a better name, if not a bit
>>> more long winded :) The idea of this API set is to give a generic
>>> framework for attaching the the offload operation meta data to a mbuf
>>> which will be retrieved at a later point, when the particular offload
>>> burst function is called. I guess as we only have a single offload
>>> device at the moment the API may look a little over the top!
>>
>> Indeed, not sure rte_mbuf_offload_metadata is better.
>> I'm still not convinced that offload should appear in the name, it
>> is a bit confusing with hardware offloads (ol_flags). Also, it
>> suggests that a work is delegated to another entity, but for instance
>> in this case it is just used as a storage area:
>>
>>  ol = rte_pktmbuf_offload_alloc(pool, RTE_PKTMBUF_OL_CRYPTO);
>>  rte_crypto_op_attach_session(&ol->op.crypto, session);
>>  ol->op.crypto.digest.data = rte_pktmbuf_append(m, digest_len);
>>  ol->op.crypto.digest.phys_addr = ...;
>>  /* ... */
>>  rte_pktmbuf_offload_attach(m, ol);
>>  ret = rte_cryptodev_enqueue_burst(dev_id, qp_id, &m, 1);
>>
>> Do you have some other examples in mind that would use this API?
>>
> +/** Rearms rte_mbuf_offload default parameters */
> +static inline void
> +__rte_pktmbuf_offload_reset(struct rte_mbuf_offload *ol,
> +enum rte_mbuf_ol_op_type type)
> +{
> +ol->m = NULL;
> +ol->type = type;
> +
> +switch (type) {
> +case RTE_PKTMBUF_OL_CRYPTO:
> +__rte_crypto_op_reset(&ol->op.crypto); break;
> +default:
> +break;
> +}
> +}

 Would it work if several OL are registered?
>>>
>>> I can't see any reason why it wouldn't
>>
>> Sorry, I read it to quickly. I thought it was a
>> rte_pktmbuf_offload_detach() function. By the way there is no
>> such function?
>>
>>
 Also, what is not clear to me is how the offload structure is freed.
 For instance, I think that calling rte_pktmbuf_free(m) on a mbuf
 that has a offload attached would result in a leak.

 It would mean that it is not allowed to call any function that free or
 reassemble a mbuf when an offload is attached.
>>>
>>> We just need to walk the chain of offloads calling
>>> rte_pktmbuf_offload_free(), before freeing the mbuf, which will be an
>>> issue with any externally attached meta data. In the case of
>>> reassembling I don't see why we would just move the chain to the head mbuf.
>>
>> Walking the chain of offload + adding the initialization will probably
>> have a little cost that should be evaluated.
>>
>> The freeing is probably not the only problem:
>> - packet duplication: are the offload infos copied? If no, it means that
>>the copy is not exactly a copy
>> - if you chain 2 mbufs that both have offload info attached, how does it
>>behave?
>> - if you prepend a segment to your mbuf, you need to copy the mbuf
>>offload pointer, and also parse the list of offload to update the
>>ol->m pointer of each element.
>>
 It seems that these offload structures are only used to pass crypto
 info to the cryptodev. Would it be a problem to have an API like this?

 rx_burst(port, q, mbuf_tab, crypto_tab, n);

>>>
>>> I really dislike this option, there's no direct linkage between mbuf and
>>> offload operation.
>>>
 Or even:

 rx_burst(port, q, crypto_tab, n);

 with each *cryto_tab pointing to a mbuf

>>>
>>> I looked at this but it would really hamstring any pipelining
>>> applications which might want to attach multiple offloads to a mbuf at a
>>> point in the pipeline for processing at later steps.
>>
>> As far as I can see, there is already a way to chain several crypto
>> operations in the crypto structure.
>>
>> Another option is to use the mbuf offload API (or the m->userdata
>> pointer which already works for that) only in the application:
>>
>> - the field is completely ignored by the mbuf api and the dpdk driver
>> - it is up to the application to initialize it and free it
>>
>> -> it can only be used when passing mbuf from a part of the app
>> to another, so it perfectly matches the pipeline use case.
>
> I don't think we should start to re-use userdata.
> Userdata was intended for the upper layer app to pass/store it's
> private data associated with mbuf, and we probably should keep it this way.
> While mbuf_offload (or whatever we'll name it) supposed to keep data
> necessary for crypto (and other future type of devices) to operate with mbuf.
>
> All your comments above

[dpdk-dev] [PATCH] i40e: configure the vector PMD option as no for default for l3fwd undefined ptype issue

[Thomas Monjalon]

> > Configure the vector PMD option as no for default as a work around for 
> > l3fwd.
> > After the l3fwd app can handle the undefined ptype or the i40e vPMD can
> > return the ptype, the option will be set as yes for default again.
> > 
> > Signed-off-by: Zhe Tao 
> Acked-by: Helin Zhang 

Few comments:
1/ The issue is not described.
2/ The release notes should be updated in the section "known issues".
3/ Changing the default config option won't prevent users from enable it.
If it is broken, it is better to fix or revert it.

[dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf

[Ananyev, Konstantin]

Hi Olivier,

> On 11/20/2015 06:26 PM, Declan Doherty wrote:
> >> The new files are called rte_mbuf_offload, but from what I understand,
> >> it is more like a mbuf metadata api. What you call "offload operation"
> >> is not called because an offload is attached, but because you call
> >> rte_cryptodev_enqueue_burst() on it.
> >
> > Maybe rte_mbuf_offload_metadata would be a better name, if not a bit
> > more long winded :) The idea of this API set is to give a generic
> > framework for attaching the the offload operation meta data to a mbuf
> > which will be retrieved at a later point, when the particular offload
> > burst function is called. I guess as we only have a single offload
> > device at the moment the API may look a little over the top!
> 
> Indeed, not sure rte_mbuf_offload_metadata is better.
> I'm still not convinced that offload should appear in the name, it
> is a bit confusing with hardware offloads (ol_flags). Also, it
> suggests that a work is delegated to another entity, but for instance
> in this case it is just used as a storage area:
> 
>   ol = rte_pktmbuf_offload_alloc(pool, RTE_PKTMBUF_OL_CRYPTO);
>   rte_crypto_op_attach_session(&ol->op.crypto, session);
>   ol->op.crypto.digest.data = rte_pktmbuf_append(m, digest_len);
>   ol->op.crypto.digest.phys_addr = ...;
>   /* ... */
>   rte_pktmbuf_offload_attach(m, ol);
>   ret = rte_cryptodev_enqueue_burst(dev_id, qp_id, &m, 1);
> 
> Do you have some other examples in mind that would use this API?
> 
> >>> +/** Rearms rte_mbuf_offload default parameters */
> >>> +static inline void
> >>> +__rte_pktmbuf_offload_reset(struct rte_mbuf_offload *ol,
> >>> +enum rte_mbuf_ol_op_type type)
> >>> +{
> >>> +ol->m = NULL;
> >>> +ol->type = type;
> >>> +
> >>> +switch (type) {
> >>> +case RTE_PKTMBUF_OL_CRYPTO:
> >>> +__rte_crypto_op_reset(&ol->op.crypto); break;
> >>> +default:
> >>> +break;
> >>> +}
> >>> +}
> >>
> >> Would it work if several OL are registered?
> >
> > I can't see any reason why it wouldn't
> 
> Sorry, I read it to quickly. I thought it was a
> rte_pktmbuf_offload_detach() function. By the way there is no
> such function?
> 
> 
> >> Also, what is not clear to me is how the offload structure is freed.
> >> For instance, I think that calling rte_pktmbuf_free(m) on a mbuf
> >> that has a offload attached would result in a leak.
> >>
> >> It would mean that it is not allowed to call any function that free or
> >> reassemble a mbuf when an offload is attached.
> >
> > We just need to walk the chain of offloads calling
> > rte_pktmbuf_offload_free(), before freeing the mbuf, which will be an
> > issue with any externally attached meta data. In the case of
> > reassembling I don't see why we would just move the chain to the head mbuf.
> 
> Walking the chain of offload + adding the initialization will probably
> have a little cost that should be evaluated.
> 
> The freeing is probably not the only problem:
> - packet duplication: are the offload infos copied? If no, it means that
>   the copy is not exactly a copy
> - if you chain 2 mbufs that both have offload info attached, how does it
>   behave?
> - if you prepend a segment to your mbuf, you need to copy the mbuf
>   offload pointer, and also parse the list of offload to update the
>   ol->m pointer of each element.
> 
> >> It seems that these offload structures are only used to pass crypto
> >> info to the cryptodev. Would it be a problem to have an API like this?
> >>
> >>rx_burst(port, q, mbuf_tab, crypto_tab, n);
> >>
> >
> > I really dislike this option, there's no direct linkage between mbuf and
> > offload operation.
> >
> >> Or even:
> >>
> >>rx_burst(port, q, crypto_tab, n);
> >>
> >>with each *cryto_tab pointing to a mbuf
> >>
> >
> > I looked at this but it would really hamstring any pipelining
> > applications which might want to attach multiple offloads to a mbuf at a
> > point in the pipeline for processing at later steps.
> 
> As far as I can see, there is already a way to chain several crypto
> operations in the crypto structure.
> 
> Another option is to use the mbuf offload API (or the m->userdata
> pointer which already works for that) only in the application:
> 
> - the field is completely ignored by the mbuf api and the dpdk driver
> - it is up to the application to initialize it and free it
> 
> -> it can only be used when passing mbuf from a part of the app
>to another, so it perfectly matches the pipeline use case.

I don't think we should start to re-use userdata.
Userdata was intended for the upper layer app to pass/store it's
private data associated with mbuf, and we probably should keep it this way.
While mbuf_offload (or whatever we'll name it) supposed to keep data
necessary for crypto (and other future type of devices) to operate with mbuf.

All your comments above about that this new field is just ignored by most mbuf
operations (copy/attach/append/free, etc) a

[dpdk-dev] [PATCH] test: fix crash in pmd_perf_test

[David Hunt]

Fix crash in pmd_perf_test autotest (div by 0) when no packets received
Also fixes the fact that the test passes even if exec_burst fails

To repeat the issue:
  The system must be incorrectly set up so that all packets will be lost, 
  i.e. no loopback cable, etc. This is an edge case, but still the test
  should not crash or pass when failing.
  run the test app
  RTE>> set_rxtx_sc poll_before_xmit
  RTE>> pmd_perf_autotest 
  --snip--
  > Generate 4096 packets @socket 1
  > start to receive total expect 4096
  > 4096 packets lost, IDLE 1 times
  > Floating point exception (core dumped)

Signed-off-by: David Hunt 
---
 app/test/test_pmd_perf.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/app/test/test_pmd_perf.c b/app/test/test_pmd_perf.c
index 8f55640..25b4d09 100644
--- a/app/test/test_pmd_perf.c
+++ b/app/test/test_pmd_perf.c
@@ -626,7 +626,10 @@ timeout:

rte_free(pkts_burst);

-   return diff_tsc / total;
+   if (total > 0)
+   return diff_tsc / total;
+   else
+   return -1;
 }

 static int
@@ -673,8 +676,10 @@ exec_burst(uint32_t flags, int lcore)

/* wait for polling finished */
diff_tsc = rte_eal_wait_lcore(lcore);
-   if (diff_tsc < 0)
+   if (diff_tsc < 0) {
+   printf("exec_burst: Failed to measure cycles per packet\n");
return -1;
+   }

printf("Result: %d cycles per packet\n", diff_tsc);

@@ -811,7 +816,8 @@ test_pmd_perf(void)
return -1;
} else if (sc_flag == SC_BURST_POLL_FIRST ||
   sc_flag == SC_BURST_XMIT_FIRST)
-   exec_burst(sc_flag, slave_id);
+   if (exec_burst(sc_flag, slave_id) < 0)
+   return -1;

/* port tear down */
for (portid = 0; portid < nb_ports; portid++) {
-- 
2.1.0

[dpdk-dev] [PATCH] eal: fix plugindir processing to be filesystem agnostic

[Thomas Monjalon]

Hi Panu,

2015-11-23 08:04, Panu Matilainen:
> On 11/20/2015 06:38 PM, David Marchand wrote:
> > It looks like you would skip the symbolic links while you were not before.
> > Intended ?
> 
> Intended. We want to accept symlinks in the driver directory, but the 
> actual drivers are always regular files.

No we use symbolic links:
http://dpdk.org/browse/dpdk/commit/mk/rte.lib.mk?id=133b75923
http://dpdk.org/browse/dpdk/tree/mk/rte.lib.mk#n170

On the same topic, you've added a check in 9f8eb1d9:
+   if (stat(solib->name, &sb) == -1) {
+   RTE_LOG(ERR, EAL, "Invalid plugin specified: %s: %s\n",
+   solib->name, strerror(errno));

It is a regression because we cannot anymore load a plugin from
LD_LIBRARY_PATH without specifying its full path.
It can be tested with scripts/test-null.sh.
How do you suggest to fix it?

Thanks

[dpdk-dev] [PATCH] vhost-user: fix enabling of queue pair

[Yuanhan Liu]

On Fri, Nov 20, 2015 at 03:45:00PM +0200, Victor Kaplansky wrote:
> The VHOST_USER_SET_VRING_ENABLE request is sent for each queue in
> queue-pair separately. So, a queue-pair should be considered
> enabled only when both RX and TX queues are enabled.

Hi Victor,

It was sent per queue-pair, and I found that Michael changed it to
per vring. The reason I made it per queue-pair is that the backend
can handle both queues in one queue-pair. However, I agree that
making it per queue (vring) is better here, to keep the consistency
of sending all requests (say vring_call) per vring.

> 
> The old code caused segfault when last TX queue was enabled.
> 
> Signed-off-by: Victor Kaplansky 
> ---
>  lib/librte_vhost/vhost_user/virtio-net-user.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c 
> b/lib/librte_vhost/vhost_user/virtio-net-user.c
> index d07452a..c06e53e 100644
> --- a/lib/librte_vhost/vhost_user/virtio-net-user.c
> +++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
> @@ -317,21 +317,25 @@ user_set_vring_enable(struct vhost_device_ctx ctx,
> struct vhost_vring_state *state)
>  {
>   struct virtio_net *dev = get_device(ctx);
> - uint16_t base_idx = state->index;
> + uint16_t idx = state->index;
> + uint16_t base_idx = (idx / VIRTIO_QNUM) * VIRTIO_QNUM;
>   int enable = (int)state->num;
> + int qpair_enabled;
>  
>   RTE_LOG(INFO, VHOST_CONFIG,
>   "set queue enable: %d to qp idx: %d\n",
>   enable, state->index);
>  
> + dev->virtqueue[idx]->enabled = enable;
> + qpair_enabled =
> + dev->virtqueue[base_idx + VIRTIO_RXQ]->enabled &&
> + dev->virtqueue[base_idx + VIRTIO_TXQ]->enabled;
> +
>   if (notify_ops->vring_state_changed) {
>   notify_ops->vring_state_changed(dev, base_idx / VIRTIO_QNUM,
> - enable);
> + qpair_enabled);

Here we could make the vring_state_changed callback be per vring then,
instead of per queue-pair. That make the code simpler, as well as more
consistent.

Thanks.

--yliu
>   }
>  
> - dev->virtqueue[base_idx + VIRTIO_RXQ]->enabled = enable;
> - dev->virtqueue[base_idx + VIRTIO_TXQ]->enabled = enable;
> -
>   return 0;
>  }
>  
> -- 
> --Victor

[dpdk-dev] Mellanox dpdk issues

[Gilad Berman]

Sotiris, 

I've compiled MLNX_DPDK-2.1_1.1 on SLES12  3.12.28-4-default with OFED 
3.1-1.0.3 with no issues. Also, no modifications were required - simply follow 
the quick start guide here - 
http://www.mellanox.com/page/products_dyn?product_family=209&mtag=pmd_for_dpdk

If you are still having issues please mail me directly and we'll sort it out.

Thx.

Gilad Berman | Staff System Engineer | Business Development | Mellanox 
Technologies Ltd. 
Work: +972 52 2554262| 6 Ha'Barzel St. Tel Aviv 6971010, Israel


-Original Message-
From: Olga Shern 
Sent: Sunday, November 22, 2015 3:45 PM
To: Gilad Berman ; Sotiris Salloumis ; dev at dpdk.org
Subject: RE: Mellanox dpdk issues

Hi Sotiris, 

You can disable compilation of igb_uio, this module is not needed for Mellanox 
PMD.

Let me know if you have any question 

Best Regards,
Olga




-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gilad Berman
Sent: Sunday, November 22, 2015 1:30 PM
To: Sotiris Salloumis ; dev at dpdk.org
Subject: Re: [dpdk-dev] Mellanox dpdk issues

Let us check and get back to you. 


Gilad Berman | Staff System Engineer | Business Development | Mellanox 
Technologies Ltd. 
Work: +972 52 2554262| 6 Ha'Barzel St. Tel Aviv 6971010, Israel


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sotiris Salloumis
Sent: Friday, November 20, 2015 7:35 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Mellanox dpdk issues

Hi all,

I'm trying to build DPDK for Mellanox ( using MLNX_DPDK-2.1_1.1 ) but I get the 
following error following the guidelines i.e. make install 
T=x86_64-native-linuxapp-gcc

== Build lib/librte_eal/linuxapp/igb_uio
make[8]: *** /lib/modules/3.12.28-4-default/build: No such file or directory.  
Stop.
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.module.mk:79: recipe for target 
'igb_uio.ko' failed
make[7]: *** [igb_uio.ko] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'igb_uio' failed
make[6]: *** [igb_uio] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'linuxapp' failed
make[5]: *** [linuxapp] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'librte_eal' failed
make[4]: *** [librte_eal] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkbuild.mk:93: recipe for target 
'lib' failed
make[3]: *** [lib] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:124: recipe for target 
'all' failed
make[2]: *** [all] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkinstall.mk:58: recipe for target 
'x86_64-native-linuxapp-gcc_install' failed
make[1]: *** [x86_64-native-linuxapp-gcc_install] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:102: recipe for target 
'install' failed
make: *** [install] Error 2

The environment is SLES12


-  Linux linux-okj7 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 
2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux

-  3.12.28-4-default

>From Mellanox point of view the only difference I see is related with firmware 
>version

 Performing Adapter Device Self Test  Number of CAs Detected 
. 1 PCI Device Check ... PASS Kernel Arch 
 x86_64 Host Driver Version  
MLNX_OFED_LINUX-3.1-1.0.3 (OFED-3.1-1.0.3): 3.12.28-4-default Host Driver RPM 
Check .. PASS Firmware on CA #0 NIC .. 
v2.35.5130 Firmware Check on CA #0 (NIC) .. PASS
NOTE: The found fw version is higher than the fw included in this package 
(v2.35.5100) Host Driver Initialization . PASS Number of CA Ports 
Active .. 2 Port State of Port #1 on CA #0 (NIC). UP 1X QDR 
(Ethernet) Port State of Port #2 on CA #0 (NIC). UP 1X QDR (Ethernet) Error 
Counter Check on CA #0 (NIC).. NA (Eth ports) Kernel Syslog Check 
 PASS Node GUID on CA #0 (NIC) ... 
a0:1d:48:03:00:b5:a6:17
-- DONE -

Any hints?

Thanks
Sotiris

[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling

[Bruce Richardson]

On Mon, Nov 23, 2015 at 02:54:54AM +, Xie, Huawei wrote:
 I checked shared mapping with MAP_POPULATE between two processes. It
> works. Then i did some search, find the manual is also ambiguous to
> others and thus have been changed, :).
> Before: MAP_POPULATE is only supported for private mappings since Linux
> 2.6.23.
> After: MAP_POPULATE is supported for private mappings only since Linux
> 2.6.23.
> http://stackoverflow.com/questions/23502361/linux-mmap-with-map-populate-man-page-seems-to-give-wrong-info
> >

Doesn't matter much for us, as we use shared rather than private mappings for 
the
hugepages.

/Bruce

[dpdk-dev] [PATCH] igb/e1000: Copy PCI device info after the rte_eal_process_type() check

[Jon DeVree]

This fixes a bug added to these two drivers by eeefe73 (drivers: copy
PCI device info to ethdev data) which causes the pci info seen by the
primary process to become invalidated by secondary process startup.
This call was added after the process type check in the other drivers.

Signed-off-by: Jon DeVree 
---
 drivers/net/e1000/em_ethdev.c  | 4 ++--
 drivers/net/e1000/igb_ethdev.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 3e81109..66e8993 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -244,8 +244,6 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)

pci_dev = eth_dev->pci_dev;

-   rte_eth_copy_pci_info(eth_dev, pci_dev);
-
eth_dev->dev_ops = ð_em_ops;
eth_dev->rx_pkt_burst = (eth_rx_burst_t)ð_em_recv_pkts;
eth_dev->tx_pkt_burst = (eth_tx_burst_t)ð_em_xmit_pkts;
@@ -260,6 +258,8 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
return 0;
}

+   rte_eth_copy_pci_info(eth_dev, pci_dev);
+
hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
hw->device_id = pci_dev->id.device_id;
adapter->stopped = 0;
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 88995b0..0dc6357 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -647,8 +647,6 @@ eth_igb_dev_init(struct rte_eth_dev *eth_dev)

pci_dev = eth_dev->pci_dev;

-   rte_eth_copy_pci_info(eth_dev, pci_dev);
-
eth_dev->dev_ops = ð_igb_ops;
eth_dev->rx_pkt_burst = ð_igb_recv_pkts;
eth_dev->tx_pkt_burst = ð_igb_xmit_pkts;
@@ -662,6 +660,8 @@ eth_igb_dev_init(struct rte_eth_dev *eth_dev)
return 0;
}

+   rte_eth_copy_pci_info(eth_dev, pci_dev);
+
hw->hw_addr= (void *)pci_dev->mem_resource[0].addr;

igb_identify_hardware(eth_dev);
-- 
2.6.2

[dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf

[Olivier MATZ]

Hi Declan,

On 11/20/2015 06:26 PM, Declan Doherty wrote:
>> The new files are called rte_mbuf_offload, but from what I understand,
>> it is more like a mbuf metadata api. What you call "offload operation"
>> is not called because an offload is attached, but because you call
>> rte_cryptodev_enqueue_burst() on it.
> 
> Maybe rte_mbuf_offload_metadata would be a better name, if not a bit
> more long winded :) The idea of this API set is to give a generic
> framework for attaching the the offload operation meta data to a mbuf
> which will be retrieved at a later point, when the particular offload
> burst function is called. I guess as we only have a single offload
> device at the moment the API may look a little over the top!

Indeed, not sure rte_mbuf_offload_metadata is better.
I'm still not convinced that offload should appear in the name, it
is a bit confusing with hardware offloads (ol_flags). Also, it
suggests that a work is delegated to another entity, but for instance
in this case it is just used as a storage area:

ol = rte_pktmbuf_offload_alloc(pool, RTE_PKTMBUF_OL_CRYPTO);
rte_crypto_op_attach_session(&ol->op.crypto, session);
ol->op.crypto.digest.data = rte_pktmbuf_append(m, digest_len);
ol->op.crypto.digest.phys_addr = ...;
/* ... */
rte_pktmbuf_offload_attach(m, ol);
ret = rte_cryptodev_enqueue_burst(dev_id, qp_id, &m, 1);

Do you have some other examples in mind that would use this API?

>>> +/** Rearms rte_mbuf_offload default parameters */
>>> +static inline void
>>> +__rte_pktmbuf_offload_reset(struct rte_mbuf_offload *ol,
>>> +enum rte_mbuf_ol_op_type type)
>>> +{
>>> +ol->m = NULL;
>>> +ol->type = type;
>>> +
>>> +switch (type) {
>>> +case RTE_PKTMBUF_OL_CRYPTO:
>>> +__rte_crypto_op_reset(&ol->op.crypto); break;
>>> +default:
>>> +break;
>>> +}
>>> +}
>>
>> Would it work if several OL are registered?
> 
> I can't see any reason why it wouldn't

Sorry, I read it to quickly. I thought it was a
rte_pktmbuf_offload_detach() function. By the way there is no
such function?


>> Also, what is not clear to me is how the offload structure is freed.
>> For instance, I think that calling rte_pktmbuf_free(m) on a mbuf
>> that has a offload attached would result in a leak.
>>
>> It would mean that it is not allowed to call any function that free or
>> reassemble a mbuf when an offload is attached.
> 
> We just need to walk the chain of offloads calling
> rte_pktmbuf_offload_free(), before freeing the mbuf, which will be an
> issue with any externally attached meta data. In the case of
> reassembling I don't see why we would just move the chain to the head mbuf.

Walking the chain of offload + adding the initialization will probably
have a little cost that should be evaluated.

The freeing is probably not the only problem:
- packet duplication: are the offload infos copied? If no, it means that
  the copy is not exactly a copy
- if you chain 2 mbufs that both have offload info attached, how does it
  behave?
- if you prepend a segment to your mbuf, you need to copy the mbuf
  offload pointer, and also parse the list of offload to update the
  ol->m pointer of each element.

>> It seems that these offload structures are only used to pass crypto
>> info to the cryptodev. Would it be a problem to have an API like this?
>>
>>rx_burst(port, q, mbuf_tab, crypto_tab, n);
>>
> 
> I really dislike this option, there's no direct linkage between mbuf and
> offload operation.
> 
>> Or even:
>>
>>rx_burst(port, q, crypto_tab, n);
>>
>>with each *cryto_tab pointing to a mbuf
>>
> 
> I looked at this but it would really hamstring any pipelining
> applications which might want to attach multiple offloads to a mbuf at a
> point in the pipeline for processing at later steps.

As far as I can see, there is already a way to chain several crypto
operations in the crypto structure.

Another option is to use the mbuf offload API (or the m->userdata
pointer which already works for that) only in the application:

- the field is completely ignored by the mbuf api and the dpdk driver
- it is up to the application to initialize it and free it

-> it can only be used when passing mbuf from a part of the app
   to another, so it perfectly matches the pipeline use case.

Example:

app_core1:

  /* receive a mbuf */
  crypto = alloc()
  crypto->xxx = yyy:
  /* ... */
  m->userdata = crypto;
  enqueue(m, app_core2);

app_core2:

  m = dequeue();
  crypto = m->userdata;
  m->userdata = NULL;
  /* api is tx_burst(port, q, mbuf_tab, crypto_tab, n) */
  tx_burst(port, q, &m, &crypto, 1);



Regards,
Olivier

[dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check for nb_tx_desc during txq setup

[Liu, Yong]

Yuanhan,
First three reports is for patch sets in the same email thread. I think 
patchwork scanned the mail and strip all of them out.
So the patch names did not change any more. For the failure one, it caused by 
validation environment. We're trying to find the root cause.

> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Monday, November 23, 2015 3:42 PM
> To: Liu, Yong
> Cc: dev at dpdk.org; Felix Marti; Kumar Sanghvi; Nirranjan Kirubaharan
> Subject: Re: [dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check
> for nb_tx_desc during txq setup
> 
> On Mon, Nov 23, 2015 at 07:36:38AM +, Liu, Yong wrote:
> > Yuanhan,
> > The validation system is based on dpkdk.org patchwork, all patch sets
> recorded by patchwork should be validated.
> > Can you supply the patch Id or just patch name? Thus, we can check out
> what happened.
> 
> Sure, here you go:
> 
>  589   T Nov 18 sys_stv at intel.c (  19) |SUCCESS| pw 8988 vhost: avoid
> buffer overflow in update_secure_len
>  733 r T Nov 17 sys_stv at intel.c (  19) |SUCCESS| pw 8965 vhost: avoid
> buffer overflow in update_secure_len
>  863   T Nov 17 sys_stv at intel.c (  19) |SUCCESS| pw 8960 vhost: avoid
> buffer overflow in update_secure_len
> 1230 r T Nov 11 sys_stv at intel.c (  87) |ERROR| pw 8870  vhost: reset
> device properly
> 
>   --yliu
> 
> >
> > > -Original Message-
> > > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> > > Sent: Monday, November 23, 2015 3:27 PM
> > > To: Liu, Yong
> > > Cc: dev at dpdk.org; Felix Marti; Kumar Sanghvi; Nirranjan Kirubaharan
> > > Subject: Re: [dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity
> check
> > > for nb_tx_desc during txq setup
> > >
> > > On Mon, Nov 23, 2015 at 07:06:45AM +, Liu, Yong wrote:
> > > > Hi Rahul,
> > > > Your patch passed "checksum_offload_with_vlan" after rerun this case.
> > > Please ignore this error report.
> > >
> > > I got a same report few weeks ago. And my patch was very vhost-user
> > > specific, touching nothing else. Even though, I sent a report for
> > > double check, and got no reply.
> > >
> > > I also got several "report" while replying to the same patch (not from
> > > me). I sent another report, yet no reply received.
> > >
> > >
> > >   --yliu
> > >
> > > >
> > > > > -Original Message-
> > > > > From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com]
> > > > > Sent: Friday, November 20, 2015 9:37 PM
> > > > > To: dev at dpdk.org
> > > > > Cc: Liu, Yong; Kumar Sanghvi; Nirranjan Kirubaharan; Felix Marti
> > > > > Subject: Re: |ERROR| pw 9018 ethdev: add a missing sanity check
> for
> > > > > nb_tx_desc during txq setup
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I received this auto email regarding 'Unexpected Packets Drop' and
> > > > > it is referring to my patch.  I don't think I've changed anything
> that
> > > > > could cause this.  Kindly advise.
> > > > >
> > > > > Thanks,
> > > > > Rahul
> > > > >
> > > > > On Friday, November 11/20/15, 2015 at 03:14:51 -0800,
> > > sys_stv at intel.com
> > > > > wrote:
> > > > > > Test-Label: Intel Niantic on Fedora
> > > > > > Test-Status: ERROR
> > > > > > Patchwork: http://www.dpdk.org/dev/patchwork/patch/9018/
> > > > > >
> > > > > > DPDK git baseline: e64833f2273ac67becbca10d9f2f1598872dc99e
> > > > > > Patchwork ID: 9018
> > > > > > http://www.dpdk.org/dev/patchwork/patch/9018/
> > > > > > Submitter: Rahul Lakkireddy 
> > > > > > Date: Fri, 20 Nov 2015 15:56:37 +0530
> > > > > >
> > > > > > Source Compilation:
> > > > > > OS: fedora
> > > > > > Nic: niantic
> > > > > > i686-native-linuxapp-gcc: compile pass
> > > > > > x86_64-native-linuxapp-gcc: compile pass
> > > > > >
> > > > > > DTS validation:
> > > > > > OS: fedora
> > > > > > Nic: Niantic
> > > > > > TestType: auto
> > > > > > GCC: 4
> > > > > > x86_64-native-linuxapp-gcc:  total 79, passed 78, failed 1.
> > > > > > Failed Case List:
> > > > > > Target: x86_64-native-linuxapp-gcc
> > > > > > OS: fedora
> > > > > > Failed DTS case:
> > > > > > checksum_offload_with_vlan:
> > > > >
> > >
> http://dpdk.org/browse/tools/dts/tree/test_plans/checksum_offload_test_pla
> > > > > n.rst
> > > > > >
> > > > > > DTS Validation Error:
> > > > > >
> > > > >
> > >
> ==
> > > > > ==
> > > > > >
> > > > >
> > >
> ==
> > > > > ==
> > > > > > TEST SUITE : TestChecksumOffload
> > > > > >
> > > > > > 
> 
> > > 
> > > > > ---
> > > > > > Begin: Test Casetest_checksum_offload_with_vlan
> > > > > > --
> > > > > > FAILED  'Unexpected Packets Drop'
> > > > > > --
> > > > > > [   SUITE_DUT_C

[dpdk-dev] [PATCH v2] i40e: fix issue of reconfigure hash enable flags

[Wu, Jingjing]

> -Original Message-
> From: Zhang, Helin
> Sent: Monday, November 23, 2015 2:19 PM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Pei, Yulong; Zhang, Helin
> Subject: [PATCH v2] i40e: fix issue of reconfigure hash enable flags
> 
> It fixes the issue of not re-configuring hash enable flags (HENA) if there is 
> no
> key.
> 
> Fixes: d0a349409bd7 ("i40e: support AQ based RSS config")
> 
> Signed-off-by: Helin Zhang 
Acked-by: Jingjing Wu 

[dpdk-dev] [PATCH] eal: fix plugindir processing to be filesystem agnostic

[Panu Matilainen]

On 11/20/2015 06:38 PM, David Marchand wrote:
> Hello Panu,
>
> On Wed, Nov 18, 2015 at 7:45 AM, Panu Matilainen 
> wrote:
>
>> Not all filesystems supply struct dirent d_type field, in which case
>> everything in the specified directory would go ignored. One such
>> filesystem being XFS which RHEL 7 defaults to... stat() the entries
>> instead.
>>
>> Fixes: 9f8eb1d9ca0f ("eal: support driver loading from directory")
>>
>> Signed-off-by: Panu Matilainen 
>> ---
>>   lib/librte_eal/common/eal_common_options.c | 6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/librte_eal/common/eal_common_options.c
>> b/lib/librte_eal/common/eal_common_options.c
>> index bed7385..e51fa12 100644
>> --- a/lib/librte_eal/common/eal_common_options.c
>> +++ b/lib/librte_eal/common/eal_common_options.c
>> @@ -191,12 +191,14 @@ eal_plugindir_init(const char *path)
>>  }
>>
>>  while ((dent = readdir(d)) != NULL) {
>> -   if (dent->d_type != DT_REG && dent->d_type != DT_LNK)
>> -   continue;
>> +   struct stat sb;
>>
>>  snprintf(sopath, PATH_MAX-1, "%s/%s", path, dent->d_name);
>>  sopath[PATH_MAX-1] = 0;
>>
>> +   if (!(stat(sopath, &sb) == 0 && S_ISREG(sb.st_mode)))
>> +   continue;
>> +
>>  if (eal_plugin_add(sopath) == -1)
>>  break;
>>  }
>
>
>
> It looks like you would skip the symbolic links while you were not before.
> Intended ?

Intended. We want to accept symlinks in the driver directory, but the 
actual drivers are always regular files. Since stat() dereferences 
symbolic links it cannot return a file whose type would be S_IFLNK.

- Panu -

[dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check for nb_tx_desc during txq setup

[Liu, Yong]

Yuanhan,
The validation system is based on dpkdk.org patchwork, all patch sets recorded 
by patchwork should be validated.
Can you supply the patch Id or just patch name? Thus, we can check out what 
happened. 

> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Monday, November 23, 2015 3:27 PM
> To: Liu, Yong
> Cc: dev at dpdk.org; Felix Marti; Kumar Sanghvi; Nirranjan Kirubaharan
> Subject: Re: [dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check
> for nb_tx_desc during txq setup
> 
> On Mon, Nov 23, 2015 at 07:06:45AM +, Liu, Yong wrote:
> > Hi Rahul,
> > Your patch passed "checksum_offload_with_vlan" after rerun this case.
> Please ignore this error report.
> 
> I got a same report few weeks ago. And my patch was very vhost-user
> specific, touching nothing else. Even though, I sent a report for
> double check, and got no reply.
> 
> I also got several "report" while replying to the same patch (not from
> me). I sent another report, yet no reply received.
> 
> 
>   --yliu
> 
> >
> > > -Original Message-
> > > From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com]
> > > Sent: Friday, November 20, 2015 9:37 PM
> > > To: dev at dpdk.org
> > > Cc: Liu, Yong; Kumar Sanghvi; Nirranjan Kirubaharan; Felix Marti
> > > Subject: Re: |ERROR| pw 9018 ethdev: add a missing sanity check for
> > > nb_tx_desc during txq setup
> > >
> > > Hi all,
> > >
> > > I received this auto email regarding 'Unexpected Packets Drop' and
> > > it is referring to my patch.  I don't think I've changed anything that
> > > could cause this.  Kindly advise.
> > >
> > > Thanks,
> > > Rahul
> > >
> > > On Friday, November 11/20/15, 2015 at 03:14:51 -0800,
> sys_stv at intel.com
> > > wrote:
> > > > Test-Label: Intel Niantic on Fedora
> > > > Test-Status: ERROR
> > > > Patchwork: http://www.dpdk.org/dev/patchwork/patch/9018/
> > > >
> > > > DPDK git baseline: e64833f2273ac67becbca10d9f2f1598872dc99e
> > > > Patchwork ID: 9018
> > > > http://www.dpdk.org/dev/patchwork/patch/9018/
> > > > Submitter: Rahul Lakkireddy 
> > > > Date: Fri, 20 Nov 2015 15:56:37 +0530
> > > >
> > > > Source Compilation:
> > > > OS: fedora
> > > > Nic: niantic
> > > > i686-native-linuxapp-gcc: compile pass
> > > > x86_64-native-linuxapp-gcc: compile pass
> > > >
> > > > DTS validation:
> > > > OS: fedora
> > > > Nic: Niantic
> > > > TestType: auto
> > > > GCC: 4
> > > > x86_64-native-linuxapp-gcc:  total 79, passed 78, failed 1.
> > > > Failed Case List:
> > > > Target: x86_64-native-linuxapp-gcc
> > > > OS: fedora
> > > > Failed DTS case:
> > > > checksum_offload_with_vlan:
> > >
> http://dpdk.org/browse/tools/dts/tree/test_plans/checksum_offload_test_pla
> > > n.rst
> > > >
> > > > DTS Validation Error:
> > > >
> > >
> ==
> > > ==
> > > >
> > >
> ==
> > > ==
> > > > TEST SUITE : TestChecksumOffload
> > > >
> > > > 
> 
> > > ---
> > > > Begin: Test Casetest_checksum_offload_with_vlan
> > > > --
> > > > FAILED  'Unexpected Packets Drop'
> > > > --
> > > > [   SUITE_DUT_CMD]  ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x6
> -n 4
> > > -- -i --portmask=0x3 --disable-hw-vlan --enable-rx-cksum --crc-strip -
> -
> > > txqflags=0
> > > > [   SUITE_DUT_CMD]  set verbose 1
> > > > [   SUITE_DUT_CMD]  set fwd csum
> > > > [   SUITE_DUT_CMD]  csum set ip hw 0
> > > > [   SUITE_DUT_CMD]  csum set udp hw 0
> > > > [   SUITE_DUT_CMD]  csum set tcp hw 0
> > > > [   SUITE_DUT_CMD]  csum set sctp hw 0
> > > > [   SUITE_DUT_CMD]  csum set ip hw 1
> > > > [   SUITE_DUT_CMD]  csum set udp hw 1
> > > > [   SUITE_DUT_CMD]  csum set tcp hw 1
> > > > [   SUITE_DUT_CMD]  csum set sctp hw 1
> > > > [   SUITE_DUT_CMD]  start
> > > > [SUITE_TESTER_CMD]  scapy
> > > > [SUITE_TESTER_CMD]  sys.path.append("./")
> > > > [SUITE_TESTER_CMD]  from sctp import *
> > > > [SUITE_TESTER_CMD]  p =
> > > Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::2")/UDP()/("X"*46)
> > > > [SUITE_TESTER_CMD]  p.show2()
> > > > [SUITE_TESTER_CMD]  p =
> > > Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/SCTP()/("X"*48)
> > > > [SUITE_TESTER_CMD]  p.show2()
> > > > [SUITE_TESTER_CMD]  p =
> > > Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::2")/TCP()/("X"*46)
> > > > [SUITE_TESTER_CMD]  p.show2()
> > > > [SUITE_TESTER_CMD]  p =
> > > Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/UDP()/("X"*46)
> > > > [SUITE_TESTER_CMD]  p.show2()
> > > > [SUITE_TESTER_CMD]  p =
> > > Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/TCP()/("X"*46)
> > > > [SUITE_TESTER_CMD]  p.show2()
> > > > [SUITE_TESTER_CMD]  exit()
> > > > [SUITE_TESTER_CMD]  echo -n '' 

[dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check for nb_tx_desc during txq setup

[Liu, Yong]

Hi Rahul,
Your patch passed "checksum_offload_with_vlan" after rerun this case. Please 
ignore this error report.

> -Original Message-
> From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com]
> Sent: Friday, November 20, 2015 9:37 PM
> To: dev at dpdk.org
> Cc: Liu, Yong; Kumar Sanghvi; Nirranjan Kirubaharan; Felix Marti
> Subject: Re: |ERROR| pw 9018 ethdev: add a missing sanity check for
> nb_tx_desc during txq setup
> 
> Hi all,
> 
> I received this auto email regarding 'Unexpected Packets Drop' and
> it is referring to my patch.  I don't think I've changed anything that
> could cause this.  Kindly advise.
> 
> Thanks,
> Rahul
> 
> On Friday, November 11/20/15, 2015 at 03:14:51 -0800, sys_stv at intel.com
> wrote:
> > Test-Label: Intel Niantic on Fedora
> > Test-Status: ERROR
> > Patchwork: http://www.dpdk.org/dev/patchwork/patch/9018/
> >
> > DPDK git baseline: e64833f2273ac67becbca10d9f2f1598872dc99e
> > Patchwork ID: 9018
> > http://www.dpdk.org/dev/patchwork/patch/9018/
> > Submitter: Rahul Lakkireddy 
> > Date: Fri, 20 Nov 2015 15:56:37 +0530
> >
> > Source Compilation:
> > OS: fedora
> > Nic: niantic
> > i686-native-linuxapp-gcc: compile pass
> > x86_64-native-linuxapp-gcc: compile pass
> >
> > DTS validation:
> > OS: fedora
> > Nic: Niantic
> > TestType: auto
> > GCC: 4
> > x86_64-native-linuxapp-gcc:  total 79, passed 78, failed 1.
> > Failed Case List:
> > Target: x86_64-native-linuxapp-gcc
> > OS: fedora
> > Failed DTS case:
> > checksum_offload_with_vlan:
> http://dpdk.org/browse/tools/dts/tree/test_plans/checksum_offload_test_pla
> n.rst
> >
> > DTS Validation Error:
> >
> ==
> ==
> >
> ==
> ==
> > TEST SUITE : TestChecksumOffload
> >
> > 
> ---
> > Begin: Test Casetest_checksum_offload_with_vlan
> > --
> > FAILED  'Unexpected Packets Drop'
> > --
> > [   SUITE_DUT_CMD]  ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x6 -n 4
> -- -i --portmask=0x3 --disable-hw-vlan --enable-rx-cksum --crc-strip --
> txqflags=0
> > [   SUITE_DUT_CMD]  set verbose 1
> > [   SUITE_DUT_CMD]  set fwd csum
> > [   SUITE_DUT_CMD]  csum set ip hw 0
> > [   SUITE_DUT_CMD]  csum set udp hw 0
> > [   SUITE_DUT_CMD]  csum set tcp hw 0
> > [   SUITE_DUT_CMD]  csum set sctp hw 0
> > [   SUITE_DUT_CMD]  csum set ip hw 1
> > [   SUITE_DUT_CMD]  csum set udp hw 1
> > [   SUITE_DUT_CMD]  csum set tcp hw 1
> > [   SUITE_DUT_CMD]  csum set sctp hw 1
> > [   SUITE_DUT_CMD]  start
> > [SUITE_TESTER_CMD]  scapy
> > [SUITE_TESTER_CMD]  sys.path.append("./")
> > [SUITE_TESTER_CMD]  from sctp import *
> > [SUITE_TESTER_CMD]  p =
> Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::2")/UDP()/("X"*46)
> > [SUITE_TESTER_CMD]  p.show2()
> > [SUITE_TESTER_CMD]  p =
> Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/SCTP()/("X"*48)
> > [SUITE_TESTER_CMD]  p.show2()
> > [SUITE_TESTER_CMD]  p =
> Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::2")/TCP()/("X"*46)
> > [SUITE_TESTER_CMD]  p.show2()
> > [SUITE_TESTER_CMD]  p =
> Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/UDP()/("X"*46)
> > [SUITE_TESTER_CMD]  p.show2()
> > [SUITE_TESTER_CMD]  p =
> Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/TCP()/("X"*46)
> > [SUITE_TESTER_CMD]  p.show2()
> > [SUITE_TESTER_CMD]  exit()
> > [SUITE_TESTER_CMD]  echo -n '' >  scapyResult.txt
> > [SUITE_TESTER_CMD]  scp sniff.py root at 10.239.128.80:~/
> > [SUITE_TESTER_CMD]  SCAPY Receive setup:
> > [SUITE_TESTER_CMD]  scapy
> > [SUITE_TESTER_CMD]  subprocess.call("scapy -c sniff.py &", shell=True)
> > [SUITE_TESTER_CMD]  sys.path.append("./")
> > [SUITE_TESTER_CMD]  import sctp
> > [SUITE_TESTER_CMD]  from sctp import *
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::1")/UDP(chksum=0xf)/("X"
> *46)], iface="p785p2")
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IP(chksum=0x0)/SCTP(chksum=0xf)/("X"
> *48)], iface="p785p2")
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::1")/TCP(chksum=0xf)/("X"
> *46)], iface="p785p2")
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IP(chksum=0x0)/UDP(chksum=0xf)/("X"*
> 46)], iface="p785p2")
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IP(chksum=0x0)/TCP(chksum=0xf)/("X"*
> 46)], iface="p785p2")
> > [SUITE_TESTER_CMD]  exit()
> > [SUITE_TESTER_CMD]  cat scapyResult.txt
> > [SUITE_TESTER_CMD]  SCAPY Result:
> > End test_checksum_offload_with_vlan
> > 
> ---
> > [SUITE_DUT_CMD] quit
> >
> >
> >
> > DPDK STV team

[dpdk-dev] [PATCH] i40e: fix issue of reconfigure hash enable flags

[Zhang, Helin]

> -Original Message-
> From: Wu, Jingjing
> Sent: Monday, November 23, 2015 1:54 PM
> To: Zhang, Helin; dev at dpdk.org
> Cc: Pei, Yulong
> Subject: RE: [PATCH] i40e: fix issue of reconfigure hash enable flags
> 
> >
> > -   if (!key || key_len != ((I40E_PFQF_HKEY_MAX_INDEX + 1) *
> > -   sizeof(uint32_t)))
> > +   if (!key || key_len == 0) {
> > +   PMD_DRV_LOG(DEBUG, "No key to be configured");
> > +   return 0;
> > +   } else if (key && (key_len != (I40E_PFQF_HKEY_MAX_INDEX + 1) *
> > +   sizeof(uint32_t))) {
> No need to check key in else if, it shouldn't be NULL here.
Yes, it should be removed. Thanks!

Regards,
Helin

> > +   PMD_DRV_LOG(ERR, "Invalid key length %u", key_len);
> > return -EINVAL;
> > +   }
> 
> Thanks
> Jingjing

[dpdk-dev] [PATCH] i40e: fix issue of reconfigure hash enable flags

[Wu, Jingjing]

> 
> - if (!key || key_len != ((I40E_PFQF_HKEY_MAX_INDEX + 1) *
> - sizeof(uint32_t)))
> + if (!key || key_len == 0) {
> + PMD_DRV_LOG(DEBUG, "No key to be configured");
> + return 0;
> + } else if (key && (key_len != (I40E_PFQF_HKEY_MAX_INDEX + 1) *
> + sizeof(uint32_t))) {
No need to check key in else if, it shouldn't be NULL here.
> + PMD_DRV_LOG(ERR, "Invalid key length %u", key_len);
>   return -EINVAL;
> + }

Thanks
Jingjing

[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling

[Xie, Huawei]

On 11/23/2015 12:07 PM, Stephen Hemminger wrote:
> On Mon, 23 Nov 2015 03:46:31 +
> "Xie, Huawei"  wrote:
>
>>> Why cannot we rely on the kernel zeroing the memory ?
>>> If that behavior were to change, then we can zero out the memory
>>> ourselves.  
>> It is undocumented kernel behavior. My opinion is if not a big burden,
>> zero out the needed memory ourselves, otherwise resort to this kernel
>> behavior.
> Really, I think it is more an oversight of missing documentation,
> the kernel has always (and will continue) to zero out memory that is given
> to a process. If it didn't it would be a massive security hole.
Agree. I believe this behavior will not change in future. For the
security issue, kernel could also set all bits like to 1. Just wonder if
this is best practice and whether there are other user space programs
rely on this behavior.

[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling

[Xie, Huawei]

On 11/19/2015 5:15 PM, Gonzalez Monroy, Sergio wrote:
> On 18/11/2015 12:07, Xie, Huawei wrote:
>> On 11/18/2015 6:45 PM, Wang, Zhihong wrote:
 -Original Message-
 From: Mcnamara, John
 Sent: Wednesday, November 18, 2015 6:40 PM
 To: Wang, Zhihong ; dev at dpdk.org
 Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
 unnecessary
 hugepage zero-filling



> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhihong Wang
> Sent: Wednesday, November 18, 2015 3:27 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
> unnecessary
> hugepage zero-filling
>
> The kernel fills new allocated (huge) pages with zeros.
> DPDK just has to touch the pages to trigger the allocation.
>> I think we shouldn't reply on the assumption that kernel has zeroed the
>> memory. Kernel zeroes the memory mostly to avoid information leakage.It
>> could also achieve this by setting each bit to 1.
>> What we indeed need to check is later DPDK initialization code doesn't
>> assume the memory has been zeroed. Otherwise zero only that part of the
>> memory. Does this makes sense?
>
> Why cannot we rely on the kernel zeroing the memory ?
> If that behavior were to change, then we can zero out the memory
> ourselves.
It is undocumented kernel behavior. My opinion is if not a big burden,
zero out the needed memory ourselves, otherwise resort to this kernel
behavior.

>
> Bruce pointed out to me that the semantics have changed a bit since we
> introduced
> rte_memzone_free.
> Before that, all memzone reserve were zero out by default.
> Is there code relying on that? I'm not sure, but it still is good
> practice to do it.
>
> I submitted an RFC regarding this:
> http://dpdk.org/ml/archives/dev/2015-November/028416.html
>
> The idea would be to keep the available memory we are managing zeroed
> at all times.
>
> Sergio
> ...
>   if (orig) {
>   hugepg_tbl[i].orig_va = virtaddr;
> -memset(virtaddr, 0, hugepage_sz);
> +memset(virtaddr, 0, 8);
>   }
 Probably worth adding a one or two line comment here to avoid someone
 thinking that it is a bug at some later stage. The text in the
 commit message
 above is suitable.

>>> Good suggestion! Will add it :)
>>>
 John.
 -- 
>
>

[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling

[Xie, Huawei]

On 11/19/2015 2:32 PM, Wang, Zhihong wrote:
>> -Original Message-
>> From: Xie, Huawei
>> Sent: Thursday, November 19, 2015 2:05 PM
>> To: Wang, Zhihong ; Stephen Hemminger
>> ; Richardson, Bruce
>> 
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
>> hugepage zero-filling
>>
>> On 11/19/2015 10:16 AM, Wang, Zhihong wrote:
 -Original Message-
 From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
 Hemminger
 Sent: Thursday, November 19, 2015 3:09 AM
 To: Richardson, Bruce 
 Cc: dev at dpdk.org
 Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
 unnecessary hugepage zero-filling

 On Wed, 18 Nov 2015 16:13:32 +
 "Richardson, Bruce"  wrote:

>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
>> Hemminger
>> Sent: Wednesday, November 18, 2015 4:00 PM
>> To: Xie, Huawei 
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
>> unnecessary hugepage zero-filling
>>
>> On Wed, 18 Nov 2015 12:07:54 +
>> "Xie, Huawei"  wrote:
>>
>> The kernel fills new allocated (huge) pages with zeros.
>> DPDK just has to touch the pages to trigger the allocation.
>>> I think we shouldn't reply on the assumption that kernel has
>>> zeroed the memory. Kernel zeroes the memory mostly to avoid
>>> information leakage.It could also achieve this by setting each bit to 1.
>>> What we indeed need to check is later DPDK initialization code
>>> doesn't assume the memory has been zeroed. Otherwise zero only
>>> that part of the memory. Does this makes sense?
>> If all new pages are zero, why does DPDK have to pre-touch the
>> pages at all?
> The pages won't actually be mapped into the processes address space
> until
 accessed.
> /Bruce
 Isn't that what mmap MAP_POPULATE flag (not currently used) will do.
>>> Yes, the MAP_POPULATE does literally the same thing.
>>> This flag is implemented since Linux 2.5.46 according to Linux man
>>> page, guess that's why DPDK fault the page tables manually in the
>>> first place. :)
>>>
>>> I think we can use this flag since it makes the code clearer.
>> The manual says MAP_POPULATE is only supported for private mappings since
>> Linux 2.6.23.
> I've done check before and MAP_SHARED | MAP_POPULATE worked together 
> correctly. Is there any implicit complication here?
I checked shared mapping with MAP_POPULATE between two processes. It
works. Then i did some search, find the manual is also ambiguous to
others and thus have been changed, :).
Before: MAP_POPULATE is only supported for private mappings since Linux
2.6.23.
After: MAP_POPULATE is supported for private mappings only since Linux
2.6.23.
http://stackoverflow.com/questions/23502361/linux-mmap-with-map-populate-man-page-seems-to-give-wrong-info
>
>>> /Zhihong
>>>
>>>
>

[dpdk-dev] [PATCH v2 2/2] scripts: add build tests

[Thomas Monjalon]

This script helps to build a list of target with some custom options.
It tries to enable most of the options.
The examples and documentation are also built.

It uses some configuration from exported variables.
This config works on my machine:
export DPDK_DEP_PCAP=y
export DPDK_DEP_MOFED=y
   mlxdep=/opt/mofed-3.0
export DPDK_DEP_CFLAGS=-I$mlxdep/include
export DPDK_DEP_LDFLAGS=-L$mlxdep/lib
export DPDK_BUILD_TEST_CONFIGS='x86_64-native-linuxapp-gcc+shared+next
   x86_64-native-linuxapp-clang+shared+combined
   i686-native-linuxapp-gcc+combined'
export DPDK_MAKE_JOBS=8
export DPDK_NOTIFY=notify-send

Signed-off-by: Thomas Monjalon 
---
v2:
- conditionally enable szedata2
- add quotes for CFLAGS and LDFLAGS

 scripts/test-build.sh | 145 ++
 1 file changed, 145 insertions(+)
 create mode 100755 scripts/test-build.sh

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
new file mode 100755
index 000..3d3cf9f
--- /dev/null
+++ b/scripts/test-build.sh
@@ -0,0 +1,145 @@
+#! /bin/sh -e
+
+# BSD LICENSE
+#
+# Copyright 2015 6WIND S.A.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+#   * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+#   * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+#   * Neither the name of 6WIND S.A. nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+# Load config options:
+# - DPDK_BUILD_TEST_CONFIGS (target1+option1+option2 target2)
+# - DPDK_DEP_CFLAGS
+# - DPDK_DEP_LDFLAGS
+# - DPDK_DEP_MOFED (y/[n])
+# - DPDK_DEP_PCAP (y/[n])
+# - DPDK_NOTIFY (notify-send)
+. scripts/load-devel-config.sh
+
+print_usage () {
+   echo "usage: $(basename $0) [-jX] [-q] [config1 [config2] ...]]"
+}
+
+J=$DPDK_MAKE_JOBS
+quick=false
+while getopts hj:q ARG ; do
+   case $ARG in
+   j ) J=$OPTARG ;;
+   q ) quick=true ;;
+   h ) print_usage ; exit 0 ;;
+   ? ) print_usage ; exit 1 ;;
+   esac
+done
+shift $(($OPTIND - 1))
+configs=${*:-$DPDK_BUILD_TEST_CONFIGS}
+
+success=false
+on_exit ()
+{
+   if [ "$DPDK_NOTIFY" = notify-send ] ; then
+   if $success ; then
+   notify-send -u low --icon=dialog-information 'DPDK 
build' 'finished'
+   elif [ -z "$signal" ] ; then
+   notify-send -u low --icon=dialog-error 'DPDK build' 
'failed'
+   fi
+   fi
+}
+# catch manual interrupt to ignore notification
+trap "signal=INT ; trap - INT ; kill -INT $$" INT
+# notify result on exit
+trap on_exit EXIT
+
+cd $(dirname $(readlink -m $0))/..
+
+config () #   
+{
+   if [ ! -e $1/.config ] ; then
+   echo Custom configuration
+   make T=$2 O=$1 config
+   echo $3 | grep -q next || \
+   sed -ri   's,(NEXT_ABI=)y,\1n,' $1/.config
+   ! echo $3 | grep -q shared || \
+   sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
+   ! echo $3 | grep -q combined || \
+   sed -ri   's,(COMBINE_LIBS=)n,\1y,' $1/.config
+   echo $2 | grep -q '^i686' || \
+   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$' || \
+   echo $3 | grep -q 'shared.*combined' || \
+   sed -ri   's,(MLX4_PMD=)n,\1y,' $1/.config
+   test "$DPDK_DEP_SZE" != y || \
+   echo $2 | grep -q '^i686' || \
+   sed -ri 

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

[Thomas Monjalon]

This script can be used to call checkpatch.pl from Linux with some
custom DPDK options.

The path to the original Linux script must be set in an environment
variable. A script is added to load any configuration variables
required by development tools from a file .develconfig, or
~/.config/dpdk/devel.config or /etc/dpdk/devel.config.

Signed-off-by: Thomas Monjalon 
---
v2:
- do not ignore COMPLEX_MACRO
- use option --no-tree to avoid silent failure
- add -q and -v options

 scripts/checkpatches.sh  | 82 
 scripts/load-devel-config.sh | 14 
 2 files changed, 96 insertions(+)
 create mode 100755 scripts/checkpatches.sh
 create mode 100755 scripts/load-devel-config.sh

diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
new file mode 100755
index 000..afc611b
--- /dev/null
+++ b/scripts/checkpatches.sh
@@ -0,0 +1,82 @@
+#! /bin/sh
+
+# BSD LICENSE
+#
+# Copyright 2015 6WIND S.A.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+#   * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+#   * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+#   * Neither the name of 6WIND S.A. nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+# Load config options:
+# - DPDK_CHECKPATCH_PATH
+# - DPDK_CHECKPATCH_LINE_LENGTH
+. scripts/load-devel-config.sh
+if [ ! -x "$DPDK_CHECKPATCH_PATH" ] ; then
+   echo 'Cannot execute DPDK_CHECKPATCH_PATH' >&2
+   exit 1
+fi
+
+length=${DPDK_CHECKPATCH_LINE_LENGTH:-80}
+
+# override default Linux options
+options="--no-tree"
+options="$options --max-line-length=$length"
+options="$options --show-types"
+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"
+
+print_usage () {
+   echo "usage: $(basename $0) [-q] [-v] [patch1 [patch2] ...]]"
+}
+
+quiet=false
+verbose=false
+while getopts hqv ARG ; do
+   case $ARG in
+   q ) quiet=true ;;
+   v ) verbose=true ;;
+   h ) print_usage ; exit 0 ;;
+   ? ) print_usage ; exit 1 ;;
+   esac
+done
+shift $(($OPTIND - 1))
+
+status=0
+for p in "$@" ; do
+   ! $verbose || printf '\n### %s\n\n' "$p"
+   report=$($DPDK_CHECKPATCH_PATH $options "$p" 2>/dev/null)
+   [ $? -ne 0 ] || continue
+   $verbose || printf '\n### %s\n\n' "$p"
+   printf '%s\n' "$report" | head -n -6
+   status=$(($status + 1))
+done
+pass=$(($# - $status))
+$quiet || printf '%d/%d valid patch' $pass $#
+$quiet || [ $pass -le 1 ] || printf 'es'
+$quiet || printf '\n'
+exit $status
diff --git a/scripts/load-devel-config.sh b/scripts/load-devel-config.sh
new file mode 100755
index 000..489f007
--- /dev/null
+++ b/scripts/load-devel-config.sh
@@ -0,0 +1,14 @@
+#! /bin/echo must be loaded with .
+
+# Load DPDK devel config and allow override
+# from system file
+test ! -r /etc/dpdk/devel.config ||
+. /etc/dpdk/devel.config
+# from user file
+test ! -r ~/.config/dpdk/devel.config ||
+. ~/.config/dpdk/devel.config
+# from local file
+test ! -r $(dirname $(readlink -m $0))/../.develconfig ||
+. $(dirname $(readlink -m $0))/../.develconfig
+
+# The config files must export variables in the shell style
-- 
2.5.2

[dpdk-dev] [PATCH v2 0/2] more basic tests

[Thomas Monjalon]

I use some scripts to make some basic checks before committing or
submitting some patches.
As they can be useful for every DPDK developers and especially for
new committers / tree owners, they are added to the scripts directory.

The problem, when sharing such tools, is how to make them customizable
while fitting for everyone. The proposed solution is to use a
development configuration file.

Thomas Monjalon (2):
  scripts: add checkpatch wrapper
  scripts: add build tests

 scripts/checkpatches.sh  |  82 
 scripts/load-devel-config.sh |  14 +
 scripts/test-build.sh| 145 +++
 3 files changed, 241 insertions(+)
 create mode 100755 scripts/checkpatches.sh
 create mode 100755 scripts/load-devel-config.sh
 create mode 100755 scripts/test-build.sh

-- 
2.5.2

[dpdk-dev] OK to reindent the pktgen (mix of tabs and spaces, etc.)?

[Matthew Hall]

I would like to reindent it using the following astyle command, with a few 
small hand edits past that level, to get it closer to most other DPDK code as 
the inconsistent mix of tabs, spaces, etc. makes it difficult to read and 
debug when it has issues.

Obviously the upstream Lua and common/wr_* code would not be included as they 
seem to be copied from elsewhere w/ different upstream standards.

If I were to make the big diff needed for this, would this item be acceptable 
upstream?

Otherwise it is going to be hard to get more people working on the code 
reliably as it will be hard for others to follow besides the original authors.

astyle \
--max-code-length=132 \
--style=attach \
--break-closing-brackets \
--add-brackets \
--indent=force-tab=8 \
--indent-switches \
--indent-labels \
--indent-col1-comments \
--pad-oper \
--pad-header \
--unpad-paren \
--align-pointer=type \
--align-reference=type \
--suffix=none \
--lineend=linux \
./app/**/*.{c,h}

Sincerely,
Matthew.

[dpdk-dev] [PATCH RFC v2 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling

[Wang, Zhihong]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Saturday, November 21, 2015 12:33 AM
> To: Wang, Zhihong 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC v2 2/2] lib/librte_eal: Remove unnecessary
> hugepage zero-filling
> 
> On Thu, 19 Nov 2015 20:53:48 -0500
> Zhihong Wang  wrote:
> 
> > The kernel fills new allocated (huge) pages with zeros.
> > DPDK just has to touch the pages to trigger the allocation.
> >
> > Signed-off-by: Zhihong Wang 
> 
> The code is correct, and optimized.
> Don't you need to update the commit message since you no longer have to touch
> the pages.

Thanks for pointing this out!

[dpdk-dev] [PATCH RFC v2 1/2] lib/librte_eal: Reduce timer initialization time

[Wang, Zhihong]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Saturday, November 21, 2015 12:32 AM
> To: Wang, Zhihong 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC v2 1/2] lib/librte_eal: Reduce timer
> initialization time
> 
> On Thu, 19 Nov 2015 20:53:47 -0500
> Zhihong Wang  wrote:
> 
> > +   struct timespec sleeptime = {.tv_nsec = 1E8 }; /* 1/10 second */
> 
> Why not NSEC_PER_SEC / 10

Yes, it looks better using macro :)

[dpdk-dev] missing __rte_deprecated on rte_eth_stats.imcasts ?

[Thomas Monjalon]

2015-11-22 18:53, Matthew Hall:
> I was reading through the deprecations in rte_eth_stats to see if I could fix 
> the pktgen. Of course many fields were marked with __rte_deprecated .
> 
> However I found this one field which said deprecated in its comment, but it 
> lacked __rte_deprecated .

When setting the __rte_deprecated attribute, Stephen wanted to keep imcasts:
http://dpdk.org/dev/patchwork/patch/8732/

> Is the comment wrong, or is the field definition wrong, or did I miss 
> something?

We have to decide if we really want to deprecate it.
I think we should set the deprecated attribute and it seems agreed.

> uint64_t imcasts;
> /**< Deprecated; Total number of multicast received packets. */

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

[Thomas Monjalon]

2015-11-22 18:25, Matthew Hall:
> On Sun, Nov 22, 2015 at 09:59:30PM +0100, Thomas Monjalon wrote:
> > > So again I am confused what advantage we got from RTE_NEXT_ABI here, and 
> > > how 
> > > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a 
> > > binary variable.
> > 
> > I don't understand what is not clear here.
> 
> OK. Let me restate it.
> 
> I was starting from an assumption that the purpose of RTE_NEXT_ABI was to 
> allow ABI changes.

Yes it is a preview. The next release will have only the new ABI without #ifdef.

> In most projects I worked on, a renaming of a variable when the data type is 
> unchanged does not count as an ABI change. So it seems like this is different 
> from the usual definition.

No, it is not an ABI change.
As I said previously, the change is in the mbuf ABI.
So in the example app, the 2 ABIs are used with #ifdef.

> Secondly, if one is making an ABI change, like I was, to some code which was 
> already changed once using RTE_NEXT_ABI, which part of the code do you change?

If your change is sent upstream, you must rely on the new ABI because the old 
one
will be removed when your change will be integrated.
If it is a local change, it depends on which ABI you want to use.

> Do you make a third copy different from the first two copies? If you make a 
> third copy, but RTE_NEXT_ABI is binary (i.e. it has two values, on and off) 
> then what labeling do you apply to the third copy?
> 
> If you don't make a third copy, I am assuming you edit the copy marked with 
> RTE_NEXT_ABI. But then what happens to a downstream user who wants to have 
> RTE_NEXT_ABI with the first ABI change, and not your second ABI change?

In each release, there is only 2 ABIs: current and next.
In 2.2, there is only 1 ABI.

> Can you see what I am trying to ask now?

Yes. Hope my detailed answer is enough.