[dpdk-dev] [PATCH] testpmd: Fix segment fault when port ID greater than 76

[Michael Qiu]

In testpmd, when using "rx_vlan add 1 77", it will be a segment fault
Because the port ID should be less than 32.

Signed-off-by: Michael Qiu 
---
 app/test-pmd/config.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 1d29146..cf2aa6e 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -388,7 +388,7 @@ port_id_is_invalid(portid_t port_id, enum print_warning 
warning)
if (port_id == (portid_t)RTE_PORT_ALL)
return 0;

-   if (ports[port_id].enabled)
+   if (port_id < RTE_MAX_ETHPORTS && ports[port_id].enabled)
return 0;

if (warning == ENABLED_WARN)
-- 
1.9.3

[dpdk-dev] [PATCH] eal: fix build

[Helin Zhang]

It fixes the build error of implicit declaration of function.

Signed-off-by: Helin Zhang 
---
 lib/librte_eal/common/include/rte_pci.h | 11 +++
 lib/librte_eal/linuxapp/eal/eal_pci.c   |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index 34cafa6..3fb2d3a 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -487,6 +487,17 @@ int rte_eal_pci_read_config(const struct rte_pci_device 
*device,
 int rte_eal_pci_write_config(const struct rte_pci_device *device,
 const void *buf, size_t len, off_t offset);

+#ifdef RTE_PCI_CONFIG
+/**
+ * Set special config space registers for performance purpose.
+ *
+ * @param dev
+ *   A pointer to a rte_pci_device structure describing the device
+ *   to use
+ */
+void pci_config_space_set(struct rte_pci_device *dev);
+#endif /* RTE_PCI_CONFIG */
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index df21846..0e62f65 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -557,7 +557,7 @@ pci_config_max_read_request_size(struct rte_pci_device *dev)
return 0;
 }

-static void
+void
 pci_config_space_set(struct rte_pci_device *dev)
 {
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
-- 
1.9.3

[dpdk-dev] [PATCH v3] i40evf: fix crash when setup tx queues on vf port

[Jingjing Wu]

This patch fixes the issue:
Testpmd crashed with Segmentation fault when setup tx queues on vf
Steps for reproduce:
  - create one vf device from i40e driver
  - bind vf device to igb_uio and start testpmd

With debugging tools, we saw the struct i40e_vf is cleared after
memcpy(&dev->data->dev_conf, dev_conf, sizeof(dev->data->dev_conf)) in
rte_eth_dev_configure, which should not happen, and the pointer to
i40e_vf isn't in the range of i40e_adapter.

The root cause is the dev_private_size in i40e virtual function driver struct
rte_i40evf_pmd was set incorrectly.

Signed-off-by: Jingjing Wu 
---
v2 changes:
  rework the patch's title and commit log.
V3 changes:
  fix name in Signed-off-by.

 drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index f3470e6..b694400 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1248,7 +1248,7 @@ static struct eth_driver rte_i40evf_pmd = {
},
.eth_dev_init = i40evf_dev_init,
.eth_dev_uninit = i40evf_dev_uninit,
-   .dev_private_size = sizeof(struct i40e_vf),
+   .dev_private_size = sizeof(struct i40e_adapter),
 };

 /*
-- 
2.4.0

[dpdk-dev] [PATCH] test-pmd: show pci address in port info

[Michael Qiu]

pci address is one important info for port.
This patch make it visible for port info.

Signed-off-by: Michael Qiu 
---
 app/test-pmd/config.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 1d29146..c7db5bc 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -297,6 +297,8 @@ port_infos_display(portid_t port_id)
 {
struct rte_port *port;
struct ether_addr mac_addr;
+   struct rte_pci_addr *addr = NULL;
+   char pci_addr[13] = ":00:00.0";
struct rte_eth_link link;
struct rte_eth_dev_info dev_info;
int vlan_offload;
@@ -317,6 +319,17 @@ port_infos_display(portid_t port_id)
   info_border, port_id, info_border);
rte_eth_macaddr_get(port_id, &mac_addr);
print_ethaddr("MAC address: ", &mac_addr);
+   if (port->dev_info.pci_dev) {
+   addr = &port->dev_info.pci_dev->addr;
+   sprintf(pci_addr, "%04x:%02x:%02x.%01x",
+   addr->domain, addr->bus, addr->devid, addr->function);
+   }
+
+   if (strncmp(":00:00.0", pci_addr, 12))
+   printf("\nPCI address: %s", pci_addr);
+   else
+   printf("\nPCI address: N/A");
+
printf("\nConnect to socket: %u", port->socket_id);

if (port_numa[port_id] != NUMA_NO_CONFIG) {
-- 
1.9.3

[dpdk-dev] [PATCH] bnx2x: fix undeclared PAGE_SIZE build error

[Tony Lu]

>-Original Message-
>From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>Sent: Tuesday, July 28, 2015 5:18 PM
>To: Zhigang Lu
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH] bnx2x: fix undeclared PAGE_SIZE build error
>
>2015-07-28 16:48, Zhigang Lu:
>> This patch fixes a build error caused by undeclared PAGE_SIZE when
>> compiling for non-X86 arches. On some arches, PAGE_SIZE is not fixed
>> so that header files do not define it.  A better way to get it is via
>> sysconf(3) or getpagesize(2).
>>
>> Fixes: 540a211084a7 ("bnx2x: driver core")
>
>Thanks for fixing it.
>
>> +#define PAGE_SIZE (sysconf(_SC_PAGESIZE))
>
>To avoid conflict with system headers, it would be better to prefix the
constant.
>Ideally, we should add RTE_PAGESIZE in EAL and cleanup every usage of
>sysconf(_SC_PAGESIZE) and getpagesize.

Agree, good idea.

[dpdk-dev] [PATCHv2 0/2] ixgbe: Two fixes for RX scatter functions.

[Lu, Wenzhuo]

Hi,
Acked-by: Wenzhuo Lu 

[dpdk-dev] [PATCH v1 1/1] ixgbe: Fix oerrors by setting it to 0

[Lu, Wenzhuo]

Hi,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maryam Tahhan
> Sent: Tuesday, July 28, 2015 11:38 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v1 1/1] ixgbe: Fix oerrors by setting it to 0
> 
> Fix afebc86be1346136125af8026dc215f81c202c50. oerrors was txdgpc -
> hw_stats->gptc, txdgpc is the number of packets DMA'ed by the host and was
> being reset on every call to read stats so it could be < gptc.
> Because we currently have no way to add txdgpc to struct hw_stats so that we
> can maintain a persistent value per port oerrors has now been set to 0.
> References to txdgpc is now removed as we don't use it. This patch also
> removes rxnfgpc as it's not used anywhere.
> 
> Signed-off-by: Maryam Tahhan 
Acked-by: Wenzhuo Lu 

[dpdk-dev] [PATCH] app test: fix mempool cache_size not match limited cache_size

[Yong Liu]

From: Marvin Liu 

In previous setting, mempool size and cache_size are both 32.
This is not satisfied with cache_size checking rule by now.
Cache size should less than CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE and mempool size 
/ 1.5.

Signed-off-by: Marvin Liu 

diff --git a/app/test/test_sched.c b/app/test/test_sched.c
index 1ef6910..7a38db3 100644
--- a/app/test/test_sched.c
+++ b/app/test/test_sched.c
@@ -87,7 +87,7 @@ static struct rte_sched_port_params port_param = {

 #define NB_MBUF  32
 #define MBUF_DATA_SZ (2048 + RTE_PKTMBUF_HEADROOM)
-#define PKT_BURST_SZ 32
+#define PKT_BURST_SZ 0
 #define MEMPOOL_CACHE_SZ PKT_BURST_SZ
 #define SOCKET   0

-- 
1.9.3

[dpdk-dev] [PATCH] app test: fix eal --no-huge option should work with -m option

[Yong Liu]

From: Marvin Liu 

'--no-huge' option now can workable with -m option.
Unit test for eal flag should change pass criterion.

Signed-off-by: Marvin Liu 

diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 0352f87..e6f7035 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -748,8 +748,8 @@ test_no_hpet_flag(void)
 }

 /*
- * Test that the app runs with --no-huge and doesn't run when either
- * -m or --socket-mem are specified with --no-huge.
+ * Test that the app runs with --no-huge and doesn't run when --socket-mem are
+ * specified with --no-huge.
  */
 static int
 test_no_huge_flag(void)
@@ -778,8 +778,8 @@ test_no_huge_flag(void)
printf("Error - process did not run ok with --no-huge flag\n");
return -1;
}
-   if (launch_proc(argv2) == 0) {
-   printf("Error - process run ok with --no-huge and -m flags\n");
+   if (launch_proc(argv2) != 0) {
+   printf("Error - process did not run ok with --no-huge and -m 
flags\n");
return -1;
}
 #ifdef RTE_EXEC_ENV_BSDAPP
-- 
1.9.3

[dpdk-dev] [PATCH] app test: fix eal --no-huge option should work with -m option

[Yong Liu]

From: Marvin Liu 

'--no-huge' option now can workable with -m option.
Unit test for eal flag should change pass criterion.

Signed-off-by: Marvin Liu 

diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 0352f87..e6f7035 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -748,8 +748,8 @@ test_no_hpet_flag(void)
 }

 /*
- * Test that the app runs with --no-huge and doesn't run when either
- * -m or --socket-mem are specified with --no-huge.
+ * Test that the app runs with --no-huge and doesn't run when --socket-mem are
+ * specified with --no-huge.
  */
 static int
 test_no_huge_flag(void)
@@ -778,8 +778,8 @@ test_no_huge_flag(void)
printf("Error - process did not run ok with --no-huge flag\n");
return -1;
}
-   if (launch_proc(argv2) == 0) {
-   printf("Error - process run ok with --no-huge and -m flags\n");
+   if (launch_proc(argv2) != 0) {
+   printf("Error - process did not run ok with --no-huge and -m 
flags\n");
return -1;
}
 #ifdef RTE_EXEC_ENV_BSDAPP
-- 
1.9.3

[dpdk-dev] [PATCH v6] Add toeplitz hash algorithm used by RSS

[Qiu, Michael]

Hi, Vladimir

You need also to fix this issue in i686 platform:

RHEL65_32,2.6.32,4.4.7,14.0.0
SUSE11SP3_32,3.0.76-0,4.3.4,14.0.0


i686-native-linuxapp-gcc/include/rte_thash.h:63: error: integer constant is too 
large for 'long' type
i686-native-linuxapp-gcc/include/rte_thash.h:63: error: integer constant is too 
large for 'long' type


Thanks,
Michael
On 2015/7/27 4:58, Vladimir Medvedkin wrote:

Hi Tony,

Sorry for the late reply, I was on vacation.
I'll prepare patch soon.

Regards,
Vladimir

2015-07-22 10:55 GMT+03:00 Tony Lu :



Hi, Vladimir

When compiling thash for no-X86 arches, it fails with the following errors.
I wonder if
it is possible to make the thash library arch-independent?

== Build app/test
  CC test_thash.o
In file included from /u/zlu.bjg/git/dpdk.org/app/test/test_thash.c:40:
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:56:22
:
error: rte_vect.h: No such file or directory
In file included from /u/zlu.bjg/git/dpdk.org/app/test/test_thash.c:40:
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:62:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'rte_thash_ipv6_bswap_mask'
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:129:
error: requested alignment is not a constant
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h: In
function 'rte_thash_load_v6_addrs':
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:160:
error: '__m128i' undeclared (first use in this function)
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:160:
error: (Each undeclared identifier is reported only once
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:160:
error: for each function it appears in.)
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:160:
error: expected ';' before 'ipv6'
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:161:
error: expected expression before ')' token
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
error: 'ipv6' undeclared (first use in this function)
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
warning: implicit declaration of function '_mm_loadu_si128'
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
warning: nested extern declaration of '_mm_loadu_si128'
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
error: expected ')' before '__m128i'
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
warning: type defaults to 'int' in declaration of 'type name'
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
warning: cast from pointer to integer of different size
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:164:
error: expected expression before ')' token
/u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:158:
warning: unused parameter 'targ'
make[3]: *** [test_thash.o] Error 1
make[2]: *** [test] Error 2
make[1]: *** [app] Error 2
make: *** [all] Error 2

Thanks
-Zhigang Lu



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Vladimir Medvedkin
Sent: Wednesday, July 01, 2015 7:40 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v6] Add toeplitz hash algorithm used by RSS

Software implementation of the Toeplitz hash function used by RSS.
Can be used either for packet distribution on single queue NIC or for


simulating


of RSS computation on specific NIC (for example after GRE header
decapsulating).

v6 changes
- Fix compilation error
- Rename some defines and function

v5 changes
- Fix errors reported by checkpatch.pl

v4 changes
- Fix copyright
- rename bswap_mask constant, add rte_ prefix
- change rte_ipv[46]_tuple struct
- change rte_thash_load_v6_addr prototype

v3 changes
- Rework API to be more generic
- Add sctp_tag into tuple

v2 changes
- Add ipv6 support
- Various style fixes

Signed-off-by: Vladimir Medvedkin 
---
lib/librte_hash/Makefile|   1 +
lib/librte_hash/rte_thash.h | 231

2 files changed, 232 insertions(+)
create mode 100644 lib/librte_hash/rte_thash.h

diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile index
3696cb1..981230b 100644
--- a/lib/librte_hash/Makefile
+++ b/lib/librte_hash/Makefile
@@ -49,6 +49,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_HASH) += rte_fbk_hash.c
SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include := rte_hash.h
SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_hash_crc.h
SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_jhash.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_thash.h
SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_fbk_hash.h

# this lib needs eal
diff --git a/lib/librte_hash/rte_thash.h b/lib/librte_hash/rte_thash.h new


file


mode 100644 index 000..1808f47
--- /dev/null
+++ b/lib/librte

[dpdk-dev] [PATCH v4] ixgbe: fix data access on big endian cpu.

[xuelin....@freescale.com]

From: Xuelin Shi 

1. cpu use data owned by ixgbe must use rte_le_to_cpu_xx(...)
2. cpu fill data to ixgbe must use rte_cpu_to_le_xx(...)
3. checking pci status with converted constant

Signed-off-by: Xuelin Shi 
---
changes for v4:
  fix compiling error: cpu16 to cpu_16
  fix issues reported by checkpatch

 drivers/net/ixgbe/ixgbe_rxtx.c | 78 --
 1 file changed, 52 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index a7c94a9..f904b40 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -130,7 +130,7 @@ ixgbe_tx_free_bufs(struct ixgbe_tx_queue *txq)

/* check DD bit on threshold descriptor */
status = txq->tx_ring[txq->tx_next_dd].wb.status;
-   if (! (status & IXGBE_ADVTXD_STAT_DD))
+   if (!(status & rte_cpu_to_le_32(IXGBE_ADVTXD_STAT_DD)))
return 0;

/*
@@ -175,11 +175,14 @@ tx4(volatile union ixgbe_adv_tx_desc *txdp, struct 
rte_mbuf **pkts)
pkt_len = (*pkts)->data_len;

/* write data to descriptor */
-   txdp->read.buffer_addr = buf_dma_addr;
+   txdp->read.buffer_addr = rte_cpu_to_le_64(buf_dma_addr);
+
txdp->read.cmd_type_len =
-   ((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
+   rte_cpu_to_le_32((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
+
txdp->read.olinfo_status =
-   (pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
+   rte_cpu_to_le_32(pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
+
rte_prefetch0(&(*pkts)->pool);
}
 }
@@ -195,11 +198,14 @@ tx1(volatile union ixgbe_adv_tx_desc *txdp, struct 
rte_mbuf **pkts)
pkt_len = (*pkts)->data_len;

/* write data to descriptor */
-   txdp->read.buffer_addr = buf_dma_addr;
+   txdp->read.buffer_addr = rte_cpu_to_le_64(buf_dma_addr);
+
txdp->read.cmd_type_len =
-   ((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
+   rte_cpu_to_le_32((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
+
txdp->read.olinfo_status =
-   (pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
+   rte_cpu_to_le_32(pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
+
rte_prefetch0(&(*pkts)->pool);
 }

@@ -511,6 +517,7 @@ ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq)
uint16_t nb_tx_desc = txq->nb_tx_desc;
uint16_t desc_to_clean_to;
uint16_t nb_tx_to_clean;
+   uint32_t stat;

/* Determine the last descriptor needing to be cleaned */
desc_to_clean_to = (uint16_t)(last_desc_cleaned + txq->tx_rs_thresh);
@@ -519,7 +526,9 @@ ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq)

/* Check to make sure the last descriptor to clean is done */
desc_to_clean_to = sw_ring[desc_to_clean_to].last_id;
-   if (! (txr[desc_to_clean_to].wb.status & IXGBE_TXD_STAT_DD))
+
+   stat = txr[desc_to_clean_to].wb.status;
+   if (!(stat & rte_cpu_to_le_32(IXGBE_TXD_STAT_DD)))
{
PMD_TX_FREE_LOG(DEBUG,
"TX descriptor %4u is not done"
@@ -806,12 +815,14 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
 */
slen = m_seg->data_len;
buf_dma_addr = RTE_MBUF_DATA_DMA_ADDR(m_seg);
+
txd->read.buffer_addr =
rte_cpu_to_le_64(buf_dma_addr);
txd->read.cmd_type_len =
rte_cpu_to_le_32(cmd_type_len | slen);
txd->read.olinfo_status =
rte_cpu_to_le_32(olinfo_status);
+
txe->last_id = tx_last;
tx_id = txe->next_id;
txe = txn;
@@ -1062,14 +1073,16 @@ ixgbe_rx_scan_hw_ring(struct ixgbe_rx_queue *rxq)
int s[LOOK_AHEAD], nb_dd;
 #endif /* RTE_NEXT_ABI */
int i, j, nb_rx = 0;
+   uint32_t stat;


/* get references to current descriptor and S/W ring entry */
rxdp = &rxq->rx_ring[rxq->rx_tail];
rxep = &rxq->sw_ring[rxq->rx_tail];

+   stat = rxdp->wb.upper.status_error;
/* check to make sure there is at least 1 packet to receive */
-   if (! (rxdp->wb.upper.status_error & IXGBE_RXDADV_STAT_DD))
+   if (!(stat & rte_cpu_to_le_32(IXGBE_RXDADV_STAT_DD)))
return 0;

/*
@@ -1081,7 +1094,7 @@ ixgbe_rx_scan_hw_ring(struct ixgbe_rx_queue *rxq)
{
/* Read desc statuses backwards to avoid race condition */
for (j = LOOK_AHEAD-1; j >= 0; --j)
-   s[j] = rxdp[j].wb.upper.status_error;
+   s[j] = rte_le_to_cpu_32(rxdp[j].wb.upper.status_error);

 #ifdef RTE_NEXT_ABI
for (j = LOOK_AHEAD - 1; j >= 0; -

[dpdk-dev] [PATCH v4] enforce rules of the cpu and ixgbe exchange data.

[Xuelin Shi]

Hi Thomas & Konstantin,

Thanks for the review and the comments are addressed by 
http://www.dpdk.org/dev/patchwork/patch/6653/

Best Regards,
Xuelin Shi

> -Origina Konstantin l Message-
> From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com]
> Sent: Monday, July 27, 2015 22:43
> To: Thomas Monjalon
> Cc: Shi Xuelin-B29237; dev at dpdk.org
> Subject: RE: [PATCH v4] enforce rules of the cpu and ixgbe exchange data.
> 
> 
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Monday, July 27, 2015 3:18 PM
> > To: Ananyev, Konstantin
> > Cc: xuelin.shi at freescale.com; dev at dpdk.org
> > Subject: Re: [PATCH v4] enforce rules of the cpu and ixgbe exchange
> data.
> >
> > A quick review of this long pending patch would be great.
> > Thanks
> 
> Well, it doesn't compile:
> 
> /local/kananye1/dpdk.org-ixgbevfix2-tst1/drivers/net/ixgbe/ixgbe_rxtx.c:
> In function ?ixgbe_rx_scan_hw_ring?:
> /local/kananye1/dpdk.org-ixgbevfix2-
> tst1/drivers/net/ixgbe/ixgbe_rxtx.c:1114:4: error: implicit declaration
> of function ?rte_le_to_cpu16? [-Werror=implicit-function-declaration]
> pkt_len = rte_le_to_cpu16(rxdp[j].wb.upper.length) -
> ^
> /local/kananye1/dpdk.org-ixgbevfix2-
> tst1/drivers/net/ixgbe/ixgbe_rxtx.c:1114:4: error: nested extern
> declaration of ?rte_le_to_cpu16? [-Werror=nested-externs]
> 
> 
> Should be rte_le_to_cpu_16(), I believe.
> 
> And checkpatch.pl complains on it:
> 
> WARNING: line over 80 characters
> #151: FILE: drivers/net/ixgbe/ixgbe_rxtx.c:1133:
> +
> + rte_le_to_cpu_32(rxdp[j].wb.lower.lo_dword.data));
> 
> ERROR: code indent should use tabs where possible
> #170: FILE: drivers/net/ixgbe/ixgbe_rxtx.c:1147:
> +^I^I^I ^Irxdp[j].wb.lower.hi_dword.csum_ip.csum) &$
> 
> WARNING: please, no space before tabs
> #170: FILE: drivers/net/ixgbe/ixgbe_rxtx.c:1147:
> +^I^I^I ^Irxdp[j].wb.lower.hi_dword.csum_ip.csum) &$
> 
> total: 1 errors, 2 warnings, 192 lines checked
> 
> Apart from that, looks harmless :)
> 
> Konstantin
> 
> >
> > 2015-07-16 14:45, xuelin.shi at freescale.com:
> > > From: Xuelin Shi 
> > >
> > > 1. cpu use data owned by ixgbe must use rte_le_to_cpu_xx(...) 2. cpu
> > > fill data to ixgbe must use rte_cpu_to_le_xx(...) 3. checking pci
> > > status with converted constant.
> > >
> > > Signed-off-by: Xuelin Shi 

[dpdk-dev] [PATCH] eal: fix build

[Thomas Monjalon]

2015-07-29 06:48, Helin Zhang:
> It fixes the build error of implicit declaration of function.

What is the error?
Please show the build log and describe the case when it happens
(compiler, version).

[dpdk-dev] [PATCH] lpm: fix extended flag check when adding a "depth small" entry

[Liang, Cunming]

On 7/28/2015 5:14 PM, Zhe Tao wrote:
> When adding a "depth small" entry, if its extended flag is not set
> and its depth is smaller than the one in the tbl24, nothing should
> be done otherwise will operate on the wrong memory area.
>
> Signed-off-by: Zhe Tao 
> ---
>   lib/librte_lpm/rte_lpm.c | 51 
> +---
>   1 file changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
> index de05307..0ef2421 100644
> --- a/lib/librte_lpm/rte_lpm.c
> +++ b/lib/librte_lpm/rte_lpm.c
> @@ -447,30 +447,33 @@ add_depth_small(struct rte_lpm *lpm, uint32_t ip, 
> uint8_t depth,
>   
>   continue;
>   }
> -
> - /* If tbl24 entry is valid and extended calculate the index
> -  * into tbl8. */
> - tbl8_index = lpm->tbl24[i].tbl8_gindex *
> - RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
> - tbl8_group_end = tbl8_index + RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
> -
> - for (j = tbl8_index; j < tbl8_group_end; j++) {
> - if (!lpm->tbl8[j].valid ||
> - lpm->tbl8[j].depth <= depth) {
> - struct rte_lpm_tbl8_entry new_tbl8_entry = {
> - .valid = VALID,
> - .valid_group = VALID,
> - .depth = depth,
> - .next_hop = next_hop,
> - };
> -
> - /*
> -  * Setting tbl8 entry in one go to avoid race
> -  * conditions
> -  */
> - lpm->tbl8[j] = new_tbl8_entry;
> -
> - continue;
> +
> + if (lpm->tbl24[i].ext_entry == 1) {
> +
> + /* If tbl24 entry is valid and extended calculate the 
> index
> +  * into tbl8. */
One minor comment on the format. Some lines are over 80 characters and 
the blank line ahead of the comment is not required.
> + tbl8_index = lpm->tbl24[i].tbl8_gindex *
> + RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
> + tbl8_group_end = tbl8_index + 
> RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
> +
> + for (j = tbl8_index; j < tbl8_group_end; j++) {
> + if (!lpm->tbl8[j].valid ||
> + lpm->tbl8[j].depth <= depth) {
> + struct rte_lpm_tbl8_entry 
> new_tbl8_entry = {
> + .valid = VALID,
> + .valid_group = VALID,
> + .depth = depth,
> + .next_hop = next_hop,
> + };
> +
> + /*
> +  * Setting tbl8 entry in one go to 
> avoid race
> +  * conditions
> +  */
> + lpm->tbl8[j] = new_tbl8_entry;
> +
> + continue;
> + }
>   }
>   }
>   }

[dpdk-dev] [PATCH] test-pmd: show pci address in port info

[Thomas Monjalon]

2015-07-29 09:05, Michael Qiu:
> pci address is one important info for port.
> This patch make it visible for port info.
> 
> Signed-off-by: Michael Qiu 

Maybe you missed this thread:
http://dpdk.org/ml/archives/dev/2015-July/022107.html

> + if (strncmp(":00:00.0", pci_addr, 12))
> + printf("\nPCI address: %s", pci_addr);
> + else
> + printf("\nPCI address: N/A");

Checking a null PCI address to handle non-pci devices is ugly.
EAL must be reworked to correctly handle non-PCI devices.
Patches welcome.

This patch is rejected.

[dpdk-dev] [PATCH v1 1/1] ixgbe: Fix oerrors by setting it to 0

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maryam Tahhan
> Sent: Tuesday, July 28, 2015 4:38 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v1 1/1] ixgbe: Fix oerrors by setting it to 0
> 
> Fix afebc86be1346136125af8026dc215f81c202c50. oerrors was txdgpc -
> hw_stats->gptc, txdgpc is the number of packets DMA'ed by the host
> and was being reset on every call to read stats so it could be < gptc.
> Because we currently have no way to add txdgpc to struct hw_stats so
> that we can maintain a persistent value per port oerrors has now been
> set to 0. References to txdgpc is now removed as we don't use it. This
> patch also removes rxnfgpc as it's not used anywhere.
> 

Acked-by: Konstantin Ananyev 

> Signed-off-by: Maryam Tahhan 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 17 +++--
>  1 file changed, 3 insertions(+), 14 deletions(-)
> 

[dpdk-dev] [PATCH v4] ixgbe: fix data access on big endian cpu.

[Ananyev, Konstantin]

> -Original Message-
> From: xuelin.shi at freescale.com [mailto:xuelin.shi at freescale.com]
> Sent: Wednesday, July 29, 2015 7:38 AM
> To: Ananyev, Konstantin
> Cc: thomas.monjalon at 6wind.com; dev at dpdk.org; Xuelin Shi
> Subject: [PATCH v4] ixgbe: fix data access on big endian cpu.
> 
> From: Xuelin Shi 
> 
> 1. cpu use data owned by ixgbe must use rte_le_to_cpu_xx(...)
> 2. cpu fill data to ixgbe must use rte_cpu_to_le_xx(...)
> 3. checking pci status with converted constant
> 
> Signed-off-by: Xuelin Shi 

Acked-by: Konstantin Ananyev 

> ---
> changes for v4:
>   fix compiling error: cpu16 to cpu_16
>   fix issues reported by checkpatch
> 
>  drivers/net/ixgbe/ixgbe_rxtx.c | 78 
> --
>  1 file changed, 52 insertions(+), 26 deletions(-)
> 

[dpdk-dev] Failed to compile the dpdk on FreeBSD10.1

[Fan, ChangruX]

Hi Stephen,


  When I compile the newest dpdk, I meet these error info. Please check.


[root at dpdk-test36 ~/dpdk]# gmake install T=x86_64-native-bsdapp-gcc CC=gcc48

== Installing x86_64-native-bsdapp-gcc Configuration done == 
Build lib == Build lib/librte_compat

  SYMLINK-FILE include/rte_compat.h

== Build lib/librte_eal

== Build lib/librte_eal/common

  SYMLINK-FILE include/generic/rte_atomic.h

  SYMLINK-FILE include/generic/rte_byteorder.h

  SYMLINK-FILE include/generic/rte_cycles.h

  SYMLINK-FILE include/generic/rte_prefetch.h

  SYMLINK-FILE include/generic/rte_spinlock.h

  SYMLINK-FILE include/generic/rte_memcpy.h

  SYMLINK-FILE include/generic/rte_cpuflags.h

  SYMLINK-FILE include/generic/rte_rwlock.h

  SYMLINK-FILE include/rte_branch_prediction.h

  SYMLINK-FILE include/rte_common.h

  SYMLINK-FILE include/rte_debug.h

  SYMLINK-FILE include/rte_eal.h

  SYMLINK-FILE include/rte_errno.h

  SYMLINK-FILE include/rte_launch.h

  SYMLINK-FILE include/rte_lcore.h

  SYMLINK-FILE include/rte_log.h

  SYMLINK-FILE include/rte_memory.h

  SYMLINK-FILE include/rte_memzone.h

  SYMLINK-FILE include/rte_pci.h

  SYMLINK-FILE include/rte_pci_dev_ids.h

  SYMLINK-FILE include/rte_per_lcore.h

  SYMLINK-FILE include/rte_random.h

  SYMLINK-FILE include/rte_tailq.h

  SYMLINK-FILE include/rte_interrupts.h

  SYMLINK-FILE include/rte_alarm.h

  SYMLINK-FILE include/rte_string_fns.h

  SYMLINK-FILE include/rte_version.h

  SYMLINK-FILE include/rte_eal_memconfig.h

  SYMLINK-FILE include/rte_malloc_heap.h

  SYMLINK-FILE include/rte_hexdump.h

  SYMLINK-FILE include/rte_devargs.h

  SYMLINK-FILE include/rte_dev.h

  SYMLINK-FILE include/rte_pci_dev_feature_defs.h

  SYMLINK-FILE include/rte_pci_dev_features.h

  SYMLINK-FILE include/rte_malloc.h

  SYMLINK-FILE include/rte_byteorder.h

  SYMLINK-FILE include/rte_atomic.h

  SYMLINK-FILE include/rte_byteorder_64.h

  SYMLINK-FILE include/rte_cpuflags.h

  SYMLINK-FILE include/rte_rtm.h

  SYMLINK-FILE include/rte_atomic_64.h

  SYMLINK-FILE include/rte_byteorder_32.h

  SYMLINK-FILE include/rte_prefetch.h

  SYMLINK-FILE include/rte_vect.h

  SYMLINK-FILE include/rte_atomic_32.h

  SYMLINK-FILE include/rte_spinlock.h

  SYMLINK-FILE include/rte_cycles.h

  SYMLINK-FILE include/rte_memcpy.h

  SYMLINK-FILE include/rte_rwlock.h

== Build lib/librte_eal/bsdapp

== Build lib/librte_eal/bsdapp/eal

  CC eal.o

  CC eal_memory.o

  CC eal_hugepage_info.o

  CC eal_thread.o

  CC eal_log.o

  CC eal_pci.o

/root/dpdk/lib/librte_eal/bsdapp/eal/eal_pci.c: In function 
'rte_eal_pci_write_config':

/root/dpdk/lib/librte_eal/bsdapp/eal/eal_pci.c:453:15: error: cast discards 
'__attribute__((const))' qualifier from pointer target type [-Werror=cast-qual]

   .pi_data = *(u_int32_t *)buf,

   ^

/root/dpdk/lib/librte_eal/bsdapp/eal/eal_pci.c:462:2: error: passing argument 1 
of 'memcpy' makes pointer from integer without a cast [-Werror]

  memcpy(pi.pi_data, buf, len);

  ^

In file included from /root/dpdk/lib/librte_eal/bsdapp/eal/eal_pci.c:37:0:

/usr/include/string.h:62:7: note: expected 'void *' but argument is of type 
'u_int32_t'

void *memcpy(void * __restrict, const void * __restrict, size_t);

   ^

cc1: all warnings being treated as errors

/root/dpdk/mk/internal/rte.compile-pre.mk:126: recipe for target 'eal_pci.o' 
failed

gmake[7]: *** [eal_pci.o] Error 1

/root/dpdk/mk/rte.subdir.mk:61: recipe for target 'eal' failed

gmake[6]: *** [eal] Error 2

/root/dpdk/mk/rte.subdir.mk:61: recipe for target 'bsdapp' failed

gmake[5]: *** [bsdapp] Error 2

/root/dpdk/mk/rte.subdir.mk:61: recipe for target 'librte_eal' failed

gmake[4]: *** [librte_eal] Error 2

/root/dpdk/mk/rte.sdkbuild.mk:93: recipe for target 'lib' failed

gmake[3]: *** [lib] Error 2

/root/dpdk/mk/rte.sdkroot.mk:124: recipe for target 'all' failed

gmake[2]: *** [all] Error 2

/root/dpdk/mk/rte.sdkinstall.mk:58: recipe for target 
'x86_64-native-bsdapp-gcc_install' failed

gmake[1]: *** [x86_64-native-bsdapp-gcc_install] Error 2

/root/dpdk/mk/rte.sdkroot.mk:102: recipe for target 'install' failed

gmake: *** [install] Error 2



thanks

changru

[dpdk-dev] lost when learning how to test dpdk

[ciprian.barbu]

On 28.07.2015 21:13, Jan Viktorin wrote:
> Hello all,
>
> I am learning how to measure throughput with dpdk. I have 4 cores
> Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz and two 82545GM NICs connected
> together. I do not understand very well, how to setup testpmd.

http://dpdk.org/doc
http://dpdk.org/doc/guides/testpmd_app_ug/run_app.html
http://dpdk.org/doc/quick-start

>
> I've successfully bound the NICs to dpdk:
>
> $ dpdk_nic_bind --status
>
> Network devices using DPDK-compatible driver
> 
> :03:00.0 '82545GM Gigabit Ethernet Controller' drv=uio_pci_generic 
> unused=e1000
> :03:02.0 '82545GM Gigabit Ethernet Controller' drv=uio_pci_generic 
> unused=e1000
>
> Network devices using kernel driver
> ===
> :00:19.0 'Ethernet Connection I217-V' if=eno1 drv=e1000e 
> unused=uio_pci_generic *Active*
>
> Other network devices
> =
> 
>
> and then I tried to run testpmd:
>
> sudo ./testpmd -b :03:00.0 -b :03:02.0 -c 0xf -n2 -- --nb-cores=1 
> --nb-ports=0 --rxd=2048 --txd=2048 --mbcache=512 --burst=512

http://dpdk.org/doc/guides/testpmd_app_ug/run_app.html#testpmd-command-line-options

The -b option black lists your PCI devices, you don't need those. The 
--nb-ports is of course the number of ports, it cannot be 0.

> ...
> EAL: Ask a virtual area of 0x40 bytes
> EAL: Virtual area found at 0x7f154980 (size = 0x40)
> EAL: Requesting 1024 pages of size 2MB from socket 0
> EAL: TSC frequency is ~369 KHz
> EAL: Master lcore 0 is ready (tid=de94a8c0;cpuset=[0])
> EAL: lcore 2 is ready (tid=487fd700;cpuset=[2])
> EAL: lcore 3 is ready (tid=47ffc700;cpuset=[3])
> EAL: lcore 1 is ready (tid=48ffe700;cpuset=[1])
> EAL: No probed ethernet devices
> EAL: Error - exiting with code: 1
>Cause: Invalid port 0
>
> I tried --nb-ports={0,1,2} but neither of them works. BTW, what does this 
> option it mean? :)
> I could not find any description in the docs nor in the help (maybe I've 
> omitted something).
>
>
> Well, if I manage the testpmd to work I need a packet generator, right? I've 
> downloaded
> the dpdk-pktgen. And I am lost again. How can I start it?
>
> After several attempts (mostly trying to use the pktgen-master/slave.sh, what 
> is
> their purpose?), the most "successful" output was:
>
> ...
> EAL: Detected lcore 0 as core 0 on socket 03 handles port 1 rx & core 4 
> handles port 0-7 tx
> EAL: Detected lcore 1 as core 1 on socket 0 as it does not matter to the 
> syntax.
> EAL: Detected lcore 2 as core 0 on socket 0
> EAL: Detected lcore 3 as core 1 on socket 0p/app/x86_64-native-linuxapp-gcc 
> (master *%=)
> EAL: Support maximum 128 logical core(s) by configuration.
> EAL: Detected 4 lcore(s)
> EAL: No free hugepages reported in hugepages-2048kB

You either don't have hugepages or there aren't any free left.

> PANIC in rte_eal_init():
> Cannot get hugepage information
> 6: [./pktgen(_start+0x29) [0x41abc9]]
> 5: [/usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f93eadcc790]]
> 4: [./pktgen(main+0x140) [0x419d80]]
> 3: [./pktgen(rte_eal_init+0xd2b) [0x4bb8bb]]
> 2: [./pktgen(__rte_panic+0xc9) [0x419ae5]]
> 1: [./pktgen(rte_dump_stack+0x16) [0x4c3946]]
> Aborted (core dumped)
>
> I'd like to run a simple scenario, just sending packets from one NIC to the 
> other (or
> something similar) and measure the throughput. Could you please help me?
>
> Regards
> Jan Viktorin
>

[dpdk-dev] ixgbe vPMD RX functions and buffer number minimum requirement

[Zoltan Kiss]

Hi,

On 28/07/15 01:10, Ananyev, Konstantin wrote:
> Hi Zoltan,
>
>> -Original Message-
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Monday, July 27, 2015 12:38 PM
>> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
>> Subject: Re: [dpdk-dev] ixgbe vPMD RX functions and buffer number minimum 
>> requirement
>>
>> Hi Konstantin,
>>
>> Thanks! Another question I would have: why does _recv_raw_pkts_vec()
>> insist on (nb_pkts > RTE_IXGBE_VPMD_RX_BURST)? Looking at the code it
>> should be able to return packets when nb_pkts >=
>> RTE_IXGBE_DESCS_PER_LOOP.
>
> Yes, that seems pretty trivial modification.
> Don't know any good reason why it wasn't done that way.
>
>> The split_flags check in
>> ixgbe_recv_scattered_pkts_vec() would be a bit more complicated, and
>> therefore maybe would have a tiny performance overhead as well, but I
>> don't it would be anything serious.
>
> I think, if the performance wouldn't be affected, that will be really useful 
> change.
> So it is definitely worth to try.
> Probably even _recv_raw_pkts_vec() for first nb_pkts &  
> ~(RTE_IXGBE_VPMD_RX_BURST - 1),
> and then sort of scalar analog for the remainder.

Ok, I'll give it a go.
Another question, regarding performance: what setup you used to show a 
performance difference? I've tried to compare the vector function with 
the normal bulk alloc with receiving a 10 Gbps stream of 64 bytes UDP 
packets (and forward them out on the other port), but both yielded ~14 
Mpps. I have a i5-4570 CPU @ 3.20GHz, maybe I should limit the clock speed?

Regards,

Zoltan

> Konstantin
>
>>
>> Regards,
>>
>> Zoltan
>>
>>
>> On 24/07/15 17:43, Ananyev, Konstantin wrote:
>>> Hi Zoltan,
>>>
 -Original Message-
 From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
 Sent: Friday, July 24, 2015 4:00 PM
 To: Richardson, Bruce; dev at dpdk.org
 Subject: [dpdk-dev] ixgbe vPMD RX functions and buffer number minimum 
 requirement

 Hi,

 I was thinking how to handle the situation when you call
 rte_eth_rx_burst with less than RTE_IXGBE_VPMD_RX_BURST buffers. In
 ODP-DPDK unfortunately we can't force this requirement onto the calling
 application.
 One idea I had to check in ixgbe_recv_pkts_vec() if nb_pkts <
 RTE_IXGBE_VPMD_RX_BURST, and call ixgbe_recv_pkts_bulk_alloc in that
 case. Accordingly, in ixgbe_recv_scattered_pkts_vec() we could call
 ixgbe_recv_scattered_pkts() in this case. A branch predictor can easily
 eliminate the performance penalty of this, and applications can use
 whatever burst size feasible for them.
 The obvious problem could be whether you can mix the receive functions
 this way. I have a feeling it wouldn't fly, but I wanted to ask first
 before spending time investigate this option further.
>>>
>>> No, it is not possible to mix different RX functions, they setup/use 
>>> ixgbe_rx_queue
>>> fields in a different manner.
>>> Konstantin
>>>

 Regards,

 Zoltan

[dpdk-dev] ixgbe vPMD RX functions and buffer number minimum requirement

[Ananyev, Konstantin]

Hi Zoltan,

> -Original Message-
> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
> Sent: Wednesday, July 29, 2015 10:40 AM
> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] ixgbe vPMD RX functions and buffer number minimum 
> requirement
> 
> Hi,
> 
> On 28/07/15 01:10, Ananyev, Konstantin wrote:
> > Hi Zoltan,
> >
> >> -Original Message-
> >> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
> >> Sent: Monday, July 27, 2015 12:38 PM
> >> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] ixgbe vPMD RX functions and buffer number minimum 
> >> requirement
> >>
> >> Hi Konstantin,
> >>
> >> Thanks! Another question I would have: why does _recv_raw_pkts_vec()
> >> insist on (nb_pkts > RTE_IXGBE_VPMD_RX_BURST)? Looking at the code it
> >> should be able to return packets when nb_pkts >=
> >> RTE_IXGBE_DESCS_PER_LOOP.
> >
> > Yes, that seems pretty trivial modification.
> > Don't know any good reason why it wasn't done that way.
> >
> >> The split_flags check in
> >> ixgbe_recv_scattered_pkts_vec() would be a bit more complicated, and
> >> therefore maybe would have a tiny performance overhead as well, but I
> >> don't it would be anything serious.
> >
> > I think, if the performance wouldn't be affected, that will be really 
> > useful change.
> > So it is definitely worth to try.
> > Probably even _recv_raw_pkts_vec() for first nb_pkts &  
> > ~(RTE_IXGBE_VPMD_RX_BURST - 1),
> > and then sort of scalar analog for the remainder.
> 
> Ok, I'll give it a go.
> Another question, regarding performance: what setup you used to show a
> performance difference? I've tried to compare the vector function with
> the normal bulk alloc with receiving a 10 Gbps stream of 64 bytes UDP
> packets (and forward them out on the other port), but both yielded ~14
> Mpps. I have a i5-4570 CPU @ 3.20GHz, maybe I should limit the clock speed?

One port is not enough here if you are running @ 3.2 GHz.
For PMD - I personally use a box with 4x10G ports, one port per pci line,
run testpmd io fwd mode, all 4 ports over 1 core @ 2.8 GHz.
If you don't have similar box - let us know when you done with your changes,
we can give it a try.
Yes, reducing clock speed to minimal is another good option.
Though, I think just 1x10G port wouldn't be enough even for 1.2 GHz.
Probably 2x10G would do.
Konstantin



> 
> Regards,
> 
> Zoltan
> 
> > Konstantin
> >
> >>
> >> Regards,
> >>
> >> Zoltan
> >>
> >>
> >> On 24/07/15 17:43, Ananyev, Konstantin wrote:
> >>> Hi Zoltan,
> >>>
>  -Original Message-
>  From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>  Sent: Friday, July 24, 2015 4:00 PM
>  To: Richardson, Bruce; dev at dpdk.org
>  Subject: [dpdk-dev] ixgbe vPMD RX functions and buffer number minimum 
>  requirement
> 
>  Hi,
> 
>  I was thinking how to handle the situation when you call
>  rte_eth_rx_burst with less than RTE_IXGBE_VPMD_RX_BURST buffers. In
>  ODP-DPDK unfortunately we can't force this requirement onto the calling
>  application.
>  One idea I had to check in ixgbe_recv_pkts_vec() if nb_pkts <
>  RTE_IXGBE_VPMD_RX_BURST, and call ixgbe_recv_pkts_bulk_alloc in that
>  case. Accordingly, in ixgbe_recv_scattered_pkts_vec() we could call
>  ixgbe_recv_scattered_pkts() in this case. A branch predictor can easily
>  eliminate the performance penalty of this, and applications can use
>  whatever burst size feasible for them.
>  The obvious problem could be whether you can mix the receive functions
>  this way. I have a feeling it wouldn't fly, but I wanted to ask first
>  before spending time investigate this option further.
> >>>
> >>> No, it is not possible to mix different RX functions, they setup/use 
> >>> ixgbe_rx_queue
> >>> fields in a different manner.
> >>> Konstantin
> >>>
> 
>  Regards,
> 
>  Zoltan

[dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filtering

[Thomas Monjalon]

Back on this old patch, it seems justified but nobody agreed.

--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -1288,7 +1288,6 @@ virtio_dev_configure(struct rte_eth_dev *dev)
&& !vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_VLAN)) {
PMD_DRV_LOG(NOTICE,
"vlan filtering not available on this host");
-   return -ENOTSUP;
}

2015-03-06 08:24, Stephen Hemminger:
> "Ouyang, Changchun"  wrote:
> > > From: Stephen Hemminger
> > > Vlan filtering is an option, and not a requirement.
> > > If host does not support filtering then it can be done in software.
> > 
> > The question is that guest only send command, no real action to do the vlan 
> > filter. 
> > So if both host and guest have no real action for vlan filter, who will do 
> > it? 
> 
> The virtio driver has features.
> Guest can not send commands to host where feature bit not enabled.
> Application can call filter_set and check if filter worked or not.
> 
> Our code already had to do MAC and VLAN validation of incoming packets
> therefore if hardware can't do vlan match, there is no problem.
> I would expect other applications would do the same thing.
> 
> Failing during configuration is bad. DPDK API should never force
> application to play "guess the working configuration" with the device
> driver or do string match on "which device is this anyway"

[dpdk-dev] [PATCH 1/2] mk: add LDLIBS variable when producing the .so file

[Nelio Laranjeiro]

Some .so libraries needs to be linked with external libraries.  For that the
LDLIBS variable should be present on the link line when those .so files are
created.  PMD Makefile is responsible for filling the LDLIBS variable with
the link to the external library it needs.

Signed-off-by: Nelio Laranjeiro 
Acked-by: Olivier Matz 
---
 mk/rte.lib.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 9ff5cce..3a07603 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -81,7 +81,8 @@ O_TO_A_DO = @set -e; \
$(O_TO_A) && \
echo $(O_TO_A_CMD) > $(call exe2cmd,$(@))

-O_TO_S = $(LD) $(_CPU_LDFLAGS) -shared $(OBJS-y) -Wl,-soname,$(LIB) -o $(LIB)
+O_TO_S = $(LD) $(_CPU_LDFLAGS) $(LDLIBS) -shared $(OBJS-y) \
+-Wl,-soname,$(LIB) -o $(LIB)
 O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
 O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)","  LD $(@)")
 O_TO_S_DO = @set -e; \
-- 
1.9.1

[dpdk-dev] [PATCH 2/2] mlx4: add missing library dependency when compiling in shared library

[Nelio Laranjeiro]

librte_pmd_mlx4.so needs to be linked with libiverbs otherwise, the PMD is not
able to open Mellanox devices and the following message is printed by testpmd
at startup "librte_pmd_mlx4: cannot access device, is mlx4_ib loaded?".

Applications dependency on libverbs are moved to be only valid in static mode,
in shared mode, applications do not depend on it anymore,
librte_pmd_mlx4.so keeps this dependency and thus is linked with libverbs.

Signed-off-by: Nelio Laranjeiro 
Acked-by: Olivier Matz 
---
 drivers/net/mlx4/Makefile | 1 +
 mk/rte.app.mk | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx4/Makefile b/drivers/net/mlx4/Makefile
index 14cb53f..d2f5692 100644
--- a/drivers/net/mlx4/Makefile
+++ b/drivers/net/mlx4/Makefile
@@ -50,6 +50,7 @@ CFLAGS += -g
 CFLAGS += -I.
 CFLAGS += -D_XOPEN_SOURCE=600
 CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -libverbs

 # A few warnings cannot be avoided in external headers.
 CFLAGS += -Wno-error=cast-qual
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 97719cb..04af756 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -100,7 +100,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_VHOST_USER),n)
 _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST)  += -lfuse
 endif

-_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD)   += -libverbs
 _LDLIBS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD)  += -lz

 _LDLIBS-y += --start-group
@@ -140,6 +139,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING)   += 
-lrte_pmd_ring
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP)   += -lrte_pmd_pcap
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET)  += -lrte_pmd_af_packet
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NULL)   += -lrte_pmd_null
+_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD)   += -libverbs

 endif # ! $(CONFIG_RTE_BUILD_SHARED_LIB)

-- 
1.9.1

[dpdk-dev] [PATCH v2] Make the thash library arch-independent

[Vladimir Medvedkin]

v2 changes
- Fix SSE to SSE3 typo
- remove unnecessary comments
- Leave unalligned union rte_thash_tuple if no support for SSE3
- Makes 32bit compiler happy by adding ULL suffix

Signed-off-by: Vladimir Medvedkin 
---
 lib/librte_hash/rte_thash.h | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/lib/librte_hash/rte_thash.h b/lib/librte_hash/rte_thash.h
index 6156e8a..d98e98e 100644
--- a/lib/librte_hash/rte_thash.h
+++ b/lib/librte_hash/rte_thash.h
@@ -53,14 +53,19 @@ extern "C" {

 #include 
 #include 
-#include 
 #include 

+#ifdef __SSE3__
+#include 
+#endif
+
+#ifdef __SSE3__
 /* Byte swap mask used for converting IPv6 address
  * 4-byte chunks to CPU byte order
  */
 static const __m128i rte_thash_ipv6_bswap_mask = {
-   0x0405060700010203, 0x0C0D0E0F08090A0B};
+   0x0405060700010203ULL, 0x0C0D0E0F08090A0BULL};
+#endif

 /**
  * length in dwords of input tuple to
@@ -126,7 +131,11 @@ struct rte_ipv6_tuple {
 union rte_thash_tuple {
struct rte_ipv4_tuple   v4;
struct rte_ipv6_tuple   v6;
+#ifdef __SSE3__
 } __attribute__((aligned(XMM_SIZE)));
+#else
+};
+#endif

 /**
  * Prepare special converted key to use with rte_softrss_be()
@@ -157,12 +166,22 @@ rte_convert_rss_key(const uint32_t *orig, uint32_t *targ, 
int len)
 static inline void
 rte_thash_load_v6_addrs(const struct ipv6_hdr *orig, union rte_thash_tuple 
*targ)
 {
+#ifdef __SSE3__
__m128i ipv6 = _mm_loadu_si128((const __m128i *)orig->src_addr);
*(__m128i *)targ->v6.src_addr =
_mm_shuffle_epi8(ipv6, rte_thash_ipv6_bswap_mask);
ipv6 = _mm_loadu_si128((const __m128i *)orig->dst_addr);
*(__m128i *)targ->v6.dst_addr =
_mm_shuffle_epi8(ipv6, rte_thash_ipv6_bswap_mask);
+#else
+   int i;
+   for (i = 0; i < 4; i++) {
+   *((uint32_t *)targ->v6.src_addr + i) =
+   rte_be_to_cpu_32(*((const uint32_t *)orig->src_addr + 
i));
+   *((uint32_t *)targ->v6.dst_addr + i) =
+   rte_be_to_cpu_32(*((const uint32_t *)orig->dst_addr + 
i));
+   }
+#endif
 }

 /**
-- 
1.8.3.2

[dpdk-dev] [PATCH v6] Add toeplitz hash algorithm used by RSS

[Vladimir Medvedkin]

Hi Michael,

Thanks for comment, it will be fixed in next patch.

Regards,
Vladimir

2015-07-29 8:01 GMT+03:00 Qiu, Michael :

>  Hi, Vladimir
>
> You need also to fix this issue in i686 platform:
>
> RHEL65_32,2.6.32,4.4.7,14.0.0
> SUSE11SP3_32,3.0.76-0,4.3.4,14.0.0
>
>
> i686-native-linuxapp-gcc/include/rte_thash.h:63: error: integer constant
> is too large for 'long' type
> i686-native-linuxapp-gcc/include/rte_thash.h:63: error: integer constant
> is too large for 'long' type
>
>
> Thanks,
> Michael
>
> On 2015/7/27 4:58, Vladimir Medvedkin wrote:
>
> Hi Tony,
>
> Sorry for the late reply, I was on vacation.
> I'll prepare patch soon.
>
> Regards,
> Vladimir
>
> 2015-07-22 10:55 GMT+03:00 Tony Lu  :
>
>
>  Hi, Vladimir
>
> When compiling thash for no-X86 arches, it fails with the following errors.
> I wonder if
> it is possible to make the thash library arch-independent?
>
> == Build app/test
>   CC test_thash.o
> In file included from /u/zlu.bjg/git/dpdk.org/app/test/test_thash.c:40:
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:56:22
> :
> error: rte_vect.h: No such file or directory
> In file included from /u/zlu.bjg/git/dpdk.org/app/test/test_thash.c:40:
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:62:
> error: expected '=', ',', ';', 'asm' or '__attribute__' before
> 'rte_thash_ipv6_bswap_mask'
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:129:
> error: requested alignment is not a constant
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h: In
> function 'rte_thash_load_v6_addrs':
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:160:
> error: '__m128i' undeclared (first use in this function)
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:160:
> error: (Each undeclared identifier is reported only once
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:160:
> error: for each function it appears in.)
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:160:
> error: expected ';' before 'ipv6'
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:161:
> error: expected expression before ')' token
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
> error: 'ipv6' undeclared (first use in this function)
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
> warning: implicit declaration of function '_mm_loadu_si128'
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
> warning: nested extern declaration of '_mm_loadu_si128'
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
> error: expected ')' before '__m128i'
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
> warning: type defaults to 'int' in declaration of 'type name'
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:163:
> warning: cast from pointer to integer of different size
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:164:
> error: expected expression before ')' token
> /u/zlu.bjg/git/dpdk.org/tile-tilegx-linuxapp-gcc/include/rte_thash.h:158:
> warning: unused parameter 'targ'
> make[3]: *** [test_thash.o] Error 1
> make[2]: *** [test] Error 2
> make[1]: *** [app] Error 2
> make: *** [all] Error 2
>
> Thanks
> -Zhigang Lu
>
>
>  -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org ] On 
> Behalf Of Vladimir Medvedkin
> Sent: Wednesday, July 01, 2015 7:40 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v6] Add toeplitz hash algorithm used by RSS
>
> Software implementation of the Toeplitz hash function used by RSS.
> Can be used either for packet distribution on single queue NIC or for
>
>  simulating
>
>  of RSS computation on specific NIC (for example after GRE header
> decapsulating).
>
> v6 changes
> - Fix compilation error
> - Rename some defines and function
>
> v5 changes
> - Fix errors reported by checkpatch.pl
>
> v4 changes
> - Fix copyright
> - rename bswap_mask constant, add rte_ prefix
> - change rte_ipv[46]_tuple struct
> - change rte_thash_load_v6_addr prototype
>
> v3 changes
> - Rework API to be more generic
> - Add sctp_tag into tuple
>
> v2 changes
> - Add ipv6 support
> - Various style fixes
>
> Signed-off-by: Vladimir Medvedkin   gmail.com>
> ---
> lib/librte_hash/Makefile|   1 +
> lib/librte_hash/rte_thash.h | 231
> 
> 2 files changed, 232 insertions(+)
> create mode 100644 lib/librte_hash/rte_thash.h
>
> diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile index
> 3696cb1..981230b 100644
> --- a/lib/librte_hash/Makefile
> +++ b/lib/librte_hash/Makefile
> @@ -49,6 +49,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_HASH) += rte_fbk_hash.c
> SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include := rte_hash.h
> SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_hash_crc.h
> SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-inclu

[dpdk-dev] [PATCH] eal: fix build

[Zhang, Helin]

Hi Thomas

It was just an implicit declaration of function, when set 
CONFIG_RTE_PCI_CONFIG=y, as follows. Nobody else cares about it.

/home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c: In 
function ???rte_eal_pci_probe_one_driver???:
/home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c:188:4:
 error: implicit declaration of function ???pci_config_space_set??? 
[-Werror=implicit-function-declaration]
pci_config_space_set(dev);
^
/home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c:188:4:
 error: nested extern declaration of ???pci_config_space_set??? 
[-Werror=nested-externs]
cc1: all warnings being treated as errors
/home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/linuxapp/eal/eal_pci.c:561:1: 
error: ???pci_config_space_set??? defined but not used [-Werror=unused-function]
 pci_config_space_set(struct rte_pci_device *dev)
 ^
cc1: all warnings being treated as errors

Regards,
Helin

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, July 29, 2015 1:20 AM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: fix build
> 
> 2015-07-29 06:48, Helin Zhang:
> > It fixes the build error of implicit declaration of function.
> 
> What is the error?
> Please show the build log and describe the case when it happens (compiler,
> version).

[dpdk-dev] [PATCH] eal: fix build

[Gonzalez Monroy, Sergio]

On 29/07/2015 16:00, Zhang, Helin wrote:
> Hi Thomas
>
> It was just an implicit declaration of function, when set 
> CONFIG_RTE_PCI_CONFIG=y, as follows. Nobody else cares about it.
>
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c: In 
> function ???rte_eal_pci_probe_one_driver???:
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c:188:4:
>  error: implicit declaration of function ???pci_config_space_set??? 
> [-Werror=implicit-function-declaration]
>  pci_config_space_set(dev);
>  ^
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c:188:4:
>  error: nested extern declaration of ???pci_config_space_set??? 
> [-Werror=nested-externs]
> cc1: all warnings being treated as errors
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/linuxapp/eal/eal_pci.c:561:1:
>  error: ???pci_config_space_set??? defined but not used 
> [-Werror=unused-function]
>   pci_config_space_set(struct rte_pci_device *dev)
>   ^
> cc1: all warnings being treated as errors
>
> Regards,
> Helin
>
>> -Original Message-
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> Sent: Wednesday, July 29, 2015 1:20 AM
>> To: Zhang, Helin
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] eal: fix build
>>
>> 2015-07-29 06:48, Helin Zhang:
>>> It fixes the build error of implicit declaration of function.
>> What is the error?
>> Please show the build log and describe the case when it happens (compiler,
>> version).
Fixes: 4d4ebca4 ("pci: merge probing and closing functions for linux and 
bsd")

The function rte_eal_pci_probe_one_driver, which calls 
pci_config_space_set, was moved to eal_common_pci.c,
but pci_config_space_set was left in eal_pci.c with static specifier.

Sergio

[dpdk-dev] Issue with non-scattered rx in ixgbe and i40e when mbuf private area size is odd

[Martin Weiser]

Hi Helin, Hi Olivier,

we are seeing an issue with the ixgbe and i40e drivers which we could
track down to our setting of the private area size of the mbufs.
The issue can be easily reproduced with the l2fwd example application
when a small modification is done: just set the priv_size parameter in
the call to the rte_pktmbuf_pool_create function to an odd number like
1. In our tests this causes every call to rte_eth_rx_burst to return 32
(which is the setting of nb_pkts) nonsense mbufs although no packets are
received on the interface and the hardware counters do not report any
received packets.
Interestingly this does not happen if we force the scattered rx path.

I assume the drivers have some expectations regarding the alignment of
the buf_addr in the mbuf and setting an odd private are size breaks this
alignment in the rte_pktmbuf_init function. If this is the case then one
possible fix might be to enforce an alignment on the private area size.

Best regards,
Martin

[dpdk-dev] [PATCH] eal: fix build

[Zhang, Helin]

> -Original Message-
> From: Gonzalez Monroy, Sergio
> Sent: Wednesday, July 29, 2015 8:06 AM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Thomas Monjalon
> Subject: Re: [dpdk-dev] [PATCH] eal: fix build
> 
> On 29/07/2015 16:00, Zhang, Helin wrote:
> > Hi Thomas
> >
> > It was just an implicit declaration of function, when set
> CONFIG_RTE_PCI_CONFIG=y, as follows. Nobody else cares about it.
> >
> >
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.
> c: In function ???rte_eal_pci_probe_one_driver???:
> >
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.
> c:188:4: error: implicit declaration of function ???pci_config_space_set???
> [-Werror=implicit-function-declaration]
> >  pci_config_space_set(dev);
> >  ^
> >
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pc
> > i.c:188:4: error: nested extern declaration of
> > ???pci_config_space_set??? [-Werror=nested-externs]
> > cc1: all warnings being treated as errors
> >
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/linuxapp/eal/eal_pci.c:561:
> 1: error: ???pci_config_space_set??? defined but not used
> [-Werror=unused-function]
> >   pci_config_space_set(struct rte_pci_device *dev)
> >   ^
> > cc1: all warnings being treated as errors
> >
> > Regards,
> > Helin
> >
> >> -Original Message-
> >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> >> Sent: Wednesday, July 29, 2015 1:20 AM
> >> To: Zhang, Helin
> >> Cc: dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH] eal: fix build
> >>
> >> 2015-07-29 06:48, Helin Zhang:
> >>> It fixes the build error of implicit declaration of function.
> >> What is the error?
> >> Please show the build log and describe the case when it happens
> >> (compiler, version).
> Fixes: 4d4ebca4 ("pci: merge probing and closing functions for linux and
> bsd")
> 
> The function rte_eal_pci_probe_one_driver, which calls pci_config_space_set,
> was moved to eal_common_pci.c, but pci_config_space_set was left in eal_pci.c
> with static specifier.
Yes, that's the root cause.
I am just have a thought that we may need to move all of those three functions
together into eal_common_pci.c, which can avoid exporting that function.

Helin

> 
> Sergio
> 

[dpdk-dev] [PATCH] eal: fix build

[Thomas Monjalon]

2015-07-29 15:00, Zhang, Helin:
> Hi Thomas
> 
> It was just an implicit declaration of function, when set
> CONFIG_RTE_PCI_CONFIG=y, as follows. Nobody else cares about it.

Why do we have this config option?
Please remove these useless ifdef's.

> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c: In 
> function ???rte_eal_pci_probe_one_driver???:
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c:188:4:
>  error: implicit declaration of function ???pci_config_space_set??? 
> [-Werror=implicit-function-declaration]
> pci_config_space_set(dev);
> ^
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.c:188:4:
>  error: nested extern declaration of ???pci_config_space_set??? 
> [-Werror=nested-externs]
> cc1: all warnings being treated as errors
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/linuxapp/eal/eal_pci.c:561:1:
>  error: ???pci_config_space_set??? defined but not used 
> [-Werror=unused-function]
>  pci_config_space_set(struct rte_pci_device *dev)
>  ^
> cc1: all warnings being treated as errors

So I will change the title to:
eal: fix build with pci config enabled

and add this into the message:
Build log:
lib/librte_eal/common/eal_common_pci.c:188:4: error:
implicit declaration of function pci_config_space_set


> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Wednesday, July 29, 2015 1:20 AM
> > To: Zhang, Helin
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] eal: fix build
> > 
> > 2015-07-29 06:48, Helin Zhang:
> > > It fixes the build error of implicit declaration of function.
> > 
> > What is the error?
> > Please show the build log and describe the case when it happens (compiler,
> > version).

[dpdk-dev] [PATCH] eal: fix build

[Zhang, Helin]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, July 29, 2015 8:09 AM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: fix build
> 
> 2015-07-29 15:00, Zhang, Helin:
> > Hi Thomas
> >
> > It was just an implicit declaration of function, when set
> > CONFIG_RTE_PCI_CONFIG=y, as follows. Nobody else cares about it.
> 
> Why do we have this config option?
> Please remove these useless ifdef's.
> 
> >
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.
> c: In function ???rte_eal_pci_probe_one_driver???:
> >
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pci.
> c:188:4: error: implicit declaration of function ???pci_config_space_set???
> [-Werror=implicit-function-declaration]
> > pci_config_space_set(dev);
> > ^
> >
> /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/common/eal_common_pc
> > i.c:188:4: error: nested extern declaration of
> > ???pci_config_space_set??? [-Werror=nested-externs]
> > cc1: all warnings being treated as errors
> > /home/hzhan75/r22/isg_cid-dpdk_org/lib/librte_eal/linuxapp/eal/eal_pci
> > .c:561:1: error: ???pci_config_space_set??? defined but not used
> > [-Werror=unused-function]  pci_config_space_set(struct rte_pci_device
> > *dev)  ^
> > cc1: all warnings being treated as errors
> 
> So I will change the title to:
>   eal: fix build with pci config enabled
> 
> and add this into the message:
>   Build log:
>   lib/librte_eal/common/eal_common_pci.c:188:4: error:
>   implicit declaration of function pci_config_space_set
OK. Please help to do it. Thank you very much!

Regards,
Helin

> 
> 
> > > -Original Message-
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > Sent: Wednesday, July 29, 2015 1:20 AM
> > > To: Zhang, Helin
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] eal: fix build
> > >
> > > 2015-07-29 06:48, Helin Zhang:
> > > > It fixes the build error of implicit declaration of function.
> > >
> > > What is the error?
> > > Please show the build log and describe the case when it happens
> > > (compiler, version).
> 

[dpdk-dev] [PATCH] eal: fix build

[Thomas Monjalon]

2015-07-29 15:09, Zhang, Helin:
> From: Gonzalez Monroy, Sergio
> > Fixes: 4d4ebca4 ("pci: merge probing and closing functions for linux and 
> > bsd")
> > 
> > The function rte_eal_pci_probe_one_driver, which calls pci_config_space_set,
> > was moved to eal_common_pci.c, but pci_config_space_set was left in 
> > eal_pci.c
> > with static specifier.
> 
> Yes, that's the root cause.
> I am just have a thought that we may need to move all of those three functions
> together into eal_common_pci.c, which can avoid exporting that function.

No it is specific to Linux (implemented in igb_uio only).
But it may be moved to eal_common if you remove the igb_uio patch and use
the new functions to access to PCI config with UIO or VFIO:
http://dpdk.org/browse/dpdk/commit/?id=632b2d1deeed

This build fix will be applied for 2.1.
It is expected the above rework will be done for 2.2.
Thanks

[dpdk-dev] [PATCH] eal: fix build

[Zhang, Helin]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, July 29, 2015 9:06 AM
> To: Zhang, Helin
> Cc: Gonzalez Monroy, Sergio; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: fix build
> 
> 2015-07-29 15:09, Zhang, Helin:
> > From: Gonzalez Monroy, Sergio
> > > Fixes: 4d4ebca4 ("pci: merge probing and closing functions for linux
> > > and bsd")
> > >
> > > The function rte_eal_pci_probe_one_driver, which calls
> > > pci_config_space_set, was moved to eal_common_pci.c, but
> > > pci_config_space_set was left in eal_pci.c with static specifier.
> >
> > Yes, that's the root cause.
> > I am just have a thought that we may need to move all of those three
> > functions together into eal_common_pci.c, which can avoid exporting that
> function.
> 
> No it is specific to Linux (implemented in igb_uio only).
> But it may be moved to eal_common if you remove the igb_uio patch and use
> the new functions to access to PCI config with UIO or VFIO:
>   http://dpdk.org/browse/dpdk/commit/?id=632b2d1deeed
Yes, I agree. It should be moved into i40e PMD only according to the user 
configurations.

Regards,
Helin

> 
> This build fix will be applied for 2.1.
> It is expected the above rework will be done for 2.2.
> Thanks

[dpdk-dev] [PATCH 1/2] virtio: initialize iopl when device is initialized

[Thomas Monjalon]

2015-03-06 08:20, Stephen Hemminger:
> The issue is that virtio has no place it can do iopl() and have the IRQ thread
> work. It only shows up on real code where application is daemon, not in a toy
> demo or test application.
> 
> Right now:
> gcc start
>rte_virtio_pmd_init
>   iopl
> main
> daemon
> fork
> fork 
>   Process is now child of init not original process
> 
>   rte_eal_init
>  fork (pthread) for irq thread
>irq thread
> (no iopl permssion)
>   program start
>   rte_pmd_virtio_configure

This call tree is wrong.
Below is the right (and more complete) one:

gcc start
driver constructor
rte_eal_driver_register (if .a)
main
rte_eal_init
eal_parse_args
rte_eal_pci_init
rte_eal_memory_init
rte_eal_intr_init
pthread_create
eal_intr_thread_main
eal_intr_handle_interrupts
eal_intr_process_interrupts
virtio_interrupt_handler
dlopen (if .so)
driver constructor
rte_eal_driver_register
rte_eal_dev_init
driver->init
rte_virtio_pmd_init
rte_eal_iopl_init
rte_eth_driver_register
pthread_create
rte_eal_pci_probe
driver->devinit
rte_eth_dev_init
rte_eth_dev_allocate
eth_drv->eth_dev_init
eth_virtio_dev_init
virtio_resource_init

> So the only place where iopl() can be done in the proper context
> so that the IRQ (and other helper threads in future) have the correct
> permissions is in eal_init.

No there are 2 other possible solutions:
1) Move rte_eal_intr_init() after rte_eal_dev_init().
2) Move dlopen() before rte_eal_intr_init() and call iopl in the constructor.
With the second solution, we must also keep an iopl call in 
rte_virtio_pmd_init()
to return an error if iopl fails.

The second solution was proposed in the series sent by David:
http://dpdk.org/ml/archives/dev/2015-March/014931.html
http://dpdk.org/ml/archives/dev/2015-March/014932.html

[dpdk-dev] [PATCH] i40e: fix for ieee15888 with rte_next_abi

[John McNamara]

Fixes issue where ieee15888 timestamping doesn't work for the i40e
pmd when RTE_ABI_NEXT is enabled.

Also refactors repeated ieee15888 flag checking and setting
code into a function.

Reported-by: Huilong Xu 
Signed-off-by: John McNamara 
---
 drivers/net/i40e/i40e_rxtx.c | 52 +++-
 1 file changed, 27 insertions(+), 25 deletions(-)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 891a221..c33d030 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -176,6 +176,30 @@ i40e_rxd_error_to_pkt_flags(uint64_t qword)
return flags;
 }

+/* Function to check and set the ieee1588 timesync index and get the
+ * appropriate flags.
+ */
+static inline uint64_t
+i40e_get_iee15888_flags(struct rte_mbuf *mb, uint64_t qword)
+{
+   uint64_t pkt_flags = 0;
+   uint16_t tsyn = (qword & (I40E_RXD_QW1_STATUS_TSYNVALID_MASK
+ | I40E_RXD_QW1_STATUS_TSYNINDX_MASK))
+   >> I40E_RX_DESC_STATUS_TSYNINDX_SHIFT;
+
+#ifdef RTE_NEXT_ABI
+   if ((mb->packet_type & RTE_PTYPE_L2_MASK)
+   == RTE_PTYPE_L2_ETHER_TIMESYNC)
+   pkt_flags = PKT_RX_IEEE1588_PTP;
+#endif
+   if (tsyn & 0x04) {
+   pkt_flags |= PKT_RX_IEEE1588_TMST;
+   mb->timesync = tsyn & 0x03;
+   }
+
+   return pkt_flags;
+}
+
 #ifdef RTE_NEXT_ABI
 /* For each value it means, datasheet of hardware can tell more details */
 static inline uint32_t
@@ -1285,15 +1309,7 @@ i40e_rx_scan_hw_ring(struct i40e_rx_queue *rxq)
pkt_flags |= i40e_rxd_build_fdir(&rxdp[j], mb);

 #ifdef RTE_LIBRTE_IEEE1588
-   uint16_t tsyn = (qword1
-& (I40E_RXD_QW1_STATUS_TSYNVALID_MASK
-  | I40E_RXD_QW1_STATUS_TSYNINDX_MASK))
->> I40E_RX_DESC_STATUS_TSYNINDX_SHIFT;
-
-   if (tsyn & 0x04)
-   pkt_flags |= PKT_RX_IEEE1588_TMST;
-
-   mb->timesync = tsyn & 0x03;
+   pkt_flags |= i40e_get_iee15888_flags(mb, qword1);
 #endif
mb->ol_flags |= pkt_flags;

@@ -1547,14 +1563,7 @@ i40e_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts)
pkt_flags |= i40e_rxd_build_fdir(&rxd, rxm);

 #ifdef RTE_LIBRTE_IEEE1588
-   uint16_t tsyn = (qword1 & (I40E_RXD_QW1_STATUS_TSYNVALID_MASK
-   | I40E_RXD_QW1_STATUS_TSYNINDX_MASK))
-   >> I40E_RX_DESC_STATUS_TSYNINDX_SHIFT;
-
-   if (tsyn & 0x04)
-   pkt_flags |= PKT_RX_IEEE1588_TMST;
-
-   rxm->timesync = tsyn & 0x03;
+   pkt_flags |= i40e_get_iee15888_flags(rxm, qword1);
 #endif
rxm->ol_flags |= pkt_flags;

@@ -1723,14 +1732,7 @@ i40e_recv_scattered_pkts(void *rx_queue,
pkt_flags |= i40e_rxd_build_fdir(&rxd, rxm);

 #ifdef RTE_LIBRTE_IEEE1588
-   uint16_t tsyn = (qword1 & (I40E_RXD_QW1_STATUS_TSYNVALID_MASK
-   | I40E_RXD_QW1_STATUS_TSYNINDX_MASK))
-   >> I40E_RX_DESC_STATUS_TSYNINDX_SHIFT;
-
-   if (tsyn & 0x04)
-   pkt_flags |= PKT_RX_IEEE1588_TMST;
-
-   first_seg->timesync = tsyn & 0x03;
+   pkt_flags |= i40e_get_iee15888_flags(first_seg, qword1);
 #endif
first_seg->ol_flags |= pkt_flags;

-- 
1.8.1.4

[dpdk-dev] Issue with non-scattered rx in ixgbe and i40e when mbuf private area size is odd

[Ananyev, Konstantin]

Hi Martin,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Martin Weiser
> Sent: Wednesday, July 29, 2015 4:07 PM
> To: Zhang, Helin; olivier.matz at 6wind.com
> Cc: dev at dpdk.org
> Subject: [dpdk-dev] Issue with non-scattered rx in ixgbe and i40e when mbuf 
> private area size is odd
> 
> Hi Helin, Hi Olivier,
> 
> we are seeing an issue with the ixgbe and i40e drivers which we could
> track down to our setting of the private area size of the mbufs.
> The issue can be easily reproduced with the l2fwd example application
> when a small modification is done: just set the priv_size parameter in
> the call to the rte_pktmbuf_pool_create function to an odd number like
> 1. In our tests this causes every call to rte_eth_rx_burst to return 32
> (which is the setting of nb_pkts) nonsense mbufs although no packets are
> received on the interface and the hardware counters do not report any
> received packets.

[dpdk-dev] Issue with non-scattered rx in ixgbe and i40e when mbuf private area size is odd

[Zhang, Helin]

Hi Martin

Thank you very much for the good catch!

The similar situation in i40e, as explained by Konstantin.
As header split hasn't been supported by DPDK till now. It would be better to 
put the header address in RX descriptor to 0.
But in the future, during header split enabling. We may need to pay extra 
attention to that. As at least x710 datasheet said specifically as below.
"The header address should be set by the software to an even number (word 
aligned address)". We may need to find a way to ensure that during mempool/mbuf 
allocation.

Regards,
Helin

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, July 29, 2015 11:12 AM
> To: Martin Weiser; Zhang, Helin; olivier.matz at 6wind.com
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] Issue with non-scattered rx in ixgbe and i40e when 
> mbuf
> private area size is odd
> 
> Hi Martin,
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Martin Weiser
> > Sent: Wednesday, July 29, 2015 4:07 PM
> > To: Zhang, Helin; olivier.matz at 6wind.com
> > Cc: dev at dpdk.org
> > Subject: [dpdk-dev] Issue with non-scattered rx in ixgbe and i40e when
> > mbuf private area size is odd
> >
> > Hi Helin, Hi Olivier,
> >
> > we are seeing an issue with the ixgbe and i40e drivers which we could
> > track down to our setting of the private area size of the mbufs.
> > The issue can be easily reproduced with the l2fwd example application
> > when a small modification is done: just set the priv_size parameter in
> > the call to the rte_pktmbuf_pool_create function to an odd number like
> > 1. In our tests this causes every call to rte_eth_rx_burst to return
> > 32 (which is the setting of nb_pkts) nonsense mbufs although no
> > packets are received on the interface and the hardware counters do not
> > report any received packets.
> 
> From Niantic datasheet:
> 
> "7.1.6.1 Advanced Receive Descriptors ? Read Format Table 7-15 lists the
> advanced receive descriptor programming by the software. The ...
> Packet Buffer Address (64)
> This is the physical address of the packet buffer. The lowest bit is A0 (LSB 
> of the
> address).
> Header Buffer Address (64)
> The physical address of the header buffer with the lowest bit being Descriptor
> Done (DD).
> When a packet spans in multiple descriptors, the header buffer address is used
> only on the first descriptor. During the programming phase, software must set
> the DD bit to zero (see the description of the DD bit in this section). This 
> means
> that header buffer addresses are always word aligned."
> 
> Right now, in ixgbe PMD we always setup  Packet Buffer Address (PBA)and
> Header Buffer Address (HBA) to the same value:
> buf_physaddr + RTE_PKTMBUF_HEADROOM
> So when pirv_size==1, DD bit in RXD is always set to one by SW itself, and 
> then
> SW considers that HW already done with it.
> In other words, right now for ixgbe you can't use RX buffer that is not 
> aligned on
> word boundary.
> 
> So the advice would be, right now - don't set priv_size to the odd value.
> As we don't support split header feature anyway, I think we can fix it just by
> always setting HBA in the RXD to zero.
> Could you try the fix for ixgbe below?
> 
> Same story with FVL, I believe.
> Konstantin
> 
> 
> > Interestingly this does not happen if we force the scattered rx path.
> >
> > I assume the drivers have some expectations regarding the alignment of
> > the buf_addr in the mbuf and setting an odd private are size breaks
> > this alignment in the rte_pktmbuf_init function. If this is the case
> > then one possible fix might be to enforce an alignment on the private area 
> > size.
> >
> > Best regards,
> > Martin
> 
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index a0c8847..94967c5 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -1183,7 +1183,7 @@ ixgbe_rx_alloc_bufs(struct ixgbe_rx_queue *rxq, bool
> reset_mbuf)
> 
> /* populate the descriptors */
> dma_addr =
> rte_cpu_to_le_64(RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb));
> -   rxdp[i].read.hdr_addr = dma_addr;
> +   rxdp[i].read.hdr_addr = 0;
> rxdp[i].read.pkt_addr = dma_addr;
> }
> 
> @@ -1414,7 +1414,7 @@ ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf
> **rx_pkts,
> rxe->mbuf = nmb;
> dma_addr =
> 
> rte_cpu_to_le_64(RTE_MBUF_DATA_DMA_ADDR_DEFAULT(nmb));
> -   rxdp->read.hdr_addr = dma_addr;
> +   rxdp->read.hdr_addr = 0;
> rxdp->read.pkt_addr = dma_addr;
> 
> /*
> @@ -1741,7 +1741,7 @@ next_desc:
> rxe->mbuf = nmb;
> 
> rxm->data_off = RTE_PKTMBUF_HEADROOM;
> -   rxdp->read.hdr_addr = dma;
> +   rxdp->read.hdr_addr = 0;
> rxdp->read.pkt_addr = dma;
> } else

[dpdk-dev] Fwd: OVS with DPDK ..Error packets

[Srikanth Akula]

(+DPDK dev team )


Hello ,

I am trying to test the OVS_DPDK performance and found that lot of packets
being treated as error packets .

ovs-vsctl get Interface dpdk0 statistics
{collisions=0, rx_bytes=38915076374, rx_crc_err=0, rx_dropped=0,
*rx_errors=3840287219
<3840287219>, *rx_frame_err=0, rx_over_err=0, rx_packets=292972799,
tx_bytes=38935883904, tx_dropped=0, tx_errors=0, tx_packets=293068162}

I am running DPDK application inside my VM .

Looks like there is a buffer issue ( 64Bytes - 10Gbps)

Could  somebody let me know if i have missed any configuration in DPDK/OVS ?

-Srikanth

[dpdk-dev] [PATCH] testpmd: Fix segment fault when port ID greater than 76

[Thomas Monjalon]

2015-07-29 02:32, Michael Qiu:
> In testpmd, when using "rx_vlan add 1 77", it will be a segment fault
> Because the port ID should be less than 32.
> 
> Signed-off-by: Michael Qiu 

Fixes: edab33b1c01d ("app/testpmd: support port hotplug")

Applied, thanks

[dpdk-dev] [PATCH v2] Add support for pthreads setname.

[Stephen Hemminger]

On Tue, 28 Jul 2015 17:51:44 -0700
Ravi Kerur  wrote:

> This patch adds support for pthread_setname_np on Linux and
> pthread_set_name_np on FreeBSD.
> 
> Changes in V2:
> Remove config support for max thread name len.
> Restrict max thread name len to 16 on Linux and FreeBSD.
> Fix checkpatch.pl errors.
> Changes based on code review comments from Thomas.
> 
> Changes in V1:
> Add support for _setname_ on Linux and FreeBSD.
> 
> Signed-off-by: Ravi Kerur 

Looks like good simple solution.
Acked-by: Stephen Hemminger 

[dpdk-dev] [PATCH] pci: make rte_pci_probe void

[Stephen Hemminger]

On Mon, 20 Apr 2015 15:15:36 +0200
Thomas Monjalon  wrote:

> 2015-04-14 10:55, Stephen Hemminger:
> > Since rte_pci_probe always returns 0 or exits via rte_exit()
> > there is no point in having it return a value.
> > 
> > Just make it void
> > 
> > Signed-off-by: Stephen Hemminger 
> 
> Seems partially superseded by this patch:
>   http://dpdk.org/dev/patchwork/patch/4347/
> 

The patch could be redone, but it would break ABI for no good
reason. Just drop it.

[dpdk-dev] [PATCH 1/2] log: rte_openlog_stream should be void

[Stephen Hemminger]

On Tue, 19 May 2015 11:24:03 +0100
Bruce Richardson  wrote:

> On Fri, Apr 17, 2015 at 08:35:33AM -0700, Stephen Hemminger wrote:
> > Function always returned 0 and no one was checking anyway.
> > 
> > Signed-off-by: Stephen Hemminger 
> 
> Acked-by: Bruce Richardson 
> 
> > ---
> >  lib/librte_eal/common/eal_common_log.c  | 3 +--
> >  lib/librte_eal/common/include/rte_log.h | 5 +
> >  2 files changed, 2 insertions(+), 6 deletions(-)
> > 
> > diff --git a/lib/librte_eal/common/eal_common_log.c 
> > b/lib/librte_eal/common/eal_common_log.c
> > index ff44d23..3802f9c 100644
> > --- a/lib/librte_eal/common/eal_common_log.c
> > +++ b/lib/librte_eal/common/eal_common_log.c
> > @@ -158,14 +158,13 @@ rte_log_set_history(int enable)
> >  }
> >  
> >  /* Change the stream that will be used by logging system */
> > -int
> > +void
> >  rte_openlog_stream(FILE *f)
> >  {
> > if (f == NULL)
> > rte_logs.file = default_log_stream;
> > else
> > rte_logs.file = f;
> > -   return 0;
> >  }
> >  
> >  /* Set global log level */
> > diff --git a/lib/librte_eal/common/include/rte_log.h 
> > b/lib/librte_eal/common/include/rte_log.h
> > index f83a0d9..888ee19 100644
> > --- a/lib/librte_eal/common/include/rte_log.h
> > +++ b/lib/librte_eal/common/include/rte_log.h
> > @@ -110,11 +110,8 @@ extern FILE *eal_default_log_stream;
> >   *
> >   * @param f
> >   *   Pointer to the stream.
> > - * @return
> > - *   - 0 on success.
> > - *   - Negative on error.
> >   */
> > -int rte_openlog_stream(FILE *f);
> > +void rte_openlog_stream(FILE *f);
> >  
> >  /**
> >   * Set the global log level.
> > -- 
> > 2.1.4
> > 

Yes it should be void, but technically this is an ABI change.
Please drop the patch.