[dpdk-dev] mk: fix app linking for combined libs

[Hiroshi Shimamoto]

> Subject: Re: [dpdk-dev] mk: fix app linking for combined libs
> 
> 2014-12-08 09:53, Neil Horman:
> > On Thu, Oct 23, 2014 at 04:36:44PM +0100, Sergio Gonzalez Monroy wrote:
> > > Building combined shared libraries results in applications being linked
> > > against separeted/individual and combined libs altogether.
> > >
> > > Link only against combined lib when the config option is enabled.
> > >
> > > Signed-off-by: Sergio Gonzalez Monroy  > > intel.com>
> > > Acked-by: Pablo de Lara 
> [...]
> > Acked-by: Neil Horman 
> 
> Neil, I didn't noticed your ack which happened after a discussion I had with
> Sergio. He agreed to make a v2.
> Actually Hiroshi did it:
>   http://dpdk.org/ml/archives/dev/2014-December/009847.html
> I'm going to apply Hiroshi's one.

Ah, I haven't noticed there was the patch to address this issue.

thanks,
Hiroshi

[dpdk-dev] Segmentation fault in rte_eal_hugepage_attach

[Rick LaMont]

My DPDK application works fine when it's the primary process but crashes
whenever --proc-type=secondary. The segmentation fault occurs in this call
to mmap() within rte_eal_hugepage_attach():

/*
 * fdzero is mmapped to get a contiguous block of virtual
 * addresses of the appropriate memseg size.
 * use mmap to get identical addresses as the primary process.
 */
base_addr = mmap(mcfg->memseg[s].addr, mcfg->memseg[s].len,
 PROT_READ, MAP_PRIVATE | MAP_FIXED, fd_zero, 0);

I've confirmed that addr and len match the values in rte_eal_hugepage_init()
of the primary process (1 gigabyte). The target platform is a 32-bit embedded
system running a Yocto distribution. I've confirmed that other applications
such as mp_simple work as both primary and secondary on the same platform.
The problem only occurs with a larger application to which I'm adding DPDK
capabilities.

Any advice on how to troubleshoot this? I've been looking at it for a week
already and am running out of ideas for things to test.

Thanks,


Rick LaMont  | The storm that I thought would blow over
Dot C Software, Inc. | Clouds the light of the love that I found

[dpdk-dev] [PATCH 6/7] vmxnet3: support RSS and refactor offload

[Stephen Hemminger]

From: Stephen Hemminger 

Refactor the logic to compute receive offload flags to a simpler
function. Andd add support for putting RSS flow hash into packet.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Bill Hong 
---
 lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c | 69 ---
 1 file changed, 40 insertions(+), 29 deletions(-)

diff --git a/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c 
b/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
index bd47c6c..53ddb2c 100644
--- a/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
+++ b/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
@@ -488,6 +488,43 @@ vmxnet3_post_rx_bufs(vmxnet3_rx_queue_t *rxq, uint8_t 
ring_id)
return i;
 }

+
+/* Receive side checksum and other offloads */
+static void
+vmxnet3_rx_offload(const Vmxnet3_RxCompDesc *rcd, struct rte_mbuf *rxm)
+{
+   /* Check for hardware stripped VLAN tag */
+   if (rcd->ts) {
+   rxm->ol_flags |= PKT_RX_VLAN_PKT;
+   rxm->vlan_tci = rte_le_to_cpu_16((uint16_t)rcd->tci);
+   }
+
+   /* Check for RSS */
+   if (rcd->rssType != VMXNET3_RCD_RSS_TYPE_NONE) {
+   rxm->ol_flags |= PKT_RX_RSS_HASH;
+   rxm->hash.rss = rcd->rssHash;
+   }
+
+   /* Check packet type, checksum errors, etc. Only support IPv4 for now. 
*/
+   if (rcd->v4) {
+   struct ether_hdr *eth = rte_pktmbuf_mtod(rxm, struct ether_hdr 
*);
+   struct ipv4_hdr *ip = (struct ipv4_hdr *)(eth + 1);
+
+   if (((ip->version_ihl & 0xf) << 2) > (int)sizeof(struct 
ipv4_hdr))
+   rxm->ol_flags |= PKT_RX_IPV4_HDR_EXT;
+   else
+   rxm->ol_flags |= PKT_RX_IPV4_HDR;
+
+   if (!rcd->cnc) {
+   if (!rcd->ipc)
+   rxm->ol_flags |= PKT_RX_IP_CKSUM_BAD;
+
+   if ((rcd->tcp || rcd->udp) && !rcd->tuc)
+   rxm->ol_flags |= PKT_RX_L4_CKSUM_BAD;
+   }
+   }
+}
+
 /*
  * Process the Rx Completion Ring of given vmxnet3_rx_queue
  * for nb_pkts burst and return the number of packets received
@@ -583,17 +620,6 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts)
goto rcd_done;
}

-   /* Check for hardware stripped VLAN tag */
-   if (rcd->ts) {
-   PMD_RX_LOG(DEBUG, "Received packet with vlan ID: %d.",
-  rcd->tci);
-   rxm->ol_flags = PKT_RX_VLAN_PKT;
-   /* Copy vlan tag in packet buffer */
-   rxm->vlan_tci = rte_le_to_cpu_16((uint16_t)rcd->tci);
-   } else {
-   rxm->ol_flags = 0;
-   rxm->vlan_tci = 0;
-   }

/* Initialize newly received packet buffer */
rxm->port = rxq->port_id;
@@ -602,25 +628,10 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts)
rxm->pkt_len = (uint16_t)rcd->len;
rxm->data_len = (uint16_t)rcd->len;
rxm->data_off = RTE_PKTMBUF_HEADROOM;
+   rxm->ol_flags = 0;
+   rxm->vlan_tci = 0;

-   /* Check packet type, checksum errors, etc. Only support IPv4 
for now. */
-   if (rcd->v4) {
-   struct ether_hdr *eth = rte_pktmbuf_mtod(rxm, struct 
ether_hdr *);
-   struct ipv4_hdr *ip = (struct ipv4_hdr *)(eth + 1);
-
-   if (((ip->version_ihl & 0xf) << 2) > (int)sizeof(struct 
ipv4_hdr))
-   rxm->ol_flags |= PKT_RX_IPV4_HDR_EXT;
-   else
-   rxm->ol_flags |= PKT_RX_IPV4_HDR;
-
-   if (!rcd->cnc) {
-   if (!rcd->ipc)
-   rxm->ol_flags |= PKT_RX_IP_CKSUM_BAD;
-
-   if ((rcd->tcp || rcd->udp) && !rcd->tuc)
-   rxm->ol_flags |= PKT_RX_L4_CKSUM_BAD;
-   }
-   }
+   vmxnet3_rx_offload(rcd, rxm);

rx_pkts[nb_rx++] = rxm;
 rcd_done:
-- 
2.1.3

[dpdk-dev] [PATCH 5/7] vmxnet3: get rid of DEBUG ifdefs

[Stephen Hemminger]

From: Stephen Hemminger 

By defining macro as a stub it is possible to get rid of #ifdef's
in the actual code.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_pmd_vmxnet3/vmxnet3_ethdev.h | 6 --
 lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c   | 9 +
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.h 
b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.h
index 258fbae..0990f59 100644
--- a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.h
+++ b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.h
@@ -35,9 +35,11 @@
 #define _VMXNET3_ETHDEV_H_

 #ifdef RTE_LIBRTE_VMXNET3_DEBUG_DRIVER
-#define VMXNET3_ASSERT(x) do { \
-   if (!(x)) rte_panic("VMXNET3: x"); \
+#define VMXNET3_ASSERT(x) do { \
+   if (unlikely(!(x))) rte_panic("VMXNET3: %s\n", #x); \
 } while(0)
+#else
+#define VMXNET3_ASSERT(x) do { (void)(x); } while (0)
 #endif

 #define VMXNET3_MAX_MAC_ADDRS 1
diff --git a/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c 
b/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
index 7cb0b93..bd47c6c 100644
--- a/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
+++ b/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
@@ -308,9 +308,7 @@ vmxnet3_tq_tx_complete(vmxnet3_tx_queue_t *txq)
while (tcd->gen == comp_ring->gen) {

/* Release cmd_ring descriptor and free mbuf */
-#ifdef RTE_LIBRTE_VMXNET3_DEBUG_DRIVER
VMXNET3_ASSERT(txq->cmd_ring.base[tcd->txdIdx].txd.eop == 1);
-#endif
mbuf = txq->cmd_ring.buf_info[tcd->txdIdx].m;
rte_pktmbuf_free_seg(mbuf);
txq->cmd_ring.buf_info[tcd->txdIdx].m = NULL;
@@ -539,16 +537,13 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts)

PMD_RX_LOG(DEBUG, "rxd idx: %d ring idx: %d.", idx, ring_idx);

-#ifdef RTE_LIBRTE_VMXNET3_DEBUG_DRIVER
VMXNET3_ASSERT(rcd->len <= rxd->len);
VMXNET3_ASSERT(rbi->m);
-#endif
+
if (unlikely(rcd->len == 0)) {
PMD_RX_LOG(DEBUG, "Rx buf was skipped. 
rxring[%d][%d]\n)",
   ring_idx, idx);
-#ifdef RTE_LIBRTE_VMXNET3_DEBUG_DRIVER
VMXNET3_ASSERT(rcd->sop && rcd->eop);
-#endif
rte_pktmbuf_free_seg(rbi->m);
goto rcd_done;
}
@@ -561,9 +556,7 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts)
rte_pktmbuf_free_seg(rbi->m);
goto rcd_done;
}
-#ifdef RTE_LIBRTE_VMXNET3_DEBUG_DRIVER
VMXNET3_ASSERT(rxd->btype == VMXNET3_RXD_BTYPE_HEAD);
-#endif
/* Get the packet buffer pointer from buf_info */
rxm = rbi->m;

-- 
2.1.3

[dpdk-dev] [PATCH 4/7] vmxnet3: fix link state handling

[Stephen Hemminger]

From: Stephen Hemminger 

This patch is a bugfx.

The Intel version of VMXNET3 driver does not handle link state properly.
The VMXNET3 API returns 1 if connected and 0 if disconnected.
Also need to return correct value to indicate state change.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c | 53 +++--
 1 file changed, 38 insertions(+), 15 deletions(-)

diff --git a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c 
b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
index 4947c78..7afb43f 100644
--- a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
+++ b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
@@ -157,9 +157,36 @@ gpa_zone_reserve(struct rte_eth_dev *dev, uint32_t size,
  *   - On success, zero.
  *   - On failure, negative value.
  */
-static inline int
-rte_vmxnet3_dev_atomic_write_link_status(struct rte_eth_dev *dev,
-   struct rte_eth_link *link)
+
+static int
+vmxnet3_dev_atomic_read_link_status(struct rte_eth_dev *dev,
+   struct rte_eth_link *link)
+{
+   struct rte_eth_link *dst = link;
+   struct rte_eth_link *src = &(dev->data->dev_link);
+
+   if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
+   *(uint64_t *)src) == 0)
+   return -1;
+
+   return 0;
+}
+
+/**
+ * Atomically writes the link status information into global
+ * structure rte_eth_dev.
+ *
+ * @param dev
+ *   - Pointer to the structure rte_eth_dev to read from.
+ *   - Pointer to the buffer to be saved with the link status.
+ *
+ * @return
+ *   - On success, zero.
+ *   - On failure, negative value.
+ */
+static int
+vmxnet3_dev_atomic_write_link_status(struct rte_eth_dev *dev,
+struct rte_eth_link *link)
 {
struct rte_eth_link *dst = &(dev->data->dev_link);
struct rte_eth_link *src = link;
@@ -576,7 +603,7 @@ vmxnet3_dev_stop(struct rte_eth_dev *dev)

/* Clear recorded link status */
memset(, 0, sizeof(link));
-   rte_vmxnet3_dev_atomic_write_link_status(dev, );
+   vmxnet3_dev_atomic_write_link_status(dev, );
 }

 /*
@@ -658,28 +685,24 @@ static int
 vmxnet3_dev_link_update(struct rte_eth_dev *dev, __attribute__((unused)) int 
wait_to_complete)
 {
struct vmxnet3_hw *hw = dev->data->dev_private;
-   struct rte_eth_link link;
+   struct rte_eth_link old, link;
uint32_t ret;

+   memset(, 0, sizeof(link));
+   vmxnet3_dev_atomic_read_link_status(dev, );
+
VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD, VMXNET3_CMD_GET_LINK);
ret = VMXNET3_READ_BAR1_REG(hw, VMXNET3_REG_CMD);

-   if (!ret) {
-   PMD_INIT_LOG(ERR, "Link Status Negative : %s()", __func__);
-   return -1;
-   }
-
if (ret & 0x1) {
link.link_status = 1;
link.link_duplex = ETH_LINK_FULL_DUPLEX;
link.link_speed = ETH_LINK_SPEED_1;
-
-   rte_vmxnet3_dev_atomic_write_link_status(dev, );
-
-   return 0;
}

-   return -1;
+   vmxnet3_dev_atomic_write_link_status(dev, );
+
+   return (old.link_status == link.link_status) ? -1 : 0;
 }

 /* Updating rxmode through Vmxnet3_DriverShared structure in adapter */
-- 
2.1.3

[dpdk-dev] [PATCH 3/7] vmxnet3: add support for mulit-segment transmit

[Stephen Hemminger]

From: Stephen Hemminger 

Change sending loop to support multi-segment mbufs.
The VMXNET3 api has start-of-packet and end-packet flags, so it
is not hard to send multi-segment mbuf's.

Also, update descriptor in 32 bit value rather than toggling
bitfields which is slower and error prone.
Based on code in earlier driver, and the Linux kernel driver.

Add a compiler barrier to make sure that update of earlier descriptor
are completed prior to update of generation bit on start of packet.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Bill Hong 
---
 lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c | 126 +-
 1 file changed, 48 insertions(+), 78 deletions(-)

diff --git a/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c 
b/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
index 8e15784..7cb0b93 100644
--- a/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
+++ b/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
@@ -312,13 +312,9 @@ vmxnet3_tq_tx_complete(vmxnet3_tx_queue_t *txq)
VMXNET3_ASSERT(txq->cmd_ring.base[tcd->txdIdx].txd.eop == 1);
 #endif
mbuf = txq->cmd_ring.buf_info[tcd->txdIdx].m;
-   if (unlikely(mbuf == NULL))
-   rte_panic("EOP desc does not point to a valid mbuf");
-   else
-   rte_pktmbuf_free(mbuf);
-
-
+   rte_pktmbuf_free_seg(mbuf);
txq->cmd_ring.buf_info[tcd->txdIdx].m = NULL;
+
/* Mark the txd for which tcd was generated as completed */
vmxnet3_cmd_ring_adv_next2comp(>cmd_ring);

@@ -336,13 +332,8 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts,
  uint16_t nb_pkts)
 {
uint16_t nb_tx;
-   Vmxnet3_TxDesc *txd = NULL;
-   vmxnet3_buf_info_t *tbi = NULL;
-   struct vmxnet3_hw *hw;
-   struct rte_mbuf *txm;
vmxnet3_tx_queue_t *txq = tx_queue;
-
-   hw = txq->hw;
+   struct vmxnet3_hw *hw = txq->hw;

if (unlikely(txq->stopped)) {
PMD_TX_LOG(DEBUG, "Tx queue is stopped.");
@@ -354,75 +345,60 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts,

nb_tx = 0;
while (nb_tx < nb_pkts) {
+   Vmxnet3_GenericDesc *gdesc;
+   vmxnet3_buf_info_t *tbi;
+   uint32_t first2fill, avail, dw2;
+   struct rte_mbuf *txm = tx_pkts[nb_tx];
+   struct rte_mbuf *m_seg = txm;
+
+   /* Is command ring full? */
+   avail = vmxnet3_cmd_ring_desc_avail(>cmd_ring);
+   if (txm->nb_segs > avail) {
+   ++txq->stats.tx_ring_full;
+   break;
+   }

-   if (vmxnet3_cmd_ring_desc_avail(>cmd_ring)) {
-   int copy_size = 0;
-
-   txm = tx_pkts[nb_tx];
-   /* Don't support scatter packets yet, free them if met 
*/
-   if (txm->nb_segs != 1) {
-   PMD_TX_LOG(DEBUG, "Don't support scatter 
packets yet, drop!");
-   rte_pktmbuf_free(tx_pkts[nb_tx]);
-   txq->stats.drop_total++;
-
-   nb_tx++;
-   continue;
-   }
-
-   txd = (Vmxnet3_TxDesc *)(txq->cmd_ring.base + 
txq->cmd_ring.next2fill);
-   if (rte_pktmbuf_pkt_len(txm) <= VMXNET3_HDR_COPY_SIZE) {
-   struct Vmxnet3_TxDataDesc *tdd;
-
-   tdd = txq->data_ring.base + 
txq->cmd_ring.next2fill;
-   copy_size = rte_pktmbuf_pkt_len(txm);
-   rte_memcpy(tdd->data, rte_pktmbuf_mtod(txm, 
char *), copy_size);
-   }
-
-   /* Fill the tx descriptor */
+   /* use the previous gen bit for the SOP desc */
+   dw2 = (txq->cmd_ring.gen ^ 0x1) << VMXNET3_TXD_GEN_SHIFT;
+   first2fill = txq->cmd_ring.next2fill;
+   do {
+   /* Remember the transmit buffer for cleanup */
tbi = txq->cmd_ring.buf_info + txq->cmd_ring.next2fill;
-   tbi->bufPA = RTE_MBUF_DATA_DMA_ADDR(txm);
-   if (copy_size)
-   txd->addr = 
rte_cpu_to_le_64(txq->data_ring.basePA +
-   txq->cmd_ring.next2fill 
*
-   sizeof(struct 
Vmxnet3_TxDataDesc));
-   else
-   txd->addr = tbi->bufPA;
-   txd->len = txm->data_len;
+   tbi->m = m_seg;

-   /* Mark the last descriptor as End of Packet. */
-   txd->cq = 1;
-   txd->eop = 1;
+   /* NB: the following assumes 

[dpdk-dev] [PATCH 1/7] vmxnet3: add support for VLAN filtering

[Stephen Hemminger]

From: Stephen Hemminger 

VMXNET3 supports configuring filter table in host.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c | 107 +---
 lib/librte_pmd_vmxnet3/vmxnet3_ethdev.h |   2 +-
 lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c   |  25 
 3 files changed, 99 insertions(+), 35 deletions(-)

diff --git a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c 
b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
index ef0af16..30d0659 100644
--- a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
+++ b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
@@ -87,6 +87,12 @@ static void vmxnet3_dev_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *stats);
 static void vmxnet3_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static int vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev,
+  uint16_t vid, int on);
+static void vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
+static void vmxnet3_dev_vlan_offload_set_clear(struct rte_eth_dev *dev,
+   int mask, int clear);
+
 #if PROCESS_SYS_EVENTS == 1
 static void vmxnet3_process_events(struct vmxnet3_hw *);
 #endif
@@ -113,6 +119,8 @@ static struct eth_dev_ops vmxnet3_eth_dev_ops = {
.link_update  = vmxnet3_dev_link_update,
.stats_get= vmxnet3_dev_stats_get,
.dev_infos_get= vmxnet3_dev_info_get,
+   .vlan_filter_set  = vmxnet3_dev_vlan_filter_set,
+   .vlan_offload_set = vmxnet3_dev_vlan_offload_set,
.rx_queue_setup   = vmxnet3_dev_rx_queue_setup,
.rx_queue_release = vmxnet3_dev_rx_queue_release,
.tx_queue_setup   = vmxnet3_dev_tx_queue_setup,
@@ -371,7 +379,7 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
Vmxnet3_DSDevRead *devRead = >devRead;
uint32_t *mac_ptr;
uint32_t val, i;
-   int ret;
+   int ret, mask;

shared->magic = VMXNET3_REV1_MAGIC;
devRead->misc.driverInfo.version = VMXNET3_DRIVER_VERSION_NUM;
@@ -442,9 +450,6 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
if (dev->data->dev_conf.rxmode.hw_ip_checksum)
devRead->misc.uptFeatures |= VMXNET3_F_RXCSUM;

-   if (dev->data->dev_conf.rxmode.hw_vlan_strip)
-   devRead->misc.uptFeatures |= VMXNET3_F_RXVLAN;
-
if (port_conf.rxmode.mq_mode == ETH_MQ_RX_RSS) {
ret = vmxnet3_rss_configure(dev);
if (ret != VMXNET3_SUCCESS)
@@ -456,11 +461,14 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
devRead->rssConfDesc.confPA  = hw->rss_confPA;
}

-   if (dev->data->dev_conf.rxmode.hw_vlan_filter) {
-   ret = vmxnet3_vlan_configure(dev);
-   if (ret != VMXNET3_SUCCESS)
-   return ret;
-   }
+   mask = 0;
+   if (dev->data->dev_conf.rxmode.hw_vlan_strip)
+   mask |= ETH_VLAN_STRIP_MASK;
+
+   if (dev->data->dev_conf.rxmode.hw_vlan_filter)
+   mask |= ETH_VLAN_FILTER_MASK;
+
+   vmxnet3_dev_vlan_offload_set_clear(dev, mask, 1);

PMD_INIT_LOG(DEBUG,
 "Writing MAC Address : %02x:%02x:%02x:%02x:%02x:%02x",
@@ -690,13 +698,23 @@ vmxnet3_dev_set_rxmode(struct vmxnet3_hw *hw, uint32_t 
feature, int set) {
VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD, VMXNET3_CMD_UPDATE_RX_MODE);
 }

+static void
+vmxnet3_dev_update_filters(struct vmxnet3_hw *hw)
+{
+   VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD,
+  VMXNET3_CMD_UPDATE_VLAN_FILTERS);
+}
+
 /* Promiscuous supported only if Vmxnet3_DriverShared is initialized in 
adapter */
 static void
 vmxnet3_dev_promiscuous_enable(struct rte_eth_dev *dev)
 {
struct vmxnet3_hw *hw = dev->data->dev_private;
+   uint32_t *vf_table = hw->shared->devRead.rxFilterConf.vfTable;

+   memset(vf_table, 0, VMXNET3_VFT_SIZE * sizeof(*vf_table));
vmxnet3_dev_set_rxmode(hw, VMXNET3_RXM_PROMISC, 1);
+   vmxnet3_dev_update_filters(hw);
 }

 /* Promiscuous supported only if Vmxnet3_DriverShared is initialized in 
adapter */
@@ -704,8 +722,11 @@ static void
 vmxnet3_dev_promiscuous_disable(struct rte_eth_dev *dev)
 {
struct vmxnet3_hw *hw = dev->data->dev_private;
+   uint32_t *vf_table = hw->shared->devRead.rxFilterConf.vfTable;

+   memset(vf_table, 0, VMXNET3_VFT_SIZE * sizeof(*vf_table));
vmxnet3_dev_set_rxmode(hw, VMXNET3_RXM_PROMISC, 0);
+   vmxnet3_dev_update_filters(hw);
 }

 /* Allmulticast supported only if Vmxnet3_DriverShared is initialized in 
adapter */
@@ -726,6 +747,74 @@ vmxnet3_dev_allmulticast_disable(struct rte_eth_dev *dev)
vmxnet3_dev_set_rxmode(hw, VMXNET3_RXM_ALL_MULTI, 0);
 }

+/* Enable/disable filter on vlan */
+static int
+vmxnet3_dev_vlan_filter_set(struct 

[dpdk-dev] [PATCH 0/7] vmxnet3: driver enhancements

[Stephen Hemminger]

This set of patches updates the vmxnet3 in the DPDK to match
the features in the driver I wrote. The most important critical
feature is support for multi-segment jumbo frames.

Stephen Hemminger (7):
  vmxnet3: add support for VLAN filtering
  vmxnet3: remove mtu check
  vmxnet3: add support for mulit-segment transmit
  vmxnet3: fix link state handling
  vmxnet3: get rid of DEBUG ifdefs
  vmxnet3: support RSS and refactor offload
  vmxnet3: support jumbo frames

 lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c | 163 ++---
 lib/librte_pmd_vmxnet3/vmxnet3_ethdev.h |   9 +-
 lib/librte_pmd_vmxnet3/vmxnet3_ring.h   |   2 +
 lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c   | 306 +---
 4 files changed, 265 insertions(+), 215 deletions(-)

-- 
2.1.3

[dpdk-dev] [PATCH v2] mk: link combined shared lib using CC

[Thomas Monjalon]

2014-10-28 15:48, Sergio Gonzalez Monroy:
> If we set EXTRA_CFLAGS=-O0, build fails with following error:
> 
> /usr/bin/ld: test: hidden symbol `mknod' in 
> /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO
> 
> Fix: link combined shared lib using CC if LINK_USING_CC is enabled.
> 
> Signed-off-by: Sergio Gonzalez Monroy 
> ---
>  mk/rte.lib.mk  |  1 -
>  mk/rte.sharelib.mk | 12 +++-
[...]
> --- a/mk/rte.lib.mk
> +++ b/mk/rte.lib.mk
> @@ -63,7 +63,6 @@ ifeq ($(LINK_USING_CC),1)
>  # Override the definition of LD here, since we're linking with CC
>  LD := $(CC)
>  LD_MULDEFS := $(call linkerprefix,-z$(comma)muldefs)
> -CPU_LDFLAGS := $(call linkerprefix,$(CPU_LDFLAGS))
>  endif

Why are you removing this line?

> --- a/mk/rte.sharelib.mk
> +++ b/mk/rte.sharelib.mk
[...]

[dpdk-dev] Fwd: FOSDEM conference - call for participation

[Stephen Hemminger]

On Fri, 31 Oct 2014 15:53:19 -0700 (PDT)
Thomas Monjalon  wrote:

> Hi,
> 
> Talks related to DPDK can be proposed for FOSDEM 2015:
>   https://fosdem.org/2015/
> This conference will take place in Belgium on 31 January & 1 February.
> 

Did DPDK make it in the schedule or not?

[dpdk-dev] [PATCH] lib/librte_table: Fix table array lookup

[Thomas Monjalon]

Cristian, this patch is about packet framework.
Could you review it please?

2014-12-12 17:06, Mark Wunderlich:
> The existing lookup function was returning an unmodified
> pkts_mask bitmask into lookup_hit_mask.  This effectively
> assumes that all packets would index correctly into one
> of the array table entries.
> 
> Also, there was no check that the metadata provided index
> value was within range of the table max entries.  By using
> using table index bitmask on the metadata provided index
> the resulting entry position may falsely indicate a hit
> for index values provided that happen to be greter than
> the number of table entries.
> 
> Like other table type lookup functions it would seem that
> the possibility exists that some of the packets provided
> to the function would not result in a hit.  It is assumed
> that the metadata provided should be a direct index into
> the array table.  So, code was added to build and return
> a bitmask for only those packets that correctly index
> directly into the table array.
> 
> If the original intent for this table type was to accept
> any 32-bit value, then by applying the table index bitmask
> as a modulo index for distribution across table entries,
> then this patch would be invalid and should be rejected.
> 
> Signed-off-by: Mark Wunderlich 
> ---
>  lib/librte_table/rte_table_array.c |   25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)

[dpdk-dev] [PATCH] replaced O(n^2) sort in sort_by_physaddr() with qsort() from standard library

[Ananyev, Konstantin]

Hi Jay,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> Sent: Thursday, December 11, 2014 4:06 PM
> To: Dev
> Subject: [dpdk-dev] [PATCH] replaced O(n^2) sort in sort_by_physaddr() with 
> qsort() from standard library
> 
> Signed-off-by: Jay Rolette 

The patch itself looks good to me.
Though it seems something wrong with formatting - all lines start with offset 0.
Probably your mail client?
Konstantin


> ---
>  lib/librte_eal/linuxapp/eal/eal_memory.c | 59
> +++-
>  1 file changed, 20 insertions(+), 39 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index bae2507..3656515 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -670,6 +670,25 @@ error:
>   return -1;
>  }
> 
> +static int
> +cmp_physaddr(const void *a, const void *b)
> +{
> +#ifndef RTE_ARCH_PPC_64
> + const struct hugepage_file *p1 = (const struct hugepage_file *)a;
> + const struct hugepage_file *p2 = (const struct hugepage_file *)b;
> +#else
> + // PowerPC needs memory sorted in reverse order from x86
> + const struct hugepage_file *p1 = (const struct hugepage_file *)b;
> + const struct hugepage_file *p2 = (const struct hugepage_file *)a;
> +#endif
> + if (p1->physaddr < p2->physaddr)
> + return -1;
> + else if (p1->physaddr > p2->physaddr)
> + return 1;
> + else
> + return 0;
> +}
> +
>  /*
>   * Sort the hugepg_tbl by physical address (lower addresses first on x86,
>   * higher address first on powerpc). We use a slow algorithm, but we won't
> @@ -678,45 +697,7 @@ error:
>  static int
>  sort_by_physaddr(struct hugepage_file *hugepg_tbl, struct hugepage_info
> *hpi)
>  {
> - unsigned i, j;
> - int compare_idx;
> - uint64_t compare_addr;
> - struct hugepage_file tmp;
> -
> - for (i = 0; i < hpi->num_pages[0]; i++) {
> - compare_addr = 0;
> - compare_idx = -1;
> -
> - /*
> - * browse all entries starting at 'i', and find the
> - * entry with the smallest addr
> - */
> - for (j=i; j< hpi->num_pages[0]; j++) {
> -
> - if (compare_addr == 0 ||
> -#ifdef RTE_ARCH_PPC_64
> - hugepg_tbl[j].physaddr > compare_addr) {
> -#else
> - hugepg_tbl[j].physaddr < compare_addr) {
> -#endif
> - compare_addr = hugepg_tbl[j].physaddr;
> - compare_idx = j;
> - }
> - }
> -
> - /* should not happen */
> - if (compare_idx == -1) {
> - RTE_LOG(ERR, EAL, "%s(): error in physaddr sorting\n", __func__);
> - return -1;
> - }
> -
> - /* swap the 2 entries in the table */
> - memcpy(, _tbl[compare_idx],
> - sizeof(struct hugepage_file));
> - memcpy(_tbl[compare_idx], _tbl[i],
> - sizeof(struct hugepage_file));
> - memcpy(_tbl[i], , sizeof(struct hugepage_file));
> - }
> + qsort(hugepg_tbl, hpi->num_pages[0], sizeof(struct hugepage_file),
> cmp_physaddr);
>   return 0;
>  }
> 
> --

[dpdk-dev] [PATCH v2] bond: static analysis issues fix

[Thomas Monjalon]

2014-12-15 17:13, Declan Doherty:
> -v2:
> Incorporates Pawel's comments regarding assertion's check on activate_slave 
> array indexing

Changelog should be below three dashes to be excluded from git history.

> Fixes for link bonding library identified by static analysis tool
> 
> - Overflow assert for active_slaves array in activate_slave function
> - Allocation check of pci_id_table in rte_eth_bond_create
> - Use of eth_dev pointer in mac_address_get/set before NULL check

Please send 3 patches. 1 bug = 1 fix with its explanation.
The main advantage is to help referencing regressions.

> Signed-off-by: Declan Doherty 
[...]
> --- a/lib/librte_pmd_bond/rte_eth_bond_api.c
> +++ b/lib/librte_pmd_bond/rte_eth_bond_api.c
> @@ -115,8 +115,12 @@ activate_slave(struct rte_eth_dev *eth_dev, uint8_t 
> port_id)
>   if (internals->mode == BONDING_MODE_8023AD)
>   bond_mode_8023ad_activate_slave(eth_dev, port_id);
>  
> + RTE_VERIFY(internals->active_slave_count <
> + (RTE_DIM(internals->active_slaves) - 1));
> +
>   internals->active_slaves[internals->active_slave_count] = port_id;
>   internals->active_slave_count++;
> +
>  }

Why a blank line here?

-- 
Thomas

[dpdk-dev] [PATCH] ring: Fix return type in enqueue and dequeue burst functions

[Olivier MATZ]

Hi Pablo,

On 12/15/2014 02:41 PM, Pablo de Lara wrote:
> Enqueue and dequeue burst functions always return a positive
> value (including 0), so return type should be unsigned,
> instead of int.
>
> Fixed also API doc for one of the functions.
>
> Signed-off-by: Pablo de Lara 

Acked-by: Olivier Matz 

[dpdk-dev] [PATCH v3] librte_pmd_null: Add null PMD

[Tetsuya Mukawa]

(2014/12/16 17:47), Thomas Monjalon wrote:
> 2014-12-16 17:44, Tetsuya Mukawa:
>> I've updated the null PMD to apply it to latest DPDK.
>> Also I've sent a port hotplug patch for null PMD.
> As explained in http://dpdk.org/dev#send, do not hesitate to
> use --annotate to add this kind of changelog when sending patch.
> Example:
>   http://dpdk.org/ml/archives/dev/2014-December/010060.html
>
> Thanks

Thanks, I will do it next time.

Regards,
Tetsuya

[dpdk-dev] [PATCH v3] librte_pmd_null: Add null PMD

[Tetsuya Mukawa]

I've updated the null PMD to apply it to latest DPDK.
Also I've sent a port hotplug patch for null PMD.

Thanks,
Tetsuya

(2014/12/16 17:39), Tetsuya Mukawa wrote:
> 'null PMD' is a driver of the virtual device particulary designed to measure
> performance of DPDK PMDs. When an application call rx, null PMD just allocates
> mbufs and returns those. Also tx, the PMD just frees mbufs.
>
> The PMD has following options.
> - size: specify packe size allocated by RX. Default packet size is 64.
> - copy: specify 1 or 0 to enable or disable copy while RX and TX.
>   Default value is 0(disbaled).
>   This option is used for emulating more realistic data transfer.
>   Copy size is equal to packet size.
>
> To use the PMD, enable CONFIG_RTE_BUILD_SHARED_LIB in config file. Then
> compile the PMD as shared library. The library can be linked using '-d'
> option when an application invokes.
>
> Here is an example.
> $ sudo ./testpmd -c f -n 4 -d librte_pmd_null.so \
>   --vdev 'eth_null0' --vdev 'eth_null1' -- -i
>
> If testpmd is compiled with CONFIG_RTE_BUILD_SHARED_LIB, it may need to
> specify more libraries using '-d' option.
>
> Signed-off-by: Tetsuya Mukawa 
> ---
>  config/common_bsdapp   |   5 +
>  config/common_linuxapp |   5 +
>  lib/Makefile   |   1 +
>  lib/librte_pmd_null/Makefile   |  58 +
>  lib/librte_pmd_null/rte_eth_null.c | 474 
> +
>  5 files changed, 543 insertions(+)
>  create mode 100644 lib/librte_pmd_null/Makefile
>  create mode 100644 lib/librte_pmd_null/rte_eth_null.c
>
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index 9177db1..fa849be 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -224,6 +224,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=y
>  CONFIG_RTE_LIBRTE_PMD_BOND=y
>  
>  #
> +# Compile null PMD
> +#
> +CONFIG_RTE_LIBRTE_PMD_NULL=y
> +
> +#
>  # Do prefetch of packet data within PMD driver receive function
>  #
>  CONFIG_RTE_PMD_PACKET_PREFETCH=y
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 2f9643b..808574a 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -232,6 +232,11 @@ CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
>  CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
>  
>  #
> +# Compile null PMD
> +#
> +CONFIG_RTE_LIBRTE_PMD_NULL=y
> +
> +#
>  # Do prefetch of packet data within PMD driver receive function
>  #
>  CONFIG_RTE_PMD_PACKET_PREFETCH=y
> diff --git a/lib/Makefile b/lib/Makefile
> index 0ffc982..d246c53 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -52,6 +52,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += librte_pmd_virtio
>  DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += librte_pmd_vmxnet3
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += librte_pmd_xenvirt
>  DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
> +DIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += librte_pmd_null
>  DIRS-$(CONFIG_RTE_LIBRTE_HASH) += librte_hash
>  DIRS-$(CONFIG_RTE_LIBRTE_LPM) += librte_lpm
>  DIRS-$(CONFIG_RTE_LIBRTE_ACL) += librte_acl
> diff --git a/lib/librte_pmd_null/Makefile b/lib/librte_pmd_null/Makefile
> new file mode 100644
> index 000..0ec4db9
> --- /dev/null
> +++ b/lib/librte_pmd_null/Makefile
> @@ -0,0 +1,58 @@
> +#   BSD LICENSE
> +#
> +#   Copyright (C) IGEL Co.,Ltd.
> +#   All rights reserved.
> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +#   notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +#   notice, this list of conditions and the following disclaimer in
> +#   the documentation and/or other materials provided with the
> +#   distribution.
> +# * Neither the name of IGEL Co.,Ltd. nor the names of its
> +#   contributors may be used to endorse or promote products derived
> +#   from this software without specific prior written permission.
> +#
> +#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> +#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +#
> +# 

[dpdk-dev] [PATCH] librte_pmd_null: Suport port hotplug function

[Tetsuya Mukawa]

The patch is for adding port hotplug funcion to null PMD.

Signed-off-by: Tetsuya Mukawa 
---
 lib/librte_pmd_null/rte_eth_null.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/lib/librte_pmd_null/rte_eth_null.c 
b/lib/librte_pmd_null/rte_eth_null.c
index 7ecdd17..67fd5a1 100644
--- a/lib/librte_pmd_null/rte_eth_null.c
+++ b/lib/librte_pmd_null/rte_eth_null.c
@@ -292,6 +292,13 @@ eth_stats_reset(struct rte_eth_dev *dev)
}
 }

+static struct eth_driver rte_null_pmd = {
+   .pci_drv = {
+   .name = "rte_null_pmd",
+   .drv_flags = RTE_PCI_DRV_DETACHABLE,
+   },
+};
+
 static void
 eth_queue_release(void *q __rte_unused) { ; }
 static int
@@ -371,10 +378,12 @@ eth_dev_null_create(const char *name __rte_unused,
data->nb_tx_queues = (uint16_t)nb_tx_queues;
data->dev_link = pmd_link;
data->mac_addrs = _addr;
+   strncpy(data->name, eth_dev->data->name, strlen(eth_dev->data->name));

eth_dev->data = data;
eth_dev->dev_ops = 
eth_dev->pci_dev = pci_dev;
+   eth_dev->driver = _null_pmd;

/* finally assign rx and tx ops */
if (packet_copy) {
@@ -465,10 +474,33 @@ rte_pmd_null_devinit(const char *name, const char *params)
return eth_dev_null_create(name, numa_node, packet_size, packet_copy);
 }

+static int
+rte_pmd_null_devclose(const char *name, const char *params __rte_unused)
+{
+   struct rte_eth_dev *eth_dev = NULL;
+
+   RTE_LOG(INFO, PMD, "Closing null ethdev on numa socket %u\n",
+   rte_socket_id());
+
+   /* reserve an ethdev entry */
+   eth_dev = rte_eth_dev_allocated(name);
+   if (eth_dev == NULL)
+   return -1;
+
+   rte_free(eth_dev->data->dev_private);
+   rte_free(eth_dev->data);
+   rte_free(eth_dev->pci_dev);
+
+   rte_eth_dev_free(name);
+
+   return 0;
+}
+
 static struct rte_driver pmd_null_drv = {
.name = "eth_null",
.type = PMD_VDEV,
.init = rte_pmd_null_devinit,
+   .close = rte_pmd_null_devclose,
 };

 PMD_REGISTER_DRIVER(pmd_null_drv);
-- 
1.9.1

[dpdk-dev] [PATCH v3] librte_pmd_null: Add null PMD

[Tetsuya Mukawa]

'null PMD' is a driver of the virtual device particulary designed to measure
performance of DPDK PMDs. When an application call rx, null PMD just allocates
mbufs and returns those. Also tx, the PMD just frees mbufs.

The PMD has following options.
- size: specify packe size allocated by RX. Default packet size is 64.
- copy: specify 1 or 0 to enable or disable copy while RX and TX.
Default value is 0(disbaled).
This option is used for emulating more realistic data transfer.
Copy size is equal to packet size.

To use the PMD, enable CONFIG_RTE_BUILD_SHARED_LIB in config file. Then
compile the PMD as shared library. The library can be linked using '-d'
option when an application invokes.

Here is an example.
$ sudo ./testpmd -c f -n 4 -d librte_pmd_null.so \
--vdev 'eth_null0' --vdev 'eth_null1' -- -i

If testpmd is compiled with CONFIG_RTE_BUILD_SHARED_LIB, it may need to
specify more libraries using '-d' option.

Signed-off-by: Tetsuya Mukawa 
---
 config/common_bsdapp   |   5 +
 config/common_linuxapp |   5 +
 lib/Makefile   |   1 +
 lib/librte_pmd_null/Makefile   |  58 +
 lib/librte_pmd_null/rte_eth_null.c | 474 +
 5 files changed, 543 insertions(+)
 create mode 100644 lib/librte_pmd_null/Makefile
 create mode 100644 lib/librte_pmd_null/rte_eth_null.c

diff --git a/config/common_bsdapp b/config/common_bsdapp
index 9177db1..fa849be 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -224,6 +224,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=y
 CONFIG_RTE_LIBRTE_PMD_BOND=y

 #
+# Compile null PMD
+#
+CONFIG_RTE_LIBRTE_PMD_NULL=y
+
+#
 # Do prefetch of packet data within PMD driver receive function
 #
 CONFIG_RTE_PMD_PACKET_PREFETCH=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2f9643b..808574a 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -232,6 +232,11 @@ CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_PMD_XENVIRT=n

 #
+# Compile null PMD
+#
+CONFIG_RTE_LIBRTE_PMD_NULL=y
+
+#
 # Do prefetch of packet data within PMD driver receive function
 #
 CONFIG_RTE_PMD_PACKET_PREFETCH=y
diff --git a/lib/Makefile b/lib/Makefile
index 0ffc982..d246c53 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -52,6 +52,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += librte_pmd_virtio
 DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += librte_pmd_vmxnet3
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += librte_pmd_xenvirt
 DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += librte_pmd_null
 DIRS-$(CONFIG_RTE_LIBRTE_HASH) += librte_hash
 DIRS-$(CONFIG_RTE_LIBRTE_LPM) += librte_lpm
 DIRS-$(CONFIG_RTE_LIBRTE_ACL) += librte_acl
diff --git a/lib/librte_pmd_null/Makefile b/lib/librte_pmd_null/Makefile
new file mode 100644
index 000..0ec4db9
--- /dev/null
+++ b/lib/librte_pmd_null/Makefile
@@ -0,0 +1,58 @@
+#   BSD LICENSE
+#
+#   Copyright (C) IGEL Co.,Ltd.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of IGEL Co.,Ltd. nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_null.a
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += rte_eth_null.c
+
+#
+# Export include files
+#
+SYMLINK-y-include +=
+
+# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += lib/librte_ether

[dpdk-dev] [PATCH] examples/vhost: Fix vlan offload issue

[Thomas Monjalon]

2014-12-12 12:15, Ouyang Changchun:
> The following commit break vm2vm hard mode test cases:
> commit db4014f2b65cb31bf209cadd5bcec778ca137fe2
> Author: Huawei Xie 
> Date:   Thu Nov 13 06:34:07 2014 +0800
> examples/vhost: use factorized default Rx/Tx configuration
> 
> Investigation show that it needs enabling vlan offload since it is turn off 
> by default,
> and Tx need it, especially when vm2vm is in hard mode.

I missed something here. Where VLAN offload is disabled by default?
Could you point the code, please?

> --- a/examples/vhost/main.c
> +++ b/examples/vhost/main.c
> @@ -390,6 +390,9 @@ port_init(uint8_t port)
>   txconf = _info.default_txconf;
>   rxconf->rx_drop_en = 1;
>  
> + /* Enable vlan offload */
> + txconf->txq_flags &= ~ETH_TXQ_FLAGS_NOVLANOFFL;
> +
>   /*
>* Zero copy defers queue RX/TX start to the time when guest
>* finishes its startup and packet buffers from that guest are
> 

[dpdk-dev] Building 1.7.1 or 1.8.0-rc4 on latest CentOS 6.6 fails

[Barak Enat]

Hi



When building 1.7.1 or 1.8.0-rc4 on recent CentOS 6 (6.6) I got this error:



In file included from
/home/makerpm/rpmbuild/BUILD/dpdk-1.8.0/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h:41,

 from
/home/makerpm/rpmbuild/BUILD/dpdk-1.8.0/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_hw.h:31,

 from
/home/makerpm/rpmbuild/BUILD/dpdk-1.8.0/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_api.h:31,

 from
/home/makerpm/rpmbuild/BUILD/dpdk-1.8.0/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.c:38:

/home/makerpm/rpmbuild/BUILD/dpdk-1.8.0/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3870:
error: conflicting types for 'skb_set_hash'

include/linux/skbuff.h:620: note: previous definition of 'skb_set_hash' was
here

make[8]: ***
[/home/makerpm/rpmbuild/BUILD/dpdk-1.8.0/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.o]
Error 1



It seems the assumption that skb_set_hash is missing in CentOS prior to
version 7 is not valid anymore.

Didn't see a fix of it in trunk or in the patches.



Thanks,

Barak

[dpdk-dev] [PATCH] l3fwd-acl: fix possible memory leak.

[Konstantin Ananyev]

At error app_acl_init() can return without freeing dynamically allocated memory.
Not really a big problem, as if app_acl_init() fails,
then application would terminate immediately anyway.
Though it is a good coding practise to make a function to cleanup after itself.

Signed-off-by: Konstantin Ananyev 
---
 examples/l3fwd-acl/main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c
index 4487c95..022ccab 100644
--- a/examples/l3fwd-acl/main.c
+++ b/examples/l3fwd-acl/main.c
@@ -1247,6 +1247,10 @@ app_acl_init(void)
acl_log("Socket %d of lcore %u is out "
"of range %d\n",
socketid, lcore_id, NB_SOCKETS);
+   free(route_base_ipv4);
+   free(route_base_ipv6);
+   free(acl_base_ipv4);
+   free(acl_base_ipv6);
return -1;
}

-- 
1.8.5.3

[dpdk-dev] mk: fix app linking for combined libs

[Thomas Monjalon]

2014-12-08 09:53, Neil Horman:
> On Thu, Oct 23, 2014 at 04:36:44PM +0100, Sergio Gonzalez Monroy wrote:
> > Building combined shared libraries results in applications being linked
> > against separeted/individual and combined libs altogether.
> > 
> > Link only against combined lib when the config option is enabled.
> > 
> > Signed-off-by: Sergio Gonzalez Monroy 
> > Acked-by: Pablo de Lara 
[...]
> Acked-by: Neil Horman 

Neil, I didn't noticed your ack which happened after a discussion I had with
Sergio. He agreed to make a v2.
Actually Hiroshi did it:
http://dpdk.org/ml/archives/dev/2014-December/009847.html
I'm going to apply Hiroshi's one.

-- 
Thomas

[dpdk-dev] [PATCH v2] testpmd: limit port mask bits to RTE_MAX_ETHPORTS

[Neil Horman]

On Tue, Dec 16, 2014 at 02:39:44PM +, Bruce Richardson wrote:
> The port mask parsing in testpmd allowed up to 64 bits to be processed,
> even if RTE_MAX_ETHPORTS is set to a max of 32. Fix this by only
> processing up to min(RTE_MAX_ETHPORTS,64) bits of the mask.
> 
> Signed-off-by: Bruce Richardson 
> ---
> V2: changed to use RTE_MIN in comparison, instead of double "<".
> ---
>  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 69a83c2..97b6525 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -1440,7 +1440,7 @@ set_fwd_ports_mask(uint64_t portmask)
>   return;
>   }
>   nb_pt = 0;
> - for (i = 0; i < 64; i++) {
> + for (i = 0; i < (unsigned)RTE_MIN(64, RTE_MAX_ETHPORTS); i++) {
>   if (! ((uint64_t)(1ULL << i) & portmask))
>   continue;
>   portlist[nb_pt++] = i;
> -- 
> 1.9.3
> 
> 

I was thinking of assigning a new temp variable to the return of RTE_MIN so as
to avoid the comparison within the for loop, but since both arguments are
constant, I'm sure the compiler will avoid multiple comparisons.

Acked-by: Neil Horman 

[dpdk-dev] [PATCH v2] mk: fix build with shared pcap pmd

[Neil Horman]

On Tue, Dec 16, 2014 at 03:39:56PM +0100, Thomas Monjalon wrote:
> 2014-12-16 08:58, Neil Horman:
> > On Tue, Dec 16, 2014 at 12:04:44AM +0100, Thomas Monjalon wrote:
> > > Some applications doesn't have the pcap link flag
> > > when shared libraries are enabled.
> > > Indeed in such case, pcap PMD must not be linked but pcap library should.
> > > 
> > > Actually -lpcap is always needed if pcap PMD is used,
> > > and -lrte_pmd_pcap must be set only with static PMD library.
> > > So the flags -lrte_pmd_pcap and -lpcap are enabled separately.
> > > 
> > > Workarounds in test-pmd/ and test-pipeline/ can be removed.
> > > 
> > > Reported-by: Stepan Sojka 
> > > Signed-off-by: Thomas Monjalon 
> [...]
> > > --- a/mk/rte.app.mk
> > > +++ b/mk/rte.app.mk
> > > @@ -119,6 +119,10 @@ LDLIBS += -lm
> > >  LDLIBS += -lrt
> > >  endif
> > >  
> > > +ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
> > > +LDLIBS += -lpcap
> > > +endif
> > > +
> > >  LDLIBS += --start-group
> > >  
> > >  ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
> > > @@ -207,7 +211,7 @@ LDLIBS += -lrte_pmd_ring
> > >  endif
> > >  
> > >  ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
> > > -LDLIBS += -lrte_pmd_pcap -lpcap
> > > +LDLIBS += -lrte_pmd_pcap
> > >  endif
> > >  
> > >  ifeq ($(CONFIG_RTE_LIBRTE_PMD_AF_PACKET),y)
> > 
> > Actually, what if we just add $(LDFLAGS) to the O_TO_S rule in 
> > mk/rte.lib.mk?
> > Then in lib/librte_pmd_pcap/Makefile, we can just add LDFLAGS+=-lpcap, and 
> > the
> > loading of the pcap pmd will itself require the loading of libpcap.  That 
> > would
> > be a nice clean implementation that allows applications to just link the 
> > pmd and
> > not have to worry about dependencies.  It would also allow us to clean up 
> > other
> > dependencies like the xenvirt pmd and vhost.
> 
> Yes it makes sense. Could you test it please?
> What about applying my patch (which keep the existing logic) as a first
> fix/clean-up and then move -lpcap in PMD as a second step?
> Proceeding this way would allow to integrate a safe fix for 1.8.0.
> Maybe that linking pcap in the PMD could unveil new bugs with some 
> distributions,
> so it would need some time to validate it.
> 
> -- 
> Thomas
> 
ACK, I'm fine with your patch currently.  I'll revisit this after 1.8 is
released
Neil

[dpdk-dev] [PATCH] Minor fixes in rte_common.h file.

[Neil Horman]

On Tue, Dec 16, 2014 at 08:46:51AM -0800, Ravi Kerur wrote:
> On Sat, Dec 13, 2014 at 2:39 AM, Neil Horman  wrote:
> >
> > On Fri, Dec 12, 2014 at 03:04:34PM -0800, r k wrote:
> > > Subject: [PATCH] Minor fixes in rte_common.h file.
> > >
> > > Fix rte_is_power_of_2 since 0 is not.
> > > Avoid branching instructions in RTE_MAX and RTE_MIN.
> > >
> > > Signed-off-by: Ravi Kerur 
> > > ---
> > >  lib/librte_eal/common/include/rte_common.h | 6 +++---
> > >  lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
> > >  lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
> > >  3 files changed, 7 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/common/include/rte_common.h
> > > b/lib/librte_eal/common/include/rte_common.h
> > > index 921b91f..e163f35 100644
> > > --- a/lib/librte_eal/common/include/rte_common.h
> > > +++ b/lib/librte_eal/common/include/rte_common.h
> > > @@ -203,7 +203,7 @@ extern int RTE_BUILD_BUG_ON_detected_error;  static
> > > inline int  rte_is_power_of_2(uint32_t n)  {
> > > -   return ((n-1) & n) == 0;
> > > +   return n && !(n & (n - 1));
> > >  }
> > >
> > >  /**
> > > @@ -259,7 +259,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MIN(a, b)
> > ({ \
> > > typeof (a) _a = (a); \
> > > typeof (b) _b = (b); \
> > > -   _a < _b ? _a : _b; \
> > > +_b ^ ((_a ^ _b) & -(_a < _b)); \
> > Are you sure this is actually faster than the branch version?  What about
> > using
> > a cmov instead?
> >
> >
>  i am pretty sure modified code is faster than branching. I remember
> cmov had performance issues esp. on Pentuim-4 not sure how new intel cpu's
> perform.
> 
Pretty sure isn't sure.  Theres no point in code churn if theres no obvious
advantage.  Some perf tests to deomonstrate the advantage here would be great.

> > })
> > >
> > >  /**
> > > @@ -268,7 +268,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MAX(a, b)
> > ({ \
> > > typeof (a) _a = (a); \
> > > typeof (b) _b = (b); \
> > > -   _a > _b ? _a : _b; \
> > > +   _a ^ ((_a ^ _b) & -(_a < _b)); \
> > Same as above
> >
> >  Same as above.
> 
> > > })
> > >
> > >  /*** Other general functions / macros / diff --git
> > > a/lib/librte_pmd_e1000/igb_pf.c b/lib/librte_pmd_e1000/igb_pf.c index
> > > bc3816a..546499c 100644
> > > --- a/lib/librte_pmd_e1000/igb_pf.c
> > > +++ b/lib/librte_pmd_e1000/igb_pf.c
> > > @@ -321,11 +321,11 @@ igb_vf_set_mac_addr(struct rte_eth_dev *dev,
> > uint32_t
> > > vf, uint32_t *msgbuf)  static int  igb_vf_set_multicast(struct
> > rte_eth_dev
> > > *dev, __rte_unused uint32_t vf, uint32_t *msgbuf)  {
> > > -   int i;
> > > +   int16_t i;
> > > uint32_t vector_bit;
> > > uint32_t vector_reg;
> > > uint32_t mta_reg;
> > > -   int entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
> > > +   int32_t entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
> > > E1000_VT_MSGINFO_SHIFT;
> > NAK, this has nothing to do with the included changelog
> >
> 
>  It does, it causes compilation errors such as
> 
> /root/dpdk-new/dpdk/lib/librte_pmd_e1000/igb_pf.c: In function
> \u2018igb_pf_mbx_process\u2019:
> /root/dpdk-new/dpdk/lib/librte_pmd_e1000/igb_pf.c:350:23: error: array
> subscript is above array bounds [-Werror=array-bounds]
>vfinfo->vf_mc_hashes[i] = hash_list[i];
>^
> cc1: all warnings being treated as errors
> 
> Also it is always better to use explicit int definitions esp. for 64bit
> systems.
> 

This is your changelog:
=
Subject: [PATCH] Minor fixes in rte_common.h file.

Fix rte_is_power_of_2 since 0 is not.
Avoid branching instructions in RTE_MAX and RTE_MIN
=

Nowhere does your changelog indicate that you are fixing compliation errors.
That would in and of itself be far more serious that making micro optimizations.
If you want to fix build breaks, great, please do, but send a patch that clearly
indicates what the break is and how your fixing it. Don't just toss it in with
whatever other work you happen to be doing.

[dpdk-dev] [PATCH 2/3] ixgbe: prevent array overflow access in vector driver

[Bruce Richardson]

Switch the order of the conditions in a while loop, so we check the
range of "i" against the max, before using it to index into the array.

Signed-off-by: Bruce Richardson 
---
 lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
index 3a30fa7..b54cb19 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
@@ -489,7 +489,7 @@ ixgbe_recv_scattered_pkts_vec(void *rx_queue, struct 
rte_mbuf **rx_pkts,
unsigned i = 0;
if (rxq->pkt_first_seg == NULL) {
/* find the first split flag, and only reassemble then*/
-   while (!split_flags[i] && i < nb_bufs)
+   while (i < nb_bufs && !split_flags[i])
i++;
if (i == nb_bufs)
return nb_bufs;
-- 
1.9.3

[dpdk-dev] [PATCH 1/3] af_packet: ensure *internals is not null when dereferencing

[Bruce Richardson]

The cleanup code on error checks for *internals being NULL only after
using the pointer to perform other cleanup. Fix this by moving the
clean-up based on the pointer inside the check for NULL.

Signed-off-by: Bruce Richardson 
---
 lib/librte_pmd_af_packet/rte_eth_af_packet.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/librte_pmd_af_packet/rte_eth_af_packet.c 
b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
index d0fb3eb..ad7242c 100644
--- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
+++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
@@ -676,14 +676,15 @@ error:
rte_free(data);
if (pci_dev)
rte_free(pci_dev);
-   for (q = 0; q < nb_queues; q++) {
-   if ((*internals)->rx_queue[q].rd)
-   rte_free((*internals)->rx_queue[q].rd);
-   if ((*internals)->tx_queue[q].rd)
-   rte_free((*internals)->tx_queue[q].rd);
-   }
-   if (*internals)
+   if (*internals) {
+   for (q = 0; q < nb_queues; q++) {
+   if ((*internals)->rx_queue[q].rd)
+   rte_free((*internals)->rx_queue[q].rd);
+   if ((*internals)->tx_queue[q].rd)
+   rte_free((*internals)->tx_queue[q].rd);
+   }
rte_free(*internals);
+   }
return -1;
 }

-- 
1.9.3

[dpdk-dev] [PATCH 0/3] (More) Fixes for issues highlighted by static analysis

[Bruce Richardson]

A further three small patches fixing more issues highlighted by static 
analysis scans.

Bruce Richardson (3):
  af_packet: ensure *internals is not null when dereferencing
  ixgbe: prevent array overflow access in vector driver
  eal: for safety, use snprintf instead of sprintf

 lib/librte_eal/common/include/rte_version.h  |  4 ++--
 lib/librte_pmd_af_packet/rte_eth_af_packet.c | 15 ---
 lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c|  2 +-
 3 files changed, 11 insertions(+), 10 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH v3] i40e: workaround for X710 performance issues

[Helin Zhang]

On X710, performance number is far from the expectation on recent
firmware versions. The fix for this issue may not be integrated in
the following firmware version. So the workaround in software driver
is needed. It needs to modify the initial values of 3 internal only
registers. Note that the workaround can be removed when it is fixed
in firmware in the future.

Signed-off-by: Helin Zhang 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 89 +++
 1 file changed, 89 insertions(+)

v2 changes:
* Added a compile error fix.

v3 changes:
* Used PRIx32 and PRIx64 instead for printing uint32_t and uint64_t
  variables.
* Re-worded annotations, and commit logs.

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 008d62c..624f0ce 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -198,6 +198,7 @@ static int i40e_dev_filter_ctrl(struct rte_eth_dev *dev,
enum rte_filter_type filter_type,
enum rte_filter_op filter_op,
void *arg);
+static void i40e_configure_registers(struct i40e_hw *hw);

 /* Default hash key buffer for RSS */
 static uint32_t rss_key_default[I40E_PFQF_HKEY_MAX_INDEX + 1];
@@ -443,6 +444,16 @@ eth_i40e_dev_init(__rte_unused struct eth_driver *eth_drv,
/* Clear PXE mode */
i40e_clear_pxe_mode(hw);

+   /*
+* On X710, performance number is far from the expectation on recent
+* firmware versions. The fix for this issue may not be integrated in
+* the following firmware version. So the workaround in software driver
+* is needed. It needs to modify the initial values of 3 internal only
+* registers. Note that the workaround can be removed when it is fixed
+* in firmware in the future.
+*/
+   i40e_configure_registers(hw);
+
/* Get hw capabilities */
ret = i40e_get_cap(hw);
if (ret != I40E_SUCCESS) {
@@ -5294,3 +5305,81 @@ i40e_pctype_to_flowtype(enum i40e_filter_pctype pctype)

return flowtype_table[pctype];
 }
+
+static int
+i40e_debug_read_register(struct i40e_hw *hw, uint32_t addr, uint64_t *val)
+{
+   struct i40e_aq_desc desc;
+   struct i40e_aqc_debug_reg_read_write *cmd =
+   (struct i40e_aqc_debug_reg_read_write *)
+   enum i40e_status_code status;
+
+   i40e_fill_default_direct_cmd_desc(, i40e_aqc_opc_debug_read_reg);
+   cmd->address = rte_cpu_to_le_32(addr);
+   status = i40e_asq_send_command(hw, , NULL, 0, NULL);
+   if (status < 0)
+   return status;
+
+   *val = ((uint64_t)(rte_le_to_cpu_32(cmd->value_high)) << (CHAR_BIT *
+   sizeof(uint32_t))) + rte_le_to_cpu_32(cmd->value_low);
+
+   return status;
+}
+
+/*
+ * On X710, performance number is far from the expectation on recent firmware
+ * versions. The fix for this issue may not be integrated in the following
+ * firmware version. So the workaround in software driver is needed. It needs
+ * to modify the initial values of 3 internal only registers. Note that the
+ * workaround can be removed when it is fixed in firmware in the future.
+ */
+static void
+i40e_configure_registers(struct i40e_hw *hw)
+{
+#define I40E_GL_SWR_PRI_JOIN_MAP_0   0x26CE00
+#define I40E_GL_SWR_PRI_JOIN_MAP_2   0x26CE08
+#define I40E_GL_SWR_PM_UP_THR0x269FBC
+#define I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE 0x1200
+#define I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE 0x011f0200
+#define I40E_GL_SWR_PM_UP_THR_VALUE  0x03030303
+
+   static const struct {
+   uint32_t addr;
+   uint64_t val;
+   } reg_table[] = {
+   {I40E_GL_SWR_PRI_JOIN_MAP_0, I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE},
+   {I40E_GL_SWR_PRI_JOIN_MAP_2, I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE},
+   {I40E_GL_SWR_PM_UP_THR, I40E_GL_SWR_PM_UP_THR_VALUE},
+   };
+   uint64_t reg;
+   uint32_t i;
+   int ret;
+
+   /* Below fix is for X710 only */
+   if (i40e_is_40G_device(hw->device_id))
+   return;
+
+   for (i = 0; i < RTE_DIM(reg_table); i++) {
+   ret = i40e_debug_read_register(hw, reg_table[i].addr, );
+   if (ret < 0) {
+   PMD_DRV_LOG(ERR, "Failed to read from 0x%"PRIx32,
+   reg_table[i].addr);
+   break;
+   }
+   PMD_DRV_LOG(DEBUG, "Read from 0x%"PRIx32": 0x%"PRIx64,
+   reg_table[i].addr, reg);
+   if (reg == reg_table[i].val)
+   continue;
+
+   ret = i40e_aq_debug_write_register(hw, reg_table[i].addr,
+   reg_table[i].val, NULL);
+   if (ret < 0) {
+   PMD_DRV_LOG(ERR, "Failed to write 0x%"PRIx64" to the "
+ 

[dpdk-dev] [PATCH] kni: fix build on RHEL6.5

[Thomas Monjalon]

2014-12-11 13:27, Jincheng Miao:
> RHEL6.5 kernel is based on 2.6.32. But there are two changing
> from 2.6.35:
> 1. socket struct is changed
> It wrappered previous wait_queue_head_t of socket to
> struct socket_wq. So for the kernel older than 2.6.35, we should
> directly use socket->wait instead.
> 
> 2. new function sk_sleep()
> This function is implemented from 2.6.35 to obtain wait queue
> from struct sock. This patch adds a macro in kni/compat.h
> to be compatible with older kernels.

I don't understand the relation between RHEL-6.5 and the kernel 2.6.35.
The patch seems not related to RHEL at all.
Please start your explanations by describing what is the problem
you want to solve.

Thanks
-- 
Thomas

[dpdk-dev] [PATCH v2] mk: fix build with shared pcap pmd

[Thomas Monjalon]

2014-12-16 08:58, Neil Horman:
> On Tue, Dec 16, 2014 at 12:04:44AM +0100, Thomas Monjalon wrote:
> > Some applications doesn't have the pcap link flag
> > when shared libraries are enabled.
> > Indeed in such case, pcap PMD must not be linked but pcap library should.
> > 
> > Actually -lpcap is always needed if pcap PMD is used,
> > and -lrte_pmd_pcap must be set only with static PMD library.
> > So the flags -lrte_pmd_pcap and -lpcap are enabled separately.
> > 
> > Workarounds in test-pmd/ and test-pipeline/ can be removed.
> > 
> > Reported-by: Stepan Sojka 
> > Signed-off-by: Thomas Monjalon 
[...]
> > --- a/mk/rte.app.mk
> > +++ b/mk/rte.app.mk
> > @@ -119,6 +119,10 @@ LDLIBS += -lm
> >  LDLIBS += -lrt
> >  endif
> >  
> > +ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
> > +LDLIBS += -lpcap
> > +endif
> > +
> >  LDLIBS += --start-group
> >  
> >  ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
> > @@ -207,7 +211,7 @@ LDLIBS += -lrte_pmd_ring
> >  endif
> >  
> >  ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
> > -LDLIBS += -lrte_pmd_pcap -lpcap
> > +LDLIBS += -lrte_pmd_pcap
> >  endif
> >  
> >  ifeq ($(CONFIG_RTE_LIBRTE_PMD_AF_PACKET),y)
> 
> Actually, what if we just add $(LDFLAGS) to the O_TO_S rule in mk/rte.lib.mk?
> Then in lib/librte_pmd_pcap/Makefile, we can just add LDFLAGS+=-lpcap, and the
> loading of the pcap pmd will itself require the loading of libpcap.  That 
> would
> be a nice clean implementation that allows applications to just link the pmd 
> and
> not have to worry about dependencies.  It would also allow us to clean up 
> other
> dependencies like the xenvirt pmd and vhost.

Yes it makes sense. Could you test it please?
What about applying my patch (which keep the existing logic) as a first
fix/clean-up and then move -lpcap in PMD as a second step?
Proceeding this way would allow to integrate a safe fix for 1.8.0.
Maybe that linking pcap in the PMD could unveil new bugs with some 
distributions,
so it would need some time to validate it.

-- 
Thomas

[dpdk-dev] [PATCH 4/5] examples: fix check for null before de-reference

[Bruce Richardson]

The check for NULL is in the wrong position in the "if" error leg. The
pointer should be checked for NULL before checking what the value of
what the pointer points to is.

Signed-off-by: Bruce Richardson 
---
 examples/vm_power_manager/channel_manager.c | 2 +-
 examples/vm_power_manager/vm_power_cli.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/examples/vm_power_manager/channel_manager.c 
b/examples/vm_power_manager/channel_manager.c
index 34a395d..04344ae 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -389,7 +389,7 @@ add_all_channels(const char *vm_name)
errno = 0;
channel_num = (unsigned)strtol(remaining, _ptr, 0);
if ((errno != 0) || (remaining[0] == '\0') ||
-   (*tail_ptr != '\0') || tail_ptr == NULL) {
+   tail_ptr == NULL || (*tail_ptr != '\0')) {
RTE_LOG(WARNING, CHANNEL_MANAGER, "Malformed channel 
name"
"'%s' found it should be in the form of 
"

"'.(decimal)'\n",
diff --git a/examples/vm_power_manager/vm_power_cli.c 
b/examples/vm_power_manager/vm_power_cli.c
index e7f4469..bd685fd 100644
--- a/examples/vm_power_manager/vm_power_cli.c
+++ b/examples/vm_power_manager/vm_power_cli.c
@@ -323,7 +323,7 @@ cmd_channels_op_parsed(void *parsed_result, struct cmdline 
*cl,
break;
errno = 0;
channel_num = (unsigned)strtol(token, _ptr, 10);
-   if ((errno != 0) || (*tail_ptr != '\0') || tail_ptr == NULL)
+   if ((errno != 0) || tail_ptr == NULL || (*tail_ptr != '\0'))
break;

if (channel_num == CHANNEL_CMDS_MAX_VM_CHANNELS) {
@@ -408,7 +408,7 @@ cmd_channels_status_op_parsed(void *parsed_result, struct 
cmdline *cl,
break;
errno = 0;
channel_num = (unsigned)strtol(token, _ptr, 10);
-   if ((errno != 0) || (*tail_ptr != '\0') || tail_ptr == NULL)
+   if ((errno != 0) || tail_ptr == NULL || (*tail_ptr != '\0'))
break;

if (channel_num == CHANNEL_CMDS_MAX_VM_CHANNELS) {
-- 
1.9.3

[dpdk-dev] [PATCH 3/5] examples: set correct limit for length of unix socket path

[Bruce Richardson]

The length of the path to a unix socket is not PATH_MAX but instead is
UNIX_PATH_MAX which is generally just over 100 bytes in size. It's not
actually defined in sys/un.h on linux - despite the man page referencing
it, so calculate the size in the case where it's not defined.

Signed-off-by: Bruce Richardson 
---
 examples/vm_power_manager/channel_manager.c | 2 +-
 examples/vm_power_manager/channel_manager.h | 8 +++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/examples/vm_power_manager/channel_manager.c 
b/examples/vm_power_manager/channel_manager.c
index 7828be7..34a395d 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -597,7 +597,7 @@ get_info_vm(const char *vm_name, struct vm_info *info)
ITERATIVE_BITMASK_CHECK_64(mask, i) {
info->channels[channel_num].channel_num = i;
memcpy(info->channels[channel_num].channel_path,
-   vm_info->channels[i]->channel_path, PATH_MAX);
+   vm_info->channels[i]->channel_path, 
UNIX_PATH_MAX);
info->channels[channel_num].status = 
vm_info->channels[i]->status;
info->channels[channel_num].fd = vm_info->channels[i]->fd;
channel_num++;
diff --git a/examples/vm_power_manager/channel_manager.h 
b/examples/vm_power_manager/channel_manager.h
index 12c29c3..67e26ec 100644
--- a/examples/vm_power_manager/channel_manager.h
+++ b/examples/vm_power_manager/channel_manager.h
@@ -39,6 +39,7 @@ extern "C" {
 #endif

 #include 
+#include 
 #include 
 #include "channel_commands.h"

@@ -54,6 +55,11 @@ extern "C" {
 /* File socket directory */
 #define CHANNEL_MGR_SOCKET_PATH "/tmp/powermonitor/"

+#ifndef UNIX_PATH_MAX
+struct sockaddr_un _sockaddr_un;
+#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)
+#endif
+
 /* Communication Channel Status */
 enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,
CHANNEL_MGR_CHANNEL_CONNECTED,
@@ -68,7 +74,7 @@ enum vm_status { CHANNEL_MGR_VM_INACTIVE = 0, 
CHANNEL_MGR_VM_ACTIVE};
  *  the host.
  */
 struct channel_info {
-   char channel_path[PATH_MAX]; /**< Path to host socket */
+   char channel_path[UNIX_PATH_MAX]; /**< Path to host socket */
volatile uint32_t status;/**< Connection status(enum 
channel_status) */
int fd;  /**< AF_UNIX socket fd */
unsigned channel_num;/**< 
CHANNEL_MGR_SOCKET_PATH/.channel_num */
-- 
1.9.3

[dpdk-dev] [PATCH 2/5] test: check for mbuf alloc failure

[Bruce Richardson]

If mbuf allocation failed for whatever reason, we would get a NULL
pointer exception in test_table_acl.c:test_pipeline_single_filter test
case.
We fix this by causing an early break out of the application loop. If we
quit the test immediately we would leak any existing allocated mbufs,
but by breaking instead, we allow the test to continue and clean up the
mbufs already in the pipeline, while still having a test failure as the
mbuf counts should not match.

Signed-off-by: Bruce Richardson 
---
 app/test/test_table_acl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/app/test/test_table_acl.c b/app/test/test_table_acl.c
index 0f2b57e..e4e9b9c 100644
--- a/app/test/test_table_acl.c
+++ b/app/test/test_table_acl.c
@@ -513,6 +513,11 @@ test_pipeline_single_filter(int expected_count)
struct rte_mbuf *mbuf;

mbuf = rte_pktmbuf_alloc(pool);
+   if (mbuf == NULL)
+   /* this will cause test failure after cleanup
+* of already enqueued mbufs, as the mbuf
+* counts won't match */
+   break;
memset(rte_pktmbuf_mtod(mbuf, char *), 0x00,
sizeof(struct ipv4_5tuple));

-- 
1.9.3

[dpdk-dev] [PATCH 1/5] test: after NULL check, don't free the NULL pointer

[Bruce Richardson]

In the kvargs test cases, we were checking for errors by checking if the
returned pointer value was NULL. In the error handling, we then tried to
free back the NULL pointer, which would cause a crash.

Signed-off-by: Bruce Richardson 
---
 app/test/test_kvargs.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/app/test/test_kvargs.c b/app/test/test_kvargs.c
index b8f5e5c..6be8512 100644
--- a/app/test/test_kvargs.c
+++ b/app/test/test_kvargs.c
@@ -78,7 +78,6 @@ static int test_valid_kvargs(void)
kvlist = rte_kvargs_parse(args, valid_keys);
if (kvlist == NULL) {
printf("rte_kvargs_parse() error");
-   rte_kvargs_free(kvlist);
goto fail;
}
rte_kvargs_free(kvlist);
@@ -89,7 +88,6 @@ static int test_valid_kvargs(void)
kvlist = rte_kvargs_parse(args, valid_keys);
if (kvlist == NULL) {
printf("rte_kvargs_parse() error");
-   rte_kvargs_free(kvlist);
goto fail;
}
/* call check_handler() for all entries with key="check" */
@@ -150,7 +148,6 @@ static int test_valid_kvargs(void)
kvlist = rte_kvargs_parse(args, valid_keys);
if (kvlist == NULL) {
printf("rte_kvargs_parse() error");
-   rte_kvargs_free(kvlist);
goto fail;
}
/* call check_handler() on all entries with key="check", it
-- 
1.9.3

[dpdk-dev] [PATCH 0/5] Fixes for issues highlighted by static analysis scan

[Bruce Richardson]

This patch set fixes 5 issues found during a static analysis scan of the latest
DPDK code. These fixes are for possible NULL pointer references and array 
overflow/underflow.

Bruce Richardson (5):
  test: after NULL check, don't free the NULL pointer
  test: check for mbuf alloc failure
  examples: set correct limit for length of unix socket path
  examples: fix check for null before de-reference
  cfgfile: prevent error when reading an empty file

 app/test/test_kvargs.c  | 3 ---
 app/test/test_table_acl.c   | 5 +
 examples/vm_power_manager/channel_manager.c | 4 ++--
 examples/vm_power_manager/channel_manager.h | 8 +++-
 examples/vm_power_manager/vm_power_cli.c| 4 ++--
 lib/librte_cfgfile/rte_cfgfile.c| 4 +++-
 6 files changed, 19 insertions(+), 9 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH v3 8/8] doc: updating the list of sample apps in rel notes

[Siobhan Butler]

Added new and existing names of sample apps to list of
sample apps in release notes.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/rel_description.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/rel_notes/rel_description.rst 
b/doc/guides/rel_notes/rel_description.rst
index 8da53c4..49f32b9 100644
--- a/doc/guides/rel_notes/rel_description.rst
+++ b/doc/guides/rel_notes/rel_description.rst
@@ -113,10 +113,14 @@ The following is a list of DPDK documents in the 
suggested reading order:

 *   L3 Forwarding

+*   L3 Forwarding with Access Control
+
 *   L3 Forwarding with Power Management

 *   L3 Forwarding in a Virtualized Environment

+*   Link Status Interrupt
+
 *   Load Balancing

 *   Multi-process
@@ -143,6 +147,8 @@ The following is a list of DPDK documents in the suggested 
reading order:

 *   VM Power Management

+*   Distributor
+
 In addition, there are some other applications that are built when the 
libraries are created.
 The source for these applications is in the DPDK/app directory and are 
called:

-- 
1.8.5.3

[dpdk-dev] [PATCH v3 7/8] doc: updated resolved issues with old known issues

[Siobhan Butler]

Removed resolved issues from known issues section.
Added new resolved issues to resolved issues section.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/known_issues.rst| 225 ---
 doc/guides/rel_notes/resolved_issues.rst | 173 +++-
 2 files changed, 172 insertions(+), 226 deletions(-)

diff --git a/doc/guides/rel_notes/known_issues.rst 
b/doc/guides/rel_notes/known_issues.rst
index 4979e66..9fcd024 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -62,147 +62,6 @@ Pause Frame Forwarding does not work properly on igb
 || 
 |
 
++--+

-Running TestPMD with SRIOV in Domain U may cause it to hang when XENVIRT 
switch is on
--
-
-++--+
-| Title  | Running TestPMD with SRIOV in Domain U may 
cause it to hang when XENVIRT switch is on|
-|| 
 |
-++==+
-| Reference #| IXA00168949 
 |
-|| 
 |
-++--+
-| Description| When TestPMD is run with only SRIOV port 
?./testpmd -c f -n 4 -- -i? , the following |
-|| error occurs:   
 |
-|| 
 |
-|| PMD: gntalloc: ioctl error  
 |
-|| 
 |
-|| EAL: Error - exiting with code: 1   
 |
-|| 
 |
-|| Cause: Creation of mbuf pool for socket 0 
failed |
-|| 
 |
-|| Then, alternately run SRIOV port and virtIO 
with testpmd:|
-|| 
 |
-|| testpmd -c f -n 4 -- -i 
 |
-|| 
 |
-|| testpmd -c f -n 4 --use-dev="eth_xenvirt0" 
-- -i |
-|| 
 |
-++--+
-| Implication| DomU will not be accessible after you 
repeat this action some times  |
-|| 
 |
-++--+
-| Resolution/ Workaround | Run testpmd with a 
"--total-num-mbufs=N(N<=3500)"|
-|| 
 |
-++--+
-| Affected Environment/ Platform | Fedora 16, 64 bits + Xen hypervisor 4.2.3 + 
Domain 0 kernel 3.10.0   |
-|| +Domain U kernel 3.6.11 
 |
-|| 
  

[dpdk-dev] [PATCH v3 5/8] doc: remove appendix a from release notes

[Siobhan Butler]

Removing Appendix A from Release Notes as Intel Licensing information is
no longer relevant in this document.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/appendices.rst | 324 
 doc/guides/rel_notes/index.rst  |  44 -
 2 files changed, 368 deletions(-)
 delete mode 100644 doc/guides/rel_notes/appendices.rst

diff --git a/doc/guides/rel_notes/appendices.rst 
b/doc/guides/rel_notes/appendices.rst
deleted file mode 100644
index 6dec2e1..000
--- a/doc/guides/rel_notes/appendices.rst
+++ /dev/null
@@ -1,324 +0,0 @@
-..  BSD LICENSE
-Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-* Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in
-the documentation and/or other materials provided with the
-distribution.
-* Neither the name of Intel Corporation nor the names of its
-contributors may be used to endorse or promote products derived
-from this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-Appendix A  Intel?  DPDK License Overview
-=
-
-
-The following describes the various licenses used by the Intel? Data Plane 
Development Kit (Intel? DPDK).
-The purpose of the Intel? DPDK is to prove the abilities of the Intel? 
architecture processors and to provide users with a strong set of examples, 
libraries and proof points.
-By placing the majority of this software under the BSD License, users may 
choose to use the Intel? as is, parts of it, or just the ideas for their 
programs.
-All code may be modified by the user to suit their project needs and 
requirements.
-
-.. note::
-
-The license in each source file takes precedence over this document, and 
should be used as the definitive license for that file.
-All users should seek their legal team's guidance with respect to the 
licensing used by the Intel? DPDK.
-
-
-
-The following table lists those files (or libraries) that are not under a BSD 
License. In some cases, these files are part of the standard Intel? DPDK 
release package,
-and in other cases may be a separate package that requires a separate download 
to be added to the Intel? DPDK. This document spells out those cases where 
possible.
-
-The sections following the table provide the various licenses used. Please 
note that copyright notices may change overtime.
-It is the responsibility of all users to understand these licenses and seek 
their legal team's guidance.
-
-The use of the GPLv2 License is confined to files in kernel loadable modules.
-
-The use of the Dual BSD/LGPLv2 License and Dual BSD/GPL License allows use 
with either free/open source software or with proprietary software in userspace.
-
-
-+---+--+--+
-| File  | Description  

| License  |
-|   |  

|  |
-+===+==+==+
-| igb_uio.c | **1st Released** 

| GPLv2 License Information

[dpdk-dev] [PATCH v3 4/8] doc: moved known issue 6.29 to resolved issues in rel notes

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/resolved_issues.rst | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/doc/guides/rel_notes/resolved_issues.rst 
b/doc/guides/rel_notes/resolved_issues.rst
index f9ddb7f..5e88005 100644
--- a/doc/guides/rel_notes/resolved_issues.rst
+++ b/doc/guides/rel_notes/resolved_issues.rst
@@ -1192,3 +1192,33 @@ Packet reception issues when virtualization is enabled
 | Driver/Module   | Poll mode drivers  
   |
 | |
   |
 
+-+---+
+
+
+
+Double VLAN does not work on Intel? 40GbE ethernet contoller
+
+
++-+---+
+| Title   | Double VLAN does not work on Intel? 40GbE 
ethernet controller |
+| |
   |
++=+===+
+| Reference # | IXA00369908
   |
+| |
   |
++-+---+
+| Description | On Intel(R) 40 GbE ethernet controller 
double VLAN does not work.   |
+| | This was confirmed as a Firmware issue 
which will be fixed in later versions of   |
+| | firmware.  
   |
++-+---+
+| Implication | After setting double vlan to be enabled on 
a port, no packets can be transmitted out  |
+| | on that port.  
   |
++-+---+
+| Resolution/Workaround   | Resolved in latest release with firmware 
upgrade. |
+| |
   |
+| |
   |
++-+---+
+| Affected Environment/Platform   | All
   |
+| |
   |
++-+---+
+| Driver/Module   | Poll mode drivers  
   |
+| |
   |
++-+---+
-- 
1.8.5.3

[dpdk-dev] [PATCH v3 1/8] doc: moved 1.7 new features to supported features for 1.8 in Rel_Notes

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/new_features.rst   | 17 -
 doc/guides/rel_notes/supported_features.rst | 22 ++
 2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index 568d0c9..a93aa3c 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -31,22 +31,5 @@
 New Features
 

-*   Packet Distributor library for dynamic, single-packet at a time, load 
balancing
-
-*   IP fragmentation and reassembly library
-
-*   Support for IPv6 in IP fragmentation and reassembly sample applications
-
-*   Support for VFIO for mapping BARs and setting up interrupts
-
-*   Link Bonding PMD Library supporting round-robin, active backup, 
balance(layer 2, layer 2+3, and layer 3+4) and broadcast bonding modes
-
-*   Support zero copy mode RX/TX in user space vhost sample
-
-*   Support multiple queues in virtio-net PMD
-
-*   Support for Intel? 40GbE Controllers
-
-*   Support NIC filters in addition to flow director for Intel? 1GbE and 10GbE 
Controllers

 For further features supported in this release, see Chapter 3 Supported 
Features.
diff --git a/doc/guides/rel_notes/supported_features.rst 
b/doc/guides/rel_notes/supported_features.rst
index c51eb26..7efeff3 100644
--- a/doc/guides/rel_notes/supported_features.rst
+++ b/doc/guides/rel_notes/supported_features.rst
@@ -31,6 +31,28 @@
 Supported Features
 ==

+*   Packet Distributor library for dynamic, single-packet at a time, load 
balancing
+
+*   IP fragmentation and reassembly library
+
+*   Support for IPv6 in IP fragmentation and reassembly sample applications
+
+*   Support for VFIO for mapping BARs and setting up interrupts
+
+*   Link Bonding PMD Library supporting round-robin, active backup, 
balance(layer 2, layer 2+3, and layer 3+4) and broadcast bonding modes
+
+*   Support zero copy mode RX/TX in user space vhost sample
+
+*   Support multiple queues in virtio-net PMD
+
+*   Support for Intel 40GbE Controllers:
+
+*   Intel(R) XL710 40 Gigabit Ethernet Controller
+
+*   Intel(R) X710 40 Gigabit Ethernet Controller
+
+*   Support NIC filters in addition to flow director for Intel? 1GbE and 10GbE 
Controllers
+
 *   Virtualization (KVM)

 *   Userspace vhost switch:
-- 
1.8.5.3

[dpdk-dev] [PATCH v3 0/8] doc: patch set to update release notes

[Siobhan Butler]

New Features section:
   - Removed 1.7 New Features 
   - Added 1.8.0 New Features
Supported Features section:
   - Added 1.7 features to Supported Features
Known Issues:
   - Added devices to Known issue "Not all varients of supported NIC types have 
been used in testing"
   - Removed known issue 6.29 "Double VLAN not working on 40GbE Ethnet 
Controller" as resolved
Resolved issues:
   - Added known issue 6.29 to resolved issues 
Removed references across all sections to Intel DPDK where no longer relevant.
Added new sample apps to sample apps list in release notes.
Moved issues newly resolved from known issues to resolved issues.
Removed Intel Licensing Appendix A as no longer relevant. 

Siobhan Butler (8):
  Doc: Moved 1.7 "New Features" to "Supported Features" for 1.8 in
Rel_Notes
  Doc: Added "New Features" to release notes
  Doc: Added to known issue 6.10 and removed fixed issue 6.29 from
Rel_Notes
  Doc: Moved known issue 6.29 to resolved issues in Rel Notes
  doc: remove appendix a from release notes
  doc: removed reference to Intel DPDK in Rel Notes
  doc: updated resolved issues with old known issues
  doc: updating the list of sample apps in rel notes

 doc/guides/rel_notes/appendices.rst | 324 
 doc/guides/rel_notes/faq.rst|  14 +-
 doc/guides/rel_notes/index.rst  |  44 
 doc/guides/rel_notes/known_issues.rst   | 288 ++---
 doc/guides/rel_notes/new_features.rst   |  27 ++-
 doc/guides/rel_notes/rel_description.rst|  70 +++---
 doc/guides/rel_notes/resolved_issues.rst| 287 
 doc/guides/rel_notes/supported_features.rst |  26 ++-
 doc/guides/rel_notes/supported_os.rst   |   4 +-
 doc/guides/rel_notes/updating_apps.rst  |  12 +-
 10 files changed, 362 insertions(+), 734 deletions(-)
 delete mode 100644 doc/guides/rel_notes/appendices.rst

-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH] testpmd: limit port mask bits to RTE_MAX_ETHPORTS

[Thomas Monjalon]

2014-12-16 13:27, Bruce Richardson:
> The port mask parsing in testpmd allowed up to 64 bits to be processed,
> even if RTE_MAX_ETHPORTS is set to a max of 32. Fix this by only
> processing up to min(RTE_MAX_ETHPORTS,64) bits of the mask.
[...]
> - for (i = 0; i < 64; i++) {
> + for (i = 0; i < 64 && i < RTE_MAX_ETHPORTS; i++) {

Why not use RTE_MIN?

-- 
Thomas

[dpdk-dev] [PATCH v2] testpmd: limit port mask bits to RTE_MAX_ETHPORTS

[Bruce Richardson]

The port mask parsing in testpmd allowed up to 64 bits to be processed,
even if RTE_MAX_ETHPORTS is set to a max of 32. Fix this by only
processing up to min(RTE_MAX_ETHPORTS,64) bits of the mask.

Signed-off-by: Bruce Richardson 
---
V2: changed to use RTE_MIN in comparison, instead of double "<".
---
 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 69a83c2..97b6525 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1440,7 +1440,7 @@ set_fwd_ports_mask(uint64_t portmask)
return;
}
nb_pt = 0;
-   for (i = 0; i < 64; i++) {
+   for (i = 0; i < (unsigned)RTE_MIN(64, RTE_MAX_ETHPORTS); i++) {
if (! ((uint64_t)(1ULL << i) & portmask))
continue;
portlist[nb_pt++] = i;
-- 
1.9.3

[dpdk-dev] [PATCH] testpmd: limit port mask bits to RTE_MAX_ETHPORTS

[Bruce Richardson]

The port mask parsing in testpmd allowed up to 64 bits to be processed,
even if RTE_MAX_ETHPORTS is set to a max of 32. Fix this by only
processing up to min(RTE_MAX_ETHPORTS,64) bits of the mask.

Signed-off-by: Bruce Richardson 
---
 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 69a83c2..c9d1e1c 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1440,7 +1440,7 @@ set_fwd_ports_mask(uint64_t portmask)
return;
}
nb_pt = 0;
-   for (i = 0; i < 64; i++) {
+   for (i = 0; i < 64 && i < RTE_MAX_ETHPORTS; i++) {
if (! ((uint64_t)(1ULL << i) & portmask))
continue;
portlist[nb_pt++] = i;
-- 
1.9.3

[dpdk-dev] [PATCH] replaced O(n^2) sort in sort_by_physaddr() with qsort() from standard library

[Jay Rolette]

Actually, I just relooked at the email I sent and it looks correct
(properly indented, etc.). Any suggestions for what might be going on?

On Tue, Dec 16, 2014 at 1:18 PM, Jay Rolette  wrote:
>
> Thanks Konstantin. Yes, I'll resend. Not sure why gmail is removing
> whitespace when I sent in Plain Text mode.
>
> Ultimately I'll need to figure out how to properly configure git to send
> these directly instead of handling them more manually. The examples I saw
> assumed you were using a gmail.com email rather than a corporate email
> hosted via google apps.
>
> Jay
>
> On Tue, Dec 16, 2014 at 12:39 PM, Ananyev, Konstantin <
> konstantin.ananyev at intel.com> wrote:
>>
>>
>> Hi Jay,
>>
>> > -Original Message-
>> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
>> > Sent: Thursday, December 11, 2014 4:06 PM
>> > To: Dev
>> > Subject: [dpdk-dev] [PATCH] replaced O(n^2) sort in sort_by_physaddr()
>> with qsort() from standard library
>> >
>> > Signed-off-by: Jay Rolette 
>>
>> The patch itself looks good to me.
>> Though it seems something wrong with formatting - all lines start with
>> offset 0.
>> Probably your mail client?
>> Konstantin
>>
>>
>> > ---
>> >  lib/librte_eal/linuxapp/eal/eal_memory.c | 59
>> > +++-
>> >  1 file changed, 20 insertions(+), 39 deletions(-)
>> >
>> > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
>> > b/lib/librte_eal/linuxapp/eal/eal_memory.c
>> > index bae2507..3656515 100644
>> > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
>> > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
>> > @@ -670,6 +670,25 @@ error:
>> >   return -1;
>> >  }
>> >
>> > +static int
>> > +cmp_physaddr(const void *a, const void *b)
>> > +{
>> > +#ifndef RTE_ARCH_PPC_64
>> > + const struct hugepage_file *p1 = (const struct hugepage_file *)a;
>> > + const struct hugepage_file *p2 = (const struct hugepage_file *)b;
>> > +#else
>> > + // PowerPC needs memory sorted in reverse order from x86
>> > + const struct hugepage_file *p1 = (const struct hugepage_file *)b;
>> > + const struct hugepage_file *p2 = (const struct hugepage_file *)a;
>> > +#endif
>> > + if (p1->physaddr < p2->physaddr)
>> > + return -1;
>> > + else if (p1->physaddr > p2->physaddr)
>> > + return 1;
>> > + else
>> > + return 0;
>> > +}
>> > +
>> >  /*
>> >   * Sort the hugepg_tbl by physical address (lower addresses first on
>> x86,
>> >   * higher address first on powerpc). We use a slow algorithm, but we
>> won't
>> > @@ -678,45 +697,7 @@ error:
>> >  static int
>> >  sort_by_physaddr(struct hugepage_file *hugepg_tbl, struct hugepage_info
>> > *hpi)
>> >  {
>> > - unsigned i, j;
>> > - int compare_idx;
>> > - uint64_t compare_addr;
>> > - struct hugepage_file tmp;
>> > -
>> > - for (i = 0; i < hpi->num_pages[0]; i++) {
>> > - compare_addr = 0;
>> > - compare_idx = -1;
>> > -
>> > - /*
>> > - * browse all entries starting at 'i', and find the
>> > - * entry with the smallest addr
>> > - */
>> > - for (j=i; j< hpi->num_pages[0]; j++) {
>> > -
>> > - if (compare_addr == 0 ||
>> > -#ifdef RTE_ARCH_PPC_64
>> > - hugepg_tbl[j].physaddr > compare_addr) {
>> > -#else
>> > - hugepg_tbl[j].physaddr < compare_addr) {
>> > -#endif
>> > - compare_addr = hugepg_tbl[j].physaddr;
>> > - compare_idx = j;
>> > - }
>> > - }
>> > -
>> > - /* should not happen */
>> > - if (compare_idx == -1) {
>> > - RTE_LOG(ERR, EAL, "%s(): error in physaddr sorting\n", __func__);
>> > - return -1;
>> > - }
>> > -
>> > - /* swap the 2 entries in the table */
>> > - memcpy(, _tbl[compare_idx],
>> > - sizeof(struct hugepage_file));
>> > - memcpy(_tbl[compare_idx], _tbl[i],
>> > - sizeof(struct hugepage_file));
>> > - memcpy(_tbl[i], , sizeof(struct hugepage_file));
>> > - }
>> > + qsort(hugepg_tbl, hpi->num_pages[0], sizeof(struct hugepage_file),
>> > cmp_physaddr);
>> >   return 0;
>> >  }
>> >
>> > --
>>
>

[dpdk-dev] [PATCH] replaced O(n^2) sort in sort_by_physaddr() with qsort() from standard library

[Jay Rolette]

Thanks Konstantin. Yes, I'll resend. Not sure why gmail is removing
whitespace when I sent in Plain Text mode.

Ultimately I'll need to figure out how to properly configure git to send
these directly instead of handling them more manually. The examples I saw
assumed you were using a gmail.com email rather than a corporate email
hosted via google apps.

Jay

On Tue, Dec 16, 2014 at 12:39 PM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
>
>
> Hi Jay,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> > Sent: Thursday, December 11, 2014 4:06 PM
> > To: Dev
> > Subject: [dpdk-dev] [PATCH] replaced O(n^2) sort in sort_by_physaddr()
> with qsort() from standard library
> >
> > Signed-off-by: Jay Rolette 
>
> The patch itself looks good to me.
> Though it seems something wrong with formatting - all lines start with
> offset 0.
> Probably your mail client?
> Konstantin
>
>
> > ---
> >  lib/librte_eal/linuxapp/eal/eal_memory.c | 59
> > +++-
> >  1 file changed, 20 insertions(+), 39 deletions(-)
> >
> > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> > b/lib/librte_eal/linuxapp/eal/eal_memory.c
> > index bae2507..3656515 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> > @@ -670,6 +670,25 @@ error:
> >   return -1;
> >  }
> >
> > +static int
> > +cmp_physaddr(const void *a, const void *b)
> > +{
> > +#ifndef RTE_ARCH_PPC_64
> > + const struct hugepage_file *p1 = (const struct hugepage_file *)a;
> > + const struct hugepage_file *p2 = (const struct hugepage_file *)b;
> > +#else
> > + // PowerPC needs memory sorted in reverse order from x86
> > + const struct hugepage_file *p1 = (const struct hugepage_file *)b;
> > + const struct hugepage_file *p2 = (const struct hugepage_file *)a;
> > +#endif
> > + if (p1->physaddr < p2->physaddr)
> > + return -1;
> > + else if (p1->physaddr > p2->physaddr)
> > + return 1;
> > + else
> > + return 0;
> > +}
> > +
> >  /*
> >   * Sort the hugepg_tbl by physical address (lower addresses first on
> x86,
> >   * higher address first on powerpc). We use a slow algorithm, but we
> won't
> > @@ -678,45 +697,7 @@ error:
> >  static int
> >  sort_by_physaddr(struct hugepage_file *hugepg_tbl, struct hugepage_info
> > *hpi)
> >  {
> > - unsigned i, j;
> > - int compare_idx;
> > - uint64_t compare_addr;
> > - struct hugepage_file tmp;
> > -
> > - for (i = 0; i < hpi->num_pages[0]; i++) {
> > - compare_addr = 0;
> > - compare_idx = -1;
> > -
> > - /*
> > - * browse all entries starting at 'i', and find the
> > - * entry with the smallest addr
> > - */
> > - for (j=i; j< hpi->num_pages[0]; j++) {
> > -
> > - if (compare_addr == 0 ||
> > -#ifdef RTE_ARCH_PPC_64
> > - hugepg_tbl[j].physaddr > compare_addr) {
> > -#else
> > - hugepg_tbl[j].physaddr < compare_addr) {
> > -#endif
> > - compare_addr = hugepg_tbl[j].physaddr;
> > - compare_idx = j;
> > - }
> > - }
> > -
> > - /* should not happen */
> > - if (compare_idx == -1) {
> > - RTE_LOG(ERR, EAL, "%s(): error in physaddr sorting\n", __func__);
> > - return -1;
> > - }
> > -
> > - /* swap the 2 entries in the table */
> > - memcpy(, _tbl[compare_idx],
> > - sizeof(struct hugepage_file));
> > - memcpy(_tbl[compare_idx], _tbl[i],
> > - sizeof(struct hugepage_file));
> > - memcpy(_tbl[i], , sizeof(struct hugepage_file));
> > - }
> > + qsort(hugepg_tbl, hpi->num_pages[0], sizeof(struct hugepage_file),
> > cmp_physaddr);
> >   return 0;
> >  }
> >
> > --
>

[dpdk-dev] [PATCH] linux_gsg: quick_start.rst fixed as per setup.sh menu options *corrected as per latest setup.sh menu options

[Reshma Pattan]

Signed-off-by: Reshma Pattan
---
 doc/guides/linux_gsg/quick_start.rst |   64 ++---
 1 files changed, 35 insertions(+), 29 deletions(-)

diff --git a/doc/guides/linux_gsg/quick_start.rst 
b/doc/guides/linux_gsg/quick_start.rst
index 089dddb..a99b8fa 100644
--- a/doc/guides/linux_gsg/quick_start.rst
+++ b/doc/guides/linux_gsg/quick_start.rst
@@ -122,15 +122,21 @@ Some options in the script prompt the user for further 
data before proceeding.

 [2] i686-native-linuxapp-icc

-[3] x86_64-ivshmem-linuxapp-gcc
+[3] ppc_64-power8-linuxapp-gcc

-[4] x86_64-ivshmem-linuxapp-icc
+[4] x86_64-ivshmem-linuxapp-gcc

-[5] x86_64-native-bsdapp-gcc
+[5] x86_64-ivshmem-linuxapp-icc

-[6] x86_64-native-linuxapp-gcc
+[6] x86_64-native-bsdapp-clang

-[7] x86_64-native-linuxapp-icc
+[7] x86_64-native-bsdapp-gcc
+
+[8] x86_64-native-linuxapp-clang
+
+[9] x86_64-native-linuxapp-gcc
+
+[10] x86_64-native-linuxapp-icc

 

@@ -138,23 +144,23 @@ Some options in the script prompt the user for further 
data before proceeding.

 

-[8] Insert IGB UIO module
+[11] Insert IGB UIO module

-[9] Insert VFIO module
+[12] Insert VFIO module

-[10] Insert KNI module
+[13] Insert KNI module

-[11] Setup hugepage mappings for non-NUMA systems
+[14] Setup hugepage mappings for non-NUMA systems

-[12] Setup hugepage mappings for NUMA systems
+[15] Setup hugepage mappings for NUMA systems

-[13] Display current Ethernet device settings
+[16] Display current Ethernet device settings

-[14] Bind Ethernet device to IGB UIO module
+[17] Bind Ethernet device to IGB UIO module

-[15] Bind Ethernet device to VFIO module
+[18] Bind Ethernet device to VFIO module

-[16] Setup VFIO permissions
+[19] Setup VFIO permissions

 

@@ -162,9 +168,9 @@ Some options in the script prompt the user for further data 
before proceeding.

 

-[17] Run test application ($RTE_TARGET/app/test)
+[20] Run test application ($RTE_TARGET/app/test)

-[18] Run testpmd application in interactive mode ($RTE_TARGET/app/testpmd)
+[21] Run testpmd application in interactive mode ($RTE_TARGET/app/testpmd)

 

@@ -172,7 +178,7 @@ Some options in the script prompt the user for further data 
before proceeding.

 

-[19] List hugepage info from /proc/meminfo
+[22] List hugepage info from /proc/meminfo

 

@@ -180,19 +186,19 @@ Some options in the script prompt the user for further 
data before proceeding.

 

-[20] Uninstall all targets
+[23] Uninstall all targets

-[21] Unbind NICs from IGB UIO driver
+[24] Unbind NICs from IGB UIO driver

-[22] Remove IGB UIO module
+[25] Remove IGB UIO module

-[23] Remove VFIO module
+[26] Remove VFIO module

-[24] Remove KNI module
+[27] Remove KNI module

-[25] Remove hugepage mappings
+[28] Remove hugepage mappings

-[26] Exit Script
+[29] Exit Script

 Option:

@@ -200,7 +206,7 @@ The following selection demonstrates the creation of the 
x86_64-native-linuxapp-

 .. code-block:: console

-Option: 4
+Option: 9

 == Installing x86_64-native-linuxapp-gcc

@@ -216,7 +222,7 @@ The following selection demonstrates the starting of the 
Intel? DPDK UIO driver

 .. code-block:: console

-Option: 5
+Option: 25

 Unloading any existing DPDK UIO module
 Loading DPDK UIO module
@@ -232,10 +238,10 @@ The result is that the application should use -m 4096 for 
starting the applicati

 .. code-block:: console

-Option: 11
+Option: 15

 Removing currently reserved hugepages
-nmounting /mnt/huge and removing directory
+Unmounting /mnt/huge and removing directory
 Input the number of 2MB pages for each node
 Example: to have 128MB of hugepages available per node,
 enter '64' to reserve 64 * 2MB pages on each node
@@ -248,7 +254,7 @@ The following selection demonstrates the launch of the test 
application to run o

 .. code-block:: console

-Option: 14
+Option: 20

 Enter hex bitmask of cores to execute test app on
 Example: to execute app on cores 0 to 7, enter 0xff
-- 
1.7.4.1

[dpdk-dev] [PATCH] bond: vlan flags misinterpreted in xmit_slave_hash function

[Thomas Monjalon]

Hi Declan,

2014-12-16 11:15, Declan Doherty:
> - Split transmit hashing function into separate functions to reduce branching
>   and to make code clearer.
> - Add IPv4 IHL parameters to rte_ip.h
> - Fixed VLAN tag support in hashing functions and add support for TCP
>   in layer 4 header hashing.
> - Fixed incorrect flag set in test application packet generator.

You forgot to describe the problem you are solving.

You seem fixing something but I'm afraid this patch is too big to be safely
integrated in 1.8.0.
Was it your goal?

> Signed-off-by: Declan Doherty 
> ---
>  app/test/packet_burst_generator.c  |   2 +-
>  lib/librte_net/rte_ip.h|   2 +
>  lib/librte_pmd_bond/rte_eth_bond_api.c |   8 ++
>  lib/librte_pmd_bond/rte_eth_bond_pmd.c | 161 
> -
>  lib/librte_pmd_bond/rte_eth_bond_private.h |  15 +++
>  5 files changed, 115 insertions(+), 73 deletions(-)
> 
[...]
> --- a/lib/librte_net/rte_ip.h
> +++ b/lib/librte_net/rte_ip.h
> @@ -109,6 +109,8 @@ struct ipv4_hdr {
>  (((b) & 0xff) << 16) | \
>  (((c) & 0xff) << 8)  | \
>  ((d) & 0xff))
> +#define IPV4_HDR_IHL_MASK(0x0f)
> +#define IPV4_FIELD_WIDTH (4)

These new definitions require some doxygen comments.

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] bond: vlan flags misinterpreted in xmit_slave_hash function

[Wodkowski, PawelX]

> -Original Message-
> From: Doherty, Declan
> Sent: Tuesday, December 16, 2014 12:16 PM
> To: dev at dpdk.org
> Cc: Wodkowski, PawelX; Doherty, Declan
> Subject: [PATCH] bond: vlan flags misinterpreted in xmit_slave_hash function
> 
> - Split transmit hashing function into separate functions to reduce branching
>   and to make code clearer.
> - Add IPv4 IHL parameters to rte_ip.h
> - Fixed VLAN tag support in hashing functions and add support for TCP
>   in layer 4 header hashing.
> - Fixed incorrect flag set in test application packet generator.
> 
> Signed-off-by: Declan Doherty 


Acked-by: Wodkowski, Pawel 

[dpdk-dev] [PATCH RFC v2 10/12] lib/librte_vhost: vhost-user memory region map

[Tetsuya Mukawa]

(2014/12/11 6:37), Huawei Xie wrote:
> deals with vhost user memory map/unmap alignment
>
> Signed-off-by: Huawei Xie 
> ---
>  lib/librte_vhost/rte_virtio_net.h |   2 +
>  lib/librte_vhost/vhost-net.h  |   2 -
>  lib/librte_vhost/vhost_user/vhost-net-user.h  |   3 +-
>  lib/librte_vhost/vhost_user/virtio-net-user.c | 105 
> --
>  4 files changed, 100 insertions(+), 12 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_virtio_net.h 
> b/lib/librte_vhost/rte_virtio_net.h
> index 00b1328..77db80b 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -48,6 +48,8 @@
>  #include 
>  #include 
>  
> +#define VHOST_MEMORY_MAX_NREGIONS 8
> +
>  /* Used to indicate that the device is running on a data core */
>  #define VIRTIO_DEV_RUNNING 1
>  
> diff --git a/lib/librte_vhost/vhost-net.h b/lib/librte_vhost/vhost-net.h
> index f9ec40b..ec2584f 100644
> --- a/lib/librte_vhost/vhost-net.h
> +++ b/lib/librte_vhost/vhost-net.h
> @@ -43,8 +43,6 @@
>  
>  #include "rte_virtio_net.h"
>  
> -#define VHOST_MEMORY_MAX_NREGIONS 8
> -
>  extern struct vhost_net_device_ops const *ops;
>  
>  /* Macros for printing using RTE_LOG */
> diff --git a/lib/librte_vhost/vhost_user/vhost-net-user.h 
> b/lib/librte_vhost/vhost_user/vhost-net-user.h
> index c138844..f4c9d01 100644
> --- a/lib/librte_vhost/vhost_user/vhost-net-user.h
> +++ b/lib/librte_vhost/vhost_user/vhost-net-user.h
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  
> +#include "rte_virtio_net.h"
>  #include "fd_man.h"
>  
>  struct vhost_server {
> @@ -47,8 +48,6 @@ struct vhost_server {
>  
>  /* refer to hw/virtio/vhost-user.c */
>  
> -#define VHOST_MEMORY_MAX_NREGIONS8
> -
>  typedef enum VhostUserRequest {
>   VHOST_USER_NONE = 0,
>   VHOST_USER_GET_FEATURES = 1,
> diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c 
> b/lib/librte_vhost/vhost_user/virtio-net-user.c
> index ad59fcc..3aecb17 100644
> --- a/lib/librte_vhost/vhost_user/virtio-net-user.c
> +++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
> @@ -36,7 +36,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
> +#include 
>  #include 
>  
>  #include "virtio-net.h"
> @@ -44,13 +48,56 @@
>  #include "vhost-net-user.h"
>  #include "vhost-net.h"
>  
> +struct orig_region_map {
> + int fd;
> + uint64_t mapped_address;
> + uint64_t mapped_size;
> + uint64_t blksz;
> +};
> +
> +#define orig_region(ptr, nregions) (struct orig_region_map 
> *)RTE_PTR_ADD(ptr, sizeof(struct virtio_memory) + sizeof(struct 
> virtio_memory_regions) * (nregions))
> +
> +static uint64_t
> +get_blk_size(int fd)
> +{
> + struct stat stat;
> + fstat(fd, );
> + return (uint64_t)stat.st_blksize;
> +}

I've also confirmed we can get hugepage size of the fd using st_blksize.
If someone wants to run QEMU on 2MB hugepage, but DPDK backend is on
1GB, even in such a case, we will also be able to mmap and munmap QEMU
backend memory correctly.
So I guess using st_blksize is smart workaround not to hit munmap issue.

> +
>  int
>  user_set_mem_table(struct vhost_device_ctx ctx, struct VhostUserMsg *pmsg)
>  {
> - unsigned int idx;
>   struct VhostUserMemory memory = pmsg->payload.memory;
>   struct virtio_memory_regions regions[VHOST_MEMORY_MAX_NREGIONS];
> - uint64_t mapped_address, base_address = 0;
> + uint64_t mapped_address, mapped_size, base_address = 0;
> + struct virtio_net *dev;
> + unsigned int idx = 0;
> + struct orig_region_map tmp[VHOST_MEMORY_MAX_NREGIONS] =
> + { [0 ... VHOST_MEMORY_MAX_NREGIONS - 1] = { 0 } };
> + struct orig_region_map *region;
> + uint64_t alignment;
> + int ret;
> +
> + /* unmap old memory regions one by one*/
> + dev = get_device(ctx);
> + if (dev->mem) {
> + region = orig_region(dev->mem, dev->mem->nregions);
> + for (idx = 0; idx < dev->mem->nregions; idx++) {
> + if (region[idx].mapped_address) {
> + alignment = region[idx].blksz;
> + printf("Freeing %p\n",
> + (void 
> *)(uintptr_t)region[idx].mapped_address);
> + ret = munmap((void 
> *)RTE_ALIGN_FLOOR(region[idx].mapped_address, alignment),
> + RTE_ALIGN_CEIL(region[idx].mapped_size, 
> alignment));
> + printf("munmap ret= %d\n", ret);
> + printf("close file %d\n", region[idx].fd);
> + close(region[idx].fd);
> + }
> + }
> + free(dev->mem);
> + dev->mem = NULL;
> + }
>  
>   for (idx = 0; idx < memory.nregions; idx++) {
>   if (memory.regions[idx].guest_phys_addr == 0)
> @@ -73,22 +120,30 @@ user_set_mem_table(struct vhost_device_ctx ctx, struct 
> VhostUserMsg 

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

[Thomas Monjalon]

2014-12-16 10:00, Sujith Sankar:
> On 16/12/14 1:21 pm, "Qiu, Michael"  wrote:
> >On 12/16/2014 12:13 PM, Sujith Sankar (ssujith) wrote:
> >> On 16/12/14 4:54 am, "Thomas Monjalon"  
> >> wrote:
> >>> 2014-12-12 13:48, Sujith Sankar:
>  This patch corrects the usage of the flag VFIO_PRESENT in enic driver.
> >>> 
> >>> Please, could you explain why the flag VFIO_PRESENT was not well used?
> >> 
> >> Without including eal_vfio.h, VFIO_PRESENT is not available in enic.
> >> Hence VFIO specific code in enic was not getting compiled and some errors
> >> were generated during run-time.
> >>
>  This has uncovered a few warnings, and this patch corrects those too.
> >>> [...]
>  --- a/lib/librte_pmd_enic/enic_main.c
>  +++ b/lib/librte_pmd_enic/enic_main.c
>  @@ -39,6 +39,7 @@
>   #include 
>   #include 
>   #include 
>  +#include 
>   
>   #include 
>   #include 
>  @@ -46,6 +47,7 @@
>   #include 
>   #include 
>   #include 
>  +#include 
> >>> 
> >>> This header was not designed to be included by PMDs.
> >>> It will break compilation on BSD.
> >> 
> >> Is there an alternative to make VFIO_PRESENT available in enic?  Please
> >> advise.
> >
> >You can remove  VFIO_PRESENT check, it all been done in eal, you can
> >check other nic pmds for reference.
> >And seems you done the interrupt logic all by your self?
> >
> >Thanks,
> >Michael
> 
> Thanks for the comment, Michael.
> 
> Without the code under VFIO_PRESENT flag, I was getting false notification
> of interrupt at the beginning (cat /proc/interrupts showed all 0s).
> Let me try to root cause it.  I shall get back after some debugging and
> testing.
> 
> There was one more reason behind doing interrupt logic in enic.  No matter
> how many interrupts the user configures, enic pmd needs only one.
> There is no way to communicate that to the EAL.  I thought doing interrupt
> login in enic could avoid registering that many interrupts.

If you think something is wrong or could be improved in EAL,
it's really better to patch it instead of workarounding in the PMD.

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] bond: vlan flags misinterpreted in xmit_slave_hash function

[Declan Doherty]

- Split transmit hashing function into separate functions to reduce branching
  and to make code clearer.
- Add IPv4 IHL parameters to rte_ip.h
- Fixed VLAN tag support in hashing functions and add support for TCP
  in layer 4 header hashing.
- Fixed incorrect flag set in test application packet generator.

Signed-off-by: Declan Doherty 
---
 app/test/packet_burst_generator.c  |   2 +-
 lib/librte_net/rte_ip.h|   2 +
 lib/librte_pmd_bond/rte_eth_bond_api.c |   8 ++
 lib/librte_pmd_bond/rte_eth_bond_pmd.c | 161 -
 lib/librte_pmd_bond/rte_eth_bond_private.h |  15 +++
 5 files changed, 115 insertions(+), 73 deletions(-)

diff --git a/app/test/packet_burst_generator.c 
b/app/test/packet_burst_generator.c
index b2824dc..4a89663 100644
--- a/app/test/packet_burst_generator.c
+++ b/app/test/packet_burst_generator.c
@@ -97,7 +97,7 @@ initialize_eth_header(struct ether_hdr *eth_hdr, struct 
ether_addr *src_mac,
vhdr->eth_proto =  rte_cpu_to_be_16(ETHER_TYPE_IPv4);
vhdr->vlan_tci = van_id;
} else {
-   eth_hdr->ether_type = rte_cpu_to_be_16(ETHER_TYPE_VLAN);
+   eth_hdr->ether_type = rte_cpu_to_be_16(ETHER_TYPE_IPv4);
}

 }
diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h
index 46f0497..c97ee0a 100644
--- a/lib/librte_net/rte_ip.h
+++ b/lib/librte_net/rte_ip.h
@@ -109,6 +109,8 @@ struct ipv4_hdr {
   (((b) & 0xff) << 16) | \
   (((c) & 0xff) << 8)  | \
   ((d) & 0xff))
+#define IPV4_HDR_IHL_MASK  (0x0f)
+#define IPV4_FIELD_WIDTH   (4)

 /* Fragment Offset * Flags. */
 #defineIPV4_HDR_DF_SHIFT   14
diff --git a/lib/librte_pmd_bond/rte_eth_bond_api.c 
b/lib/librte_pmd_bond/rte_eth_bond_api.c
index ef5ddf4..fb015a8 100644
--- a/lib/librte_pmd_bond/rte_eth_bond_api.c
+++ b/lib/librte_pmd_bond/rte_eth_bond_api.c
@@ -268,6 +268,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t 
socket_id)
internals->mode = BONDING_MODE_INVALID;
internals->current_primary_port = 0;
internals->balance_xmit_policy = BALANCE_XMIT_POLICY_LAYER2;
+   internals->xmit_hash = xmit_l2_hash;
internals->user_defined_mac = 0;
internals->link_props_set = 0;

@@ -710,9 +711,16 @@ rte_eth_bond_xmit_policy_set(uint8_t bonded_port_id, 
uint8_t policy)

switch (policy) {
case BALANCE_XMIT_POLICY_LAYER2:
+   internals->balance_xmit_policy = policy;
+   internals->xmit_hash = xmit_l2_hash;
+   break;
case BALANCE_XMIT_POLICY_LAYER23:
+   internals->balance_xmit_policy = policy;
+   internals->xmit_hash = xmit_l23_hash;
+   break;
case BALANCE_XMIT_POLICY_LAYER34:
internals->balance_xmit_policy = policy;
+   internals->xmit_hash = xmit_l34_hash;
break;

default:
diff --git a/lib/librte_pmd_bond/rte_eth_bond_pmd.c 
b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
index 3db473b..dc1a828 100644
--- a/lib/librte_pmd_bond/rte_eth_bond_pmd.c
+++ b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
@@ -31,6 +31,8 @@
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 #include 
+#include 
+
 #include 
 #include 
 #include 
@@ -48,6 +50,9 @@
 #include "rte_eth_bond_8023ad_private.h"

 #define REORDER_PERIOD_MS 10
+
+#define HASH_L4_PORTS(h) ((h)->src_port ^ (h)->dst_port)
+
 /* Table for statistics in mode 5 TLB */
 static uint64_t tlb_last_obytets[RTE_MAX_ETHPORTS];

@@ -276,90 +281,104 @@ ipv6_hash(struct ipv6_hdr *ipv6_hdr)
(word_src_addr[3] ^ word_dst_addr[3]);
 }

-static uint32_t
-udp_hash(struct udp_hdr *hdr)
+static inline size_t
+get_vlan_offset(struct ether_hdr *eth_hdr)
 {
-   return hdr->src_port ^ hdr->dst_port;
+   size_t vlan_offset = 0;
+
+   /* Calculate VLAN offset */
+   if (rte_cpu_to_be_16(ETHER_TYPE_VLAN) == eth_hdr->ether_type) {
+   struct vlan_hdr *vlan_hdr = (struct vlan_hdr *)(eth_hdr + 1);
+   vlan_offset = sizeof(struct vlan_hdr);
+
+   while (rte_cpu_to_be_16(ETHER_TYPE_VLAN) ==
+   vlan_hdr->eth_proto) {
+   vlan_hdr = vlan_hdr + 1;
+   vlan_offset += sizeof(struct vlan_hdr);
+   }
+   }
+   return vlan_offset;
 }

-static inline uint16_t
-xmit_slave_hash(const struct rte_mbuf *buf, uint8_t slave_count, uint8_t 
policy)
+uint16_t
+xmit_l2_hash(const struct rte_mbuf *buf, uint8_t slave_count)
 {
-   struct ether_hdr *eth_hdr;
-   struct udp_hdr *udp_hdr;
-   size_t eth_offset = 0;
-   uint32_t hash = 0;
-
-   if (slave_count == 1)
-   return 0;
+   struct ether_hdr *eth_hdr = rte_pktmbuf_mtod(buf, struct ether_hdr *);

-   switch 

[dpdk-dev] [PATCH] testpmd: remove duplicated function parse_item_list

[Bruce Richardson]

There were two static functions called "parse_item_list" in testpmd app.
Since one was a superset of the functionality of the other, we can
collapse the two calls down into a single one, shared between the two
C files.

Signed-off-by: Bruce Richardson 
---
 app/test-pmd/cmdline.c|  2 +-
 app/test-pmd/parameters.c | 49 ++-
 app/test-pmd/testpmd.h|  3 +++
 3 files changed, 6 insertions(+), 48 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 882a5a2..4618b92 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -2224,7 +2224,7 @@ cmdline_parse_inst_t cmd_stop = {

 /* *** SET CORELIST and PORTLIST CONFIGURATION *** */

-static unsigned int
+unsigned int
 parse_item_list(char* str, const char* item_name, unsigned int max_items,
unsigned int *parsed_items, int check_unique_values)
 {
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index fcb2c99..adf3203 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -491,52 +491,6 @@ parse_ringnuma_config(const char *q_arg)
return 0;
 }

-static unsigned int
-parse_item_list(char* str, unsigned int max_items, unsigned int *parsed_items)
-{
-   unsigned int nb_item;
-   unsigned int value;
-   unsigned int i;
-   int value_ok;
-   char c;
-
-   /*
-* First parse all items in the list and store their value.
-*/
-   value = 0;
-   nb_item = 0;
-   value_ok = 0;
-   for (i = 0; i < strlen(str); i++) {
-   c = str[i];
-   if ((c >= '0') && (c <= '9')) {
-   value = (unsigned int) (value * 10 + (c - '0'));
-   value_ok = 1;
-   continue;
-   }
-   if (c != ',') {
-   printf("character %c is not a decimal digit\n", c);
-   return (0);
-   }
-   if (! value_ok) {
-   printf("No valid value before comma\n");
-   return (0);
-   }
-   if (nb_item < max_items) {
-   parsed_items[nb_item] = value;
-   value_ok = 0;
-   value = 0;
-   }
-   nb_item++;
-   }
-
-   if (nb_item >= max_items)
-   rte_exit(EXIT_FAILURE, "too many txpkt segments!\n");
-
-   parsed_items[nb_item++] = value;
-
-   return (nb_item);
-}
-
 void
 launch_args_parse(int argc, char** argv)
 {
@@ -1050,7 +1004,8 @@ launch_args_parse(int argc, char** argv)
unsigned seg_lengths[RTE_MAX_SEGS_PER_PKT];
unsigned int nb_segs;

-   nb_segs = parse_item_list(optarg, 
RTE_MAX_SEGS_PER_PKT, seg_lengths);
+   nb_segs = parse_item_list(optarg, "txpkt 
segments",
+   RTE_MAX_SEGS_PER_PKT, 
seg_lengths, 0);
if (nb_segs > 0)
set_tx_pkt_segments(seg_lengths, 
nb_segs);
else
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index f8b0740..8f5e6c7 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -446,6 +446,9 @@ port_pci_reg_write(struct rte_port *port, uint32_t reg_off, 
uint32_t reg_v)
port_pci_reg_write([(pt_id)], (reg_off), (reg_value))

 /* Prototypes */
+unsigned int parse_item_list(char* str, const char* item_name,
+   unsigned int max_items,
+   unsigned int *parsed_items, int check_unique_values);
 void launch_args_parse(int argc, char** argv);
 void prompt(void);
 void nic_stats_display(portid_t port_id);
-- 
1.9.3

[dpdk-dev] [PATCH v3] i40e: workaround for X710 performance issues

[Zhang, Helin]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, December 16, 2014 4:37 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Rowden, Aaron F; Chen, Jing D
> Subject: Re: [dpdk-dev] [PATCH v3] i40e: workaround for X710 performance
> issues
> 
> Hi Helin,
> 
> First, thank you and Jing for the excellent review process.
> 
> 2014-12-16 16:23, Helin Zhang:
> > On X710, performance number is far from the expectation on recent
> > firmware versions. The fix for this issue may not be integrated in the
> > following firmware version. So the workaround in software driver is
> > needed. It needs to modify the initial values of 3 internal only
> > registers. Note that the workaround can be removed when it is fixed in
> > firmware in the future.
> 
> I want to understand something here. You say the workaround can be removed
> when firmware will be fixed. But I suppose that some NICs won't be updated so
> the workaround will be needed forever?
Yes, it is possible. Let me check with our NIC marketing guys of their firmware 
update strategy before removing it.
Now it is quite useful for high performance. Thank you very much for pointing 
out this!

Regards,
Helin

> 
> --
> Thomas

[dpdk-dev] [PATCH] doc: remove intel legal info from freebsd-gsg

[Siobhan Butler]

Removed redundant legal blurb from FreeBSD GSG

Signed-off-by: Siobhan Butler 
---
 doc/guides/freebsd_gsg/index.rst | 38 --
 1 file changed, 38 deletions(-)

diff --git a/doc/guides/freebsd_gsg/index.rst b/doc/guides/freebsd_gsg/index.rst
index f84c2f8..1b4cd3b 100644
--- a/doc/guides/freebsd_gsg/index.rst
+++ b/doc/guides/freebsd_gsg/index.rst
@@ -33,44 +33,6 @@ Getting Started Guide for FreeBSD

 |today|

-INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS.
-NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL 
PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT.
-EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, 
INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR 
IMPLIED WARRANTY,
-RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR 
WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR 
INFRINGEMENT OF ANY PATENT,
-COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
-
-A ?Mission Critical Application? is any application in which failure of the 
Intel Product could result, directly or indirectly, in personal injury or death.
-SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL 
APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, 
SUBCONTRACTORS AND AFFILIATES,
-AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL 
CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT 
OF, DIRECTLY OR INDIRECTLY,
-ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY 
OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS 
SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN,
-MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS.
-
-Intel may make changes to specifications and product descriptions at any time, 
without notice.
-Designers must not rely on the absence or characteristics of any features or 
instructions marked ?reserved? or ?undefined?.
-Intel reserves these for future definition and shall have no responsibility 
whatsoever for conflicts or incompatibilities arising from future changes to 
them.
-The information here is subject to change without notice. Do not finalize a 
design with this information.
-
-The products described in this document may contain design defects or errors 
known as errata which may cause the product to deviate from published 
specifications.
-Current characterized errata are available on request.
-
-Contact your local Intel sales office or your distributor to obtain the latest 
specifications and before placing your product order.
-
-Copies of documents which have an order number and are referenced in this 
document, or other Intel literature, may be obtained by calling 1-800-548- 4725,
-or go to: http://www.intel.com/design/literature.htm
-
-Any software source code reprinted in this document is furnished for 
informational purposes only and may only be used or copied and no license, 
express or implied, by estoppel or otherwise,
-to any of the reprinted source code is granted by this document.
-
-Code Names are only for use by Intel to identify products, platforms, 
programs, services, etc. (?products?) in development by Intel that
-have not been made commercially available to the public, i.e., announced, 
launched or shipped.
-They are never to be used as ?commercial? names for products. Also, they are 
not intended to function as trademarks.
-
-Intel, the Intel logo, Intel Core and Xeon are trademarks of Intel Corporation 
in the U.S. and/or other countries.
-
-\*Other names and brands may be claimed as the property of others.
-
-Copyright ? 2014, Intel Corporation. All rights reserved.
-
 **Contents**

 .. toctree::
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH 2/2] Makefile changes for moved files.

[Ravi Kerur]

Use RTE_EXEC_ENV_BSDAPP in common files for code specific to BSD and
!RTE_EXEC_ENV_BSDAPP for Linux.

Signed-off-by: Ravi Kerur 
---
 lib/librte_eal/bsdapp/eal/Makefile|  6 ++--
 lib/librte_eal/common/eal_common_alarm.c  | 40 
 lib/librte_eal/common/eal_common_interrupts.c | 45
++-
 lib/librte_eal/linuxapp/eal/Makefile  |  6 ++--
 4 files changed, 90 insertions(+), 7 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index d434882..3573c08 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -53,11 +53,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) +=
eal_hugepage_info.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_thread.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_log.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_pci.c
-SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_debug.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_lcore.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_timer.c
-SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_interrupts.c
-SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_alarm.c

 # from common dir
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_memzone.c @@ -73,6
+70,9 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_hexdump.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_devargs.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_dev.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_options.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_alarm.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_debug.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_interrupts.c

 CFLAGS_eal.o := -D_GNU_SOURCE
 #CFLAGS_eal_thread.o := -D_GNU_SOURCE
diff --git a/lib/librte_eal/common/eal_common_alarm.c
b/lib/librte_eal/common/eal_common_alarm.c
index e8da32f..abc6f74 100644
--- a/lib/librte_eal/common/eal_common_alarm.c
+++ b/lib/librte_eal/common/eal_common_alarm.c
@@ -30,6 +30,16 @@
  *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
+#ifdef RTE_EXEC_ENV_BSDAPP
+#include 
+#include 
+
+#include 
+#include 
+#include "eal_private.h"
+
+#else  /* !RTE_EXEC_ENV_BSDAPP */
+
 #include 
 #include 
 #include 
@@ -80,6 +90,33 @@ static struct rte_intr_handle intr_handle = {.fd = -1
};  static int handler_registered = 0;  static void
eal_alarm_callback(struct rte_intr_handle *hdl, void *arg);

+#endif /* RTE_EXEC_ENV_BSDAPP */
+
+#ifdef RTE_EXEC_ENV_BSDAPP
+
+int
+rte_eal_alarm_init(void)
+{
+return 0;
+}
+
+
+int
+rte_eal_alarm_set(uint64_t us __rte_unused,
+rte_eal_alarm_callback cb_fn __rte_unused,
+void *cb_arg __rte_unused) {
+return -ENOTSUP;
+}
+
+int
+rte_eal_alarm_cancel(rte_eal_alarm_callback cb_fn __rte_unused,
+void *cb_arg __rte_unused) {
+return -ENOTSUP;
+}
+
+#else /* !RTE_EXEC_ENV_BSDAPP */
 int
 rte_eal_alarm_init(void)
 {
@@ -94,6 +131,7 @@ rte_eal_alarm_init(void)
 error:
rte_errno = errno;
return -1;
+
 }

 static void
@@ -266,3 +304,5 @@ rte_eal_alarm_cancel(rte_eal_alarm_callback cb_fn, void
*cb_arg)

return count;
 }
+
+#endif /* RTE_EXEC_ENV_BSDAPP */
diff --git a/lib/librte_eal/common/eal_common_interrupts.c
b/lib/librte_eal/common/eal_common_interrupts.c
index dc2668a..745413e 100644
--- a/lib/librte_eal/common/eal_common_interrupts.c
+++ b/lib/librte_eal/common/eal_common_interrupts.c
@@ -31,6 +31,48 @@
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */

+#ifdef RTE_EXEC_ENV_BSDAPP
+
+#include 
+#include 
+#include "eal_private.h"
+
+int
+rte_intr_callback_register(struct rte_intr_handle *intr_handle
__rte_unused,
+rte_intr_callback_fn cb __rte_unused,
+void *cb_arg __rte_unused) {
+return -ENOTSUP;
+}
+
+int
+rte_intr_callback_unregister(struct rte_intr_handle *intr_handle
__rte_unused,
+rte_intr_callback_fn cb_fn __rte_unused,
+void *cb_arg __rte_unused) {
+return -ENOTSUP;
+}
+
+int
+rte_intr_enable(struct rte_intr_handle *intr_handle __rte_unused) {
+return -ENOTSUP;
+}
+
+int
+rte_intr_disable(struct rte_intr_handle *intr_handle __rte_unused) {
+return -ENOTSUP;
+}
+
+int
+rte_eal_intr_init(void)
+{
+return 0;
+}
+
+#else   /* !RTE_EXEC_ENV_BSDAPP */
+
 #include 
 #include 
 #include 
@@ -66,7 +108,7 @@
 #include 

 #include "eal_private.h"
-#include "eal_vfio.h"
+#include 

 #define EAL_INTR_EPOLL_WAIT_FOREVER (-1)

@@ -824,3 +866,4 @@ rte_eal_intr_init(void)
return -ret;
 }

+#endif   /* RTE_EXEC_ENV_BSDAPP */
diff --git a/lib/librte_eal/linuxapp/eal/Makefile
b/lib/librte_eal/linuxapp/eal/Makefile
index 72ecf3a..0e2ba30 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -62,11 +62,8 @@ 

[dpdk-dev] [PATCH 0/2] [RFC] Moving EAL source files into common dir.

[Ravi Kerur]

This patch is RFC for moving EAL source files into common directory.
Currently eal_alarm.c, eal_interrupts.c and eal_debug.c are moved.
Please let me know if this approach makes sense.

Ravi Kerur (2):
  Move EAL source files into common directory.
  Makefile changes for moved files.

 lib/librte_eal/bsdapp/eal/Makefile|   6 +-
 lib/librte_eal/bsdapp/eal/eal_alarm.c |  60 --
 lib/librte_eal/bsdapp/eal/eal_debug.c | 113 
 lib/librte_eal/bsdapp/eal/eal_interrupts.c|  71 ---
 lib/librte_eal/common/eal_common_alarm.c  | 308 +
 lib/librte_eal/common/eal_common_debug.c  | 113 
 lib/librte_eal/common/eal_common_interrupts.c | 869
++
 lib/librte_eal/common/eal_vfio.h  |  55 ++
 lib/librte_eal/linuxapp/eal/Makefile  |   6 +-
 lib/librte_eal/linuxapp/eal/eal_alarm.c   | 268 
 lib/librte_eal/linuxapp/eal/eal_debug.c   | 113 
 lib/librte_eal/linuxapp/eal/eal_interrupts.c  | 826

 lib/librte_eal/linuxapp/eal/eal_vfio.h|  55 --
 13 files changed, 1351 insertions(+), 1512 deletions(-)  delete mode
100644 lib/librte_eal/bsdapp/eal/eal_alarm.c
 delete mode 100644 lib/librte_eal/bsdapp/eal/eal_debug.c
 delete mode 100644 lib/librte_eal/bsdapp/eal/eal_interrupts.c
 create mode 100644 lib/librte_eal/common/eal_common_alarm.c
 create mode 100644 lib/librte_eal/common/eal_common_debug.c
 create mode 100644 lib/librte_eal/common/eal_common_interrupts.c
 create mode 100644 lib/librte_eal/common/eal_vfio.h  delete mode 100644
lib/librte_eal/linuxapp/eal/eal_alarm.c
 delete mode 100644 lib/librte_eal/linuxapp/eal/eal_debug.c
 delete mode 100644 lib/librte_eal/linuxapp/eal/eal_interrupts.c
 delete mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio.h

--
1.9.1

[dpdk-dev] [PATCH v2] doc: remove redundant intel references-freebsd gsg

[Siobhan Butler]

Updated the FreeBSD GSG to remove redundant Intel references.

Signed-off-by: Siobhan Butler 
---
 doc/guides/freebsd_gsg/build_dpdk.rst | 78 +--
 doc/guides/freebsd_gsg/build_sample_apps.rst  | 40 +++---
 doc/guides/freebsd_gsg/install_from_ports.rst | 28 +-
 doc/guides/freebsd_gsg/intro.rst  | 22 
 4 files changed, 84 insertions(+), 84 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst 
b/doc/guides/freebsd_gsg/build_dpdk.rst
index 5fdab44..8eff599 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -30,28 +30,28 @@

 .. _building_from_source:

-Compiling the Intel? DPDK Target from Source
-
+Compiling the DPDK Target from Source
+=

 .. note::

 Testing has been performed using FreeBSD* 10.0-RELEASE (x86_64) and 
requires the
 installation of the kernel sources, which should be included during the
-installation of FreeBSD*.   The Intel? DPDK also requires the use of 
FreeBSD*
+installation of FreeBSD*. The DPDK also requires the use of FreeBSD*
 ports to compile and function.

 System Requirements
 ---

-The Intel? DPDK and its applications require the GNU make system (gmake)
+The DPDK and its applications require the GNU make system (gmake)
 to build on FreeBSD*. Optionally, gcc may also be used in place of clang
-to build the Intel? DPDK, in which case it too must be installed prior to
-compiling the Intel? DPDK. The installation of these tools is covered in this
+to build the DPDK, in which case it too must be installed prior to
+compiling the DPDK. The installation of these tools is covered in this
 section.

-Compiling the Intel? DPDK requires the FreeBSD kernel sources, which should be
+Compiling the DPDK requires the FreeBSD kernel sources, which should be
 included during the installation of FreeBSD* on the development platform.
-The Intel? DPDK also requires the use of FreeBSD* ports to compile and 
function.
+The DPDK also requires the use of FreeBSD* ports to compile and function.

 To use the FreeBSD* ports system, it is required to update and extract the 
FreeBSD*
 ports tree by issuing the following commands:
@@ -69,7 +69,7 @@ using:
 root at host:~ # setenv http_proxy :
 root at host:~ # setenv ftp_proxy :

-The FreeBSD* ports below need to be installed prior to building the Intel? 
DPDK.
+The FreeBSD* ports below need to be installed prior to building the DPDK.
 In general these can be installed using the following set of commands:

 #.  cd /usr/ports/
@@ -97,7 +97,7 @@ GNU make(gmake)
 coreutils
/usr/ports/sysutils/coreutils

-For compiling and using the Intel? DPDK with gcc, it too must be installed
+For compiling and using the DPDK with gcc, it too must be installed
 from the ports collection:

 gcc: version 4.8 is recommended
@@ -105,7 +105,7 @@ gcc: version 4.8 is recommended
(Ensure that CPU_OPTS is selected (default is OFF))

 When running the make config-recursive command, a dialog may be presented to 
the
-user. For the installation of the Intel? DPDK, the default options were used.
+user. For the installation of the DPDK, the default options were used.

 .. note::

@@ -114,10 +114,10 @@ user. For the installation of the Intel? DPDK, the 
default options were used.
 make config -recursive command until no more dialogs are seen.


-Install the Intel? DPDK and Browse Sources
---
+Install the DPDK and Browse Sources
+---

-First, uncompress the archive and move to the Intel? DPDK source directory:
+First, uncompress the archive and move to the DPDK source directory:

 .. code-block:: console

@@ -126,20 +126,20 @@ First, uncompress the archive and move to the Intel? DPDK 
source directory:
 user at host:~/DPDK # ls
 app/ config/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile mk/ scripts/ 
tools/

-The Intel? DPDK is composed of several directories:
+The DPDK is composed of several directories:

-*   lib: Source code of Intel? DPDK libraries
+*   lib: Source code of DPDK libraries

-*   app: Source code of Intel? DPDK applications (automatic tests)
+*   app: Source code of DPDK applications (automatic tests)

-*   examples: Source code of Intel? DPDK applications
+*   examples: Source code of DPDK applications

 *   config, tools, scripts, mk: Framework-related makefiles, scripts and 
configuration

-Installation of the Intel? DPDK Target Environments

+Installation of the DPDK Target Environments
+

-The format of an Intel? DPDK target is:
+The format of a DPDK target is:

 ARCH-MACHINE-EXECENV-TOOLCHAIN

@@ -153,7 +153,7 @@ Where:

 *   TOOLCHAIN is: gcc | clang

-The configuration files for the Intel? DPDK targets can be found in the 

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

[Sujith Sankar (ssujith)]

On 16/12/14 4:06 pm, "Burakov, Anatoly"  wrote:

>> -Original Message-
>> From: Sujith Sankar (ssujith) [mailto:ssujith at cisco.com]
>> Sent: Tuesday, December 16, 2014 10:34 AM
>> To: Burakov, Anatoly; Thomas Monjalon
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] enic: corrected the usage of
>>VFIO_PRESENT
>> 
>> 
>> 
>> On 16/12/14 3:52 pm, "Burakov, Anatoly" 
>> wrote:
>> 
>> >> On 16/12/14 4:54 am, "Thomas Monjalon"
>> 
>> >> wrote:
>> >>
>> >> >2014-12-12 13:48, Sujith Sankar:
>> >> >> This patch corrects the usage of the flag VFIO_PRESENT in enic
>> >>driver.
>> >> >
>> >> >Please, could you explain why the flag VFIO_PRESENT was not well
>> used?
>> >>
>> >> Without including eal_vfio.h, VFIO_PRESENT is not available in enic.
>> >> Hence VFIO specific code in enic was not getting compiled and some
>> >>errors  were generated during run-time.
>> >>
>> >> >
>> >> >> This has uncovered a few warnings, and this patch corrects those
>>too.
>> >> >[...]
>> >> >> --- a/lib/librte_pmd_enic/enic_main.c
>> >> >> +++ b/lib/librte_pmd_enic/enic_main.c
>> >> >> @@ -39,6 +39,7 @@
>> >> >>  #include 
>> >> >>  #include 
>> >> >>  #include 
>> >> >> +#include 
>> >> >>
>> >> >>  #include 
>> >> >>  #include 
>> >> >> @@ -46,6 +47,7 @@
>> >> >>  #include 
>> >> >>  #include 
>> >> >>  #include 
>> >> >> +#include 
>> >> >
>> >> >This header was not designed to be included by PMDs.
>> >> >It will break compilation on BSD.
>> >>
>> >> Is there an alternative to make VFIO_PRESENT available in enic?
>> >> Please advise.
>> >>
>> >> Thanks,
>> >> -Sujith
>> >>
>> >> >
>> >> >>  #include "enic_compat.h"
>> >> >>  #include "enic.h"
>> >> >> @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct
>> >> >>rte_pci_device *hwdev,
>> >> >>/* Nothing to be done */
>> >> >>  }
>> >> >>
>> >> >> +#ifndef VFIO_PRESENT
>> >> >>  static void
>> >> >>  enic_intr_handler(__rte_unused struct rte_intr_handle *handle,
>> >> >>void *arg)
>> >> >> @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct
>> >> >>rte_intr_handle *handle,
>> >> >>
>> >> >>enic_log_q_error(enic);
>> >> >>  }
>> >> >> +#endif
>> >> >
>> >> >--
>> >> >Thomas
>> >
>> >Hi Sujith
>> >
>> >Thomas is correct, VFIO code is designed to be EAL-only (mainly because
>> >it's Linuxapp-specific, and PMD's are intended to be cross-platform at
>> >least when it comes to compilation). Whatever it is that you're working
>> >around is better fixed in the EAL itself rather than in the PMD.
>> 
>> I agree with you and Thomas.  Let me find the root cause for the false
>>trigger.
>> 
>> Thanks,
>> -Sujith
>> 
>
>You may find it in EAL VFIO interrupts code. When VFIO enables some
>interrupt types, it manually sends a trigger. Normally, this "trigger"
>just enables interrupts, but maybe for ENIC it's different. I therefore
>suggest you to look there first.

Ok.  Thanks for the info, Anatoly.
ENIC does not need that trigger.  Let me take a look at that first.

Thanks,
-Sujith

>
>Thanks,
>Anatoly

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

[Burakov, Anatoly]

> -Original Message-
> From: Sujith Sankar (ssujith) [mailto:ssujith at cisco.com]
> Sent: Tuesday, December 16, 2014 10:34 AM
> To: Burakov, Anatoly; Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT
> 
> 
> 
> On 16/12/14 3:52 pm, "Burakov, Anatoly" 
> wrote:
> 
> >> On 16/12/14 4:54 am, "Thomas Monjalon"
> 
> >> wrote:
> >>
> >> >2014-12-12 13:48, Sujith Sankar:
> >> >> This patch corrects the usage of the flag VFIO_PRESENT in enic
> >>driver.
> >> >
> >> >Please, could you explain why the flag VFIO_PRESENT was not well
> used?
> >>
> >> Without including eal_vfio.h, VFIO_PRESENT is not available in enic.
> >> Hence VFIO specific code in enic was not getting compiled and some
> >>errors  were generated during run-time.
> >>
> >> >
> >> >> This has uncovered a few warnings, and this patch corrects those too.
> >> >[...]
> >> >> --- a/lib/librte_pmd_enic/enic_main.c
> >> >> +++ b/lib/librte_pmd_enic/enic_main.c
> >> >> @@ -39,6 +39,7 @@
> >> >>  #include 
> >> >>  #include 
> >> >>  #include 
> >> >> +#include 
> >> >>
> >> >>  #include 
> >> >>  #include 
> >> >> @@ -46,6 +47,7 @@
> >> >>  #include 
> >> >>  #include 
> >> >>  #include 
> >> >> +#include 
> >> >
> >> >This header was not designed to be included by PMDs.
> >> >It will break compilation on BSD.
> >>
> >> Is there an alternative to make VFIO_PRESENT available in enic?
> >> Please advise.
> >>
> >> Thanks,
> >> -Sujith
> >>
> >> >
> >> >>  #include "enic_compat.h"
> >> >>  #include "enic.h"
> >> >> @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct
> >> >>rte_pci_device *hwdev,
> >> >> /* Nothing to be done */
> >> >>  }
> >> >>
> >> >> +#ifndef VFIO_PRESENT
> >> >>  static void
> >> >>  enic_intr_handler(__rte_unused struct rte_intr_handle *handle,
> >> >> void *arg)
> >> >> @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct
> >> >>rte_intr_handle *handle,
> >> >>
> >> >> enic_log_q_error(enic);
> >> >>  }
> >> >> +#endif
> >> >
> >> >--
> >> >Thomas
> >
> >Hi Sujith
> >
> >Thomas is correct, VFIO code is designed to be EAL-only (mainly because
> >it's Linuxapp-specific, and PMD's are intended to be cross-platform at
> >least when it comes to compilation). Whatever it is that you're working
> >around is better fixed in the EAL itself rather than in the PMD.
> 
> I agree with you and Thomas.  Let me find the root cause for the false 
> trigger.
> 
> Thanks,
> -Sujith
> 

You may find it in EAL VFIO interrupts code. When VFIO enables some interrupt 
types, it manually sends a trigger. Normally, this "trigger" just enables 
interrupts, but maybe for ENIC it's different. I therefore suggest you to look 
there first.

Thanks,
Anatoly

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

[Sujith Sankar (ssujith)]

On 16/12/14 3:52 pm, "Burakov, Anatoly"  wrote:

>> On 16/12/14 4:54 am, "Thomas Monjalon" 
>> wrote:
>> 
>> >2014-12-12 13:48, Sujith Sankar:
>> >> This patch corrects the usage of the flag VFIO_PRESENT in enic
>>driver.
>> >
>> >Please, could you explain why the flag VFIO_PRESENT was not well used?
>> 
>> Without including eal_vfio.h, VFIO_PRESENT is not available in enic.
>> Hence VFIO specific code in enic was not getting compiled and some
>>errors
>> were generated during run-time.
>> 
>> >
>> >> This has uncovered a few warnings, and this patch corrects those too.
>> >[...]
>> >> --- a/lib/librte_pmd_enic/enic_main.c
>> >> +++ b/lib/librte_pmd_enic/enic_main.c
>> >> @@ -39,6 +39,7 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >>
>> >>  #include 
>> >>  #include 
>> >> @@ -46,6 +47,7 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >
>> >This header was not designed to be included by PMDs.
>> >It will break compilation on BSD.
>> 
>> Is there an alternative to make VFIO_PRESENT available in enic?  Please
>> advise.
>> 
>> Thanks,
>> -Sujith
>> 
>> >
>> >>  #include "enic_compat.h"
>> >>  #include "enic.h"
>> >> @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct
>> >>rte_pci_device *hwdev,
>> >>   /* Nothing to be done */
>> >>  }
>> >>
>> >> +#ifndef VFIO_PRESENT
>> >>  static void
>> >>  enic_intr_handler(__rte_unused struct rte_intr_handle *handle,
>> >>   void *arg)
>> >> @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct
>> >>rte_intr_handle *handle,
>> >>
>> >>   enic_log_q_error(enic);
>> >>  }
>> >> +#endif
>> >
>> >--
>> >Thomas
>
>Hi Sujith
>
>Thomas is correct, VFIO code is designed to be EAL-only (mainly because
>it's Linuxapp-specific, and PMD's are intended to be cross-platform at
>least when it comes to compilation). Whatever it is that you're working
>around is better fixed in the EAL itself rather than in the PMD.

I agree with you and Thomas.  Let me find the root cause for the false
trigger. 

Thanks,
-Sujith

>
>Thanks,
>Anatoly

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

[Burakov, Anatoly]

> On 16/12/14 4:54 am, "Thomas Monjalon" 
> wrote:
> 
> >2014-12-12 13:48, Sujith Sankar:
> >> This patch corrects the usage of the flag VFIO_PRESENT in enic driver.
> >
> >Please, could you explain why the flag VFIO_PRESENT was not well used?
> 
> Without including eal_vfio.h, VFIO_PRESENT is not available in enic.
> Hence VFIO specific code in enic was not getting compiled and some errors
> were generated during run-time.
> 
> >
> >> This has uncovered a few warnings, and this patch corrects those too.
> >[...]
> >> --- a/lib/librte_pmd_enic/enic_main.c
> >> +++ b/lib/librte_pmd_enic/enic_main.c
> >> @@ -39,6 +39,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  #include 
> >>  #include 
> >> @@ -46,6 +47,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >
> >This header was not designed to be included by PMDs.
> >It will break compilation on BSD.
> 
> Is there an alternative to make VFIO_PRESENT available in enic?  Please
> advise.
> 
> Thanks,
> -Sujith
> 
> >
> >>  #include "enic_compat.h"
> >>  #include "enic.h"
> >> @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct
> >>rte_pci_device *hwdev,
> >>/* Nothing to be done */
> >>  }
> >>
> >> +#ifndef VFIO_PRESENT
> >>  static void
> >>  enic_intr_handler(__rte_unused struct rte_intr_handle *handle,
> >>void *arg)
> >> @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct
> >>rte_intr_handle *handle,
> >>
> >>enic_log_q_error(enic);
> >>  }
> >> +#endif
> >
> >--
> >Thomas

Hi Sujith

Thomas is correct, VFIO code is designed to be EAL-only (mainly because it's 
Linuxapp-specific, and PMD's are intended to be cross-platform at least when it 
comes to compilation). Whatever it is that you're working around is better 
fixed in the EAL itself rather than in the PMD.

Thanks,
Anatoly

[dpdk-dev] [PATCH v2] add one option memory-only for secondary processes

[Bruce Richardson]

On Tue, Dec 16, 2014 at 09:26:48AM +, Chi, Xiaobo (NSN - CN/Hangzhou) wrote:
> Hi, Bruce,
> How about this patch, can it be merged to master branch? Thanks.
> 
> Brgs,
> Chi Xiaobo
> 

At this point, I think we are well past code-freeze for new features for 1.8,
but this looks a good candidate for 2.0 once the merge window for that opens.

/Bruce

> 
> -Original Message-
> From: Chi, Xiaobo (NSN - CN/Hangzhou) 
> Sent: Monday, December 15, 2014 5:58 PM
> To: 'ext Hiroshi Shimamoto'; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2] add one option memory-only for secondary 
> processes
> 
> Hi, Hiroshi,
> Yes, the should be performance degradation, not only due to the mempool 
> cache, but also due to process scheduling overhead (lead by no CPU pin.)
> I have not done the performance testing. In my project scenarios, those 
> SECONDARY processes only send/receive messages to/from the PRIMARY process 
> via mempool/ring, the throughput is not so high, so the performance 
> degradation is not critical to us. but there are dozens of SECONDARY 
> processes in our system, it will be hard to manually properly pin them to 
> different CPU cores, what we want is to apply linux standard scheduling 
> mechanism to do load balance between CPU cores.
> 
> Brgs,
> Chi Xiaobo
> 
> 
> -Original Message-
> From: ext Hiroshi Shimamoto [mailto:h-shimamoto at ct.jp.nec.com] 
> Sent: Thursday, December 11, 2014 11:03 AM
> To: Chi, Xiaobo (NSN - CN/Hangzhou); dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2] add one option memory-only for secondary 
> processes
> 
> Hi,
> 
> sorry for the delay.
> 
> > Subject: RE: [dpdk-dev] [PATCH v2] add one option memory-only for secondary 
> > processes
> > 
> > Hi, Hiroshi,
> > Yes, you are right, in order to avoid such problem, while create the 
> > mempool, which shall be shared between the primary
> > process and those secondary Processes, we need to assign the cache_size 
> > param value to be zero. And in order to make the
> > system more stable, it's better to define the RTE_MEMPOOL_CACHE_MAX_SIZE to 
> > be 0 in rte_config.h.
> 
> Yes, it prevents the data corruption, but it also hurts the performance.
> I think, if we use the mbuf w/o cache for PMD, we will see the performance 
> degradation.
> 
> Don't you have any number?
> 
> thanks,
> Hiroshi
> 
> > 
> > /* create the mempool */
> > struct rte_mempool *
> > rte_mempool_create(const char *name, unsigned n, unsigned elt_size,
> >unsigned cache_size, unsigned private_data_size,
> >rte_mempool_ctor_t *mp_init, void *mp_init_arg,
> >rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
> >int socket_id, unsigned flags);
> > 
> > 
> > Brgs,
> > Chi xiaobo
> > 
> > 
> > -Original Message-
> > From: ext Hiroshi Shimamoto [mailto:h-shimamoto at ct.jp.nec.com]
> > Sent: Wednesday, December 03, 2014 6:54 PM
> > To: Chi, Xiaobo (NSN - CN/Hangzhou); dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH v2] add one option memory-only for secondary 
> > processes
> > 
> > Hi,
> > 
> > > Subject: [dpdk-dev] [PATCH v2] add one option memory-only for secondary 
> > > processes
> > >
> > > From: Chi Xiaobo 
> > >
> > > Problem: There is one normal DPDK processes deployment scenarios: one 
> > > primary process and several (even hundreds) secondary
> > > processes; all outside packets/messages are sent/received by primary 
> > > process and then distribute them to those secondary
> > > processes by DPDK's ring/sharedmemory mechanism. In such scenarios, those 
> > > SECONDARY processes need only hugepage based
> > > sharememory mechanism and it???s upper libs (such as ring, mempool, 
> > > etc.), they need not cpu core pinning, iopl privilege
> > > changing , pci device, timer, alarm, interrupt, shared_driver_list,  
> > > core_info, threads for each core, etc. Then, for
> > > such kind of SECONDARY processes, the current rte_eal_init() is too heavy.
> > >
> > > Solution:One new EAL initializing argument, --memory-only, is added. It 
> > > is only for those SECONDARY processes which
> > only
> > > want to share memory with other processes. if this argument is defined, 
> > > users need not define those mandatory arguments,
> > > such as -c and -n, due to we don't want to pin such kind of processes to 
> > > any CPUs.
> > 
> > however, we need the lcore_id per thread to use mempool.
> > If the lcore_id is not initialized, it must be 0, and multiple threads will 
> > break
> > mempool caches per thread, because of race condition.
> > We have to assign lcore_id per thread, these ids must not be overlapped, or 
> > disable
> > mempool handling in SECONDARY process.
> > 
> > thanks,
> > Hiroshi
> > 
> > > Signed-off-by: Chi Xiaobo 
> > > ---
> > >  lib/librte_eal/common/eal_common_options.c | 17 ---
> > >  lib/librte_eal/common/eal_internal_cfg.h   |  1 +
> > >  lib/librte_eal/common/eal_options.h|  2 ++
> > >  

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

[Sujith Sankar (ssujith)]

On 16/12/14 1:21 pm, "Qiu, Michael"  wrote:

>On 12/16/2014 12:13 PM, Sujith Sankar (ssujith) wrote:
>> On 16/12/14 4:54 am, "Thomas Monjalon" 
>>wrote:
>>
>>> 2014-12-12 13:48, Sujith Sankar:
 This patch corrects the usage of the flag VFIO_PRESENT in enic driver.
>>> Please, could you explain why the flag VFIO_PRESENT was not well used?
>> Without including eal_vfio.h, VFIO_PRESENT is not available in enic.
>> Hence VFIO specific code in enic was not getting compiled and some
>>errors
>> were generated during run-time.
>>
 This has uncovered a few warnings, and this patch corrects those too.
>>> [...]
 --- a/lib/librte_pmd_enic/enic_main.c
 +++ b/lib/librte_pmd_enic/enic_main.c
 @@ -39,6 +39,7 @@
  #include 
  #include 
  #include 
 +#include 
  
  #include 
  #include 
 @@ -46,6 +47,7 @@
  #include 
  #include 
  #include 
 +#include 
>>> This header was not designed to be included by PMDs.
>>> It will break compilation on BSD.
>> Is there an alternative to make VFIO_PRESENT available in enic?  Please
>> advise.
>
>You can remove  VFIO_PRESENT check, it all been done in eal, you can
>check other nic pmds for reference.
>And seems you done the interrupt logic all by your self?
>
>Thanks,
>Michael

Thanks for the comment, Michael.

Without the code under VFIO_PRESENT flag, I was getting false notification
of interrupt at the beginning (cat /proc/interrupts showed all 0s).
Let me try to root cause it.  I shall get back after some debugging and
testing.

There was one more reason behind doing interrupt logic in enic.  No matter
how many interrupts the user configures, enic pmd needs only one.
There is no way to communicate that to the EAL.  I thought doing interrupt
login in enic could avoid registering that many interrupts.

Thanks,
-Sujith

>>  
>> Thanks,
>> -Sujith
>>
  #include "enic_compat.h"
  #include "enic.h"
 @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct
 rte_pci_device *hwdev,
/* Nothing to be done */
  }
  
 +#ifndef VFIO_PRESENT
  static void
  enic_intr_handler(__rte_unused struct rte_intr_handle *handle,
void *arg)
 @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct
 rte_intr_handle *handle,
  
enic_log_q_error(enic);
  }
 +#endif
>>> -- 
>>> Thomas
>>
>

[dpdk-dev] [PATCH] testpmd: limit port mask bits to RTE_MAX_ETHPORTS

[Neil Horman]

On Tue, Dec 16, 2014 at 01:50:06PM +, Bruce Richardson wrote:
> On Tue, Dec 16, 2014 at 02:40:09PM +0100, Thomas Monjalon wrote:
> > 2014-12-16 13:27, Bruce Richardson:
> > > The port mask parsing in testpmd allowed up to 64 bits to be processed,
> > > even if RTE_MAX_ETHPORTS is set to a max of 32. Fix this by only
> > > processing up to min(RTE_MAX_ETHPORTS,64) bits of the mask.
> > [...]
> > > - for (i = 0; i < 64; i++) {
> > > + for (i = 0; i < 64 && i < RTE_MAX_ETHPORTS; i++) {
> > 
> > Why not use RTE_MIN?
> > 
> > -- 
> > Thomas
> 
> Because this works equally well, and the change is simpler and clearer IMHO.
> However, if you feel very strongly about it, I can change it to use RTE_MIN
> instead. :-)
> 
> /Bruce
> 

Please do, checking the same variable for being less than 2 different values
isn't common practice.  Its common, and far more readable to use a min function
as Thomas indicates.  It also saves you doing an extra comparison every loop
iteration.

Neil

[dpdk-dev] [PATCH v3] i40e: workaround for X710 performance issues

[Chen, Jing D]

> -Original Message-
> From: Zhang, Helin
> Sent: Tuesday, December 16, 2014 4:23 PM
> To: dev at dpdk.org
> Cc: Chen, Jing D; Wu, Jingjing; Liu, Jijiang; Cao, Waterman; Lu, Patrick;
> Rowden, Aaron F; Zhang, Helin
> Subject: [PATCH v3] i40e: workaround for X710 performance issues
> 
> On X710, performance number is far from the expectation on recent
> firmware versions. The fix for this issue may not be integrated in
> the following firmware version. So the workaround in software driver
> is needed. It needs to modify the initial values of 3 internal only
> registers. Note that the workaround can be removed when it is fixed
> in firmware in the future.
> 
> Signed-off-by: Helin Zhang 
> ---
>  lib/librte_pmd_i40e/i40e_ethdev.c | 89
> +++
>  1 file changed, 89 insertions(+)
> 
> v2 changes:
> * Added a compile error fix.
> 
> v3 changes:
> * Used PRIx32 and PRIx64 instead for printing uint32_t and uint64_t
>   variables.
> * Re-worded annotations, and commit logs.
> 
> diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
> b/lib/librte_pmd_i40e/i40e_ethdev.c
> index 008d62c..624f0ce 100644
> --- a/lib/librte_pmd_i40e/i40e_ethdev.c
> +++ b/lib/librte_pmd_i40e/i40e_ethdev.c
> @@ -198,6 +198,7 @@ static int i40e_dev_filter_ctrl(struct rte_eth_dev *dev,
>   enum rte_filter_type filter_type,
>   enum rte_filter_op filter_op,
>   void *arg);
> +static void i40e_configure_registers(struct i40e_hw *hw);
> 
>  /* Default hash key buffer for RSS */
>  static uint32_t rss_key_default[I40E_PFQF_HKEY_MAX_INDEX + 1];
> @@ -443,6 +444,16 @@ eth_i40e_dev_init(__rte_unused struct eth_driver
> *eth_drv,
>   /* Clear PXE mode */
>   i40e_clear_pxe_mode(hw);
> 
> + /*
> +  * On X710, performance number is far from the expectation on
> recent
> +  * firmware versions. The fix for this issue may not be integrated in
> +  * the following firmware version. So the workaround in software
> driver
> +  * is needed. It needs to modify the initial values of 3 internal only
> +  * registers. Note that the workaround can be removed when it is
> fixed
> +  * in firmware in the future.
> +  */
> + i40e_configure_registers(hw);
> +
>   /* Get hw capabilities */
>   ret = i40e_get_cap(hw);
>   if (ret != I40E_SUCCESS) {
> @@ -5294,3 +5305,81 @@ i40e_pctype_to_flowtype(enum
> i40e_filter_pctype pctype)
> 
>   return flowtype_table[pctype];
>  }
> +
> +static int
> +i40e_debug_read_register(struct i40e_hw *hw, uint32_t addr, uint64_t
> *val)
> +{
> + struct i40e_aq_desc desc;
> + struct i40e_aqc_debug_reg_read_write *cmd =
> + (struct i40e_aqc_debug_reg_read_write
> *)
> + enum i40e_status_code status;
> +
> + i40e_fill_default_direct_cmd_desc(,
> i40e_aqc_opc_debug_read_reg);
> + cmd->address = rte_cpu_to_le_32(addr);
> + status = i40e_asq_send_command(hw, , NULL, 0, NULL);
> + if (status < 0)
> + return status;
> +
> + *val = ((uint64_t)(rte_le_to_cpu_32(cmd->value_high)) <<
> (CHAR_BIT *
> + sizeof(uint32_t))) + rte_le_to_cpu_32(cmd-
> >value_low);
> +
> + return status;
> +}
> +
> +/*
> + * On X710, performance number is far from the expectation on recent
> firmware
> + * versions. The fix for this issue may not be integrated in the following
> + * firmware version. So the workaround in software driver is needed. It
> needs
> + * to modify the initial values of 3 internal only registers. Note that the
> + * workaround can be removed when it is fixed in firmware in the future.
> + */
> +static void
> +i40e_configure_registers(struct i40e_hw *hw)
> +{
> +#define I40E_GL_SWR_PRI_JOIN_MAP_0   0x26CE00
> +#define I40E_GL_SWR_PRI_JOIN_MAP_2   0x26CE08
> +#define I40E_GL_SWR_PM_UP_THR0x269FBC
> +#define I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE 0x1200
> +#define I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE 0x011f0200
> +#define I40E_GL_SWR_PM_UP_THR_VALUE  0x03030303
> +
> + static const struct {
> + uint32_t addr;
> + uint64_t val;
> + } reg_table[] = {
> + {I40E_GL_SWR_PRI_JOIN_MAP_0,
> I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE},
> + {I40E_GL_SWR_PRI_JOIN_MAP_2,
> I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE},
> + {I40E_GL_SWR_PM_UP_THR,
> I40E_GL_SWR_PM_UP_THR_VALUE},
> + };
> + uint64_t reg;
> + uint32_t i;
> + int ret;
> +
> + /* Below fix is for X710 only */
> + if (i40e_is_40G_device(hw->device_id))
> + return;
> +
> + for (i = 0; i < RTE_DIM(reg_table); i++) {
> + ret = i40e_debug_read_register(hw, reg_table[i].addr, );
> + if (ret < 0) {
> + PMD_DRV_LOG(ERR, "Failed to read from
> 0x%"PRIx32,
> + reg_table[i].addr);
> + break;
> + }
> + 

[dpdk-dev] [PATCH 17/17] libte_acl: fix compilation issues with RTE_LIBRTE_ACL_STANDALONE=y.

[Neil Horman]

On Sun, Dec 14, 2014 at 06:10:59PM +, Konstantin Ananyev wrote:
> Signed-off-by: Konstantin Ananyev 
> ---
>  lib/librte_acl/rte_acl_osdep_alone.h | 47 
> ++--
>  1 file changed, 45 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_acl/rte_acl_osdep_alone.h 
> b/lib/librte_acl/rte_acl_osdep_alone.h
> index a84b6f9..58c4f6a 100644
> --- a/lib/librte_acl/rte_acl_osdep_alone.h
> +++ b/lib/librte_acl/rte_acl_osdep_alone.h
> @@ -57,6 +57,10 @@
>  #include 
>  #endif
>  
> +#if defined(__AVX__)
> +#include 
> +#endif
> +
>  #else
>  
>  #include 
> @@ -128,8 +132,8 @@ typedef __m128i xmm_t;
>  #define  XMM_SIZE(sizeof(xmm_t))
>  #define  XMM_MASK(XMM_SIZE - 1)
>  
> -typedef union rte_mmsse {
> - xmm_tm;
> +typedef union rte_xmm {
> + xmm_tx;
>   uint8_t  u8[XMM_SIZE / sizeof(uint8_t)];
>   uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
>   uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
> @@ -137,6 +141,33 @@ typedef union rte_mmsse {
>   double   pd[XMM_SIZE / sizeof(double)];
>  } rte_xmm_t;
>  
> +#ifdef __AVX__
> +
> +typedef __m256i ymm_t;
> +
> +#define  YMM_SIZE(sizeof(ymm_t))
> +#define  YMM_MASK(YMM_SIZE - 1)
> +
> +typedef union rte_ymm {
> + ymm_ty;
> + xmm_tx[YMM_SIZE / sizeof(xmm_t)];
> + uint8_t  u8[YMM_SIZE / sizeof(uint8_t)];
> + uint16_t u16[YMM_SIZE / sizeof(uint16_t)];
> + uint32_t u32[YMM_SIZE / sizeof(uint32_t)];
> + uint64_t u64[YMM_SIZE / sizeof(uint64_t)];
> + double   pd[YMM_SIZE / sizeof(double)];
> +} rte_ymm_t;
> +
> +#endif /* __AVX__ */
> +
> +#ifdef RTE_ARCH_I686
> +#define _mm_cvtsi128_si64(a) ({ \
> + rte_xmm_t m;\
> + m.x = (a);  \
> + (m.u64[0]); \
> +})
> +#endif
> +
>  /*
>   * rte_cycles related.
>   */
> @@ -214,6 +245,13 @@ rte_rdtsc(void)
>  /*
>   * rte_tailq related.
>   */
> +
> +struct rte_tailq_entry {
> + TAILQ_ENTRY(rte_tailq_entry) next; /**< Pointer entries for a tailq list
> + */
> + void *data; /**< Pointer to the data referenced by this tailq entry */
> +};
> +
>  static inline void *
>  rte_dummy_tailq(void)
>  {
> @@ -248,6 +286,7 @@ rte_zmalloc_socket(__rte_unused const char *type, size_t 
> size, unsigned align,
>   void *ptr;
>   int rc;
>  
> + align = (align != 0) ? align : RTE_CACHE_LINE_SIZE;
>   rc = posix_memalign(, align, size);
>   if (rc != 0) {
>   rte_errno = rc;
> @@ -258,6 +297,8 @@ rte_zmalloc_socket(__rte_unused const char *type, size_t 
> size, unsigned align,
>   return ptr;
>  }
>  
> +#define  rte_zmalloc(type, sz, align)rte_zmalloc_socket(type, sz, 
> align, 0)
> +
>  /*
>   * rte_debug related
>   */
> @@ -271,6 +312,8 @@ rte_zmalloc_socket(__rte_unused const char *type, size_t 
> size, unsigned align,
>   exit(err);   \
>  } while (0)
>  
> +#define  rte_cpu_get_flag_enabled(x) (0)
> +
>  #ifdef __cplusplus
>  }
>  #endif
> -- 
> 1.8.5.3
> 
> 
I think you should merge these changes with patch 10 where the problem was
introduced, so that you avoid a FTBFS issue
Neil

[dpdk-dev] [PATCH v2] bond: static analysis issues fix

[Wodkowski, PawelX]

> -Original Message-
> From: Doherty, Declan
> Sent: Monday, December 15, 2014 6:14 PM
> To: dev at dpdk.org
> Cc: Wodkowski, PawelX; Doherty, Declan
> Subject: [PATCH v2] bond: static analysis issues fix
> 
> -v2:
> Incorporates Pawel's comments regarding assertion's check on activate_slave
> array indexing
> 
> Fixes for link bonding library identified by static analysis tool
> 
> - Overflow assert for active_slaves array in activate_slave function
> - Allocation check of pci_id_table in rte_eth_bond_create
> - Use of eth_dev pointer in mac_address_get/set before NULL check
> 
> Signed-off-by: Declan Doherty 
> ---
> 

Acked-by: Wodkowski, Pawel 

[dpdk-dev] [PATCH] Minor fixes in rte_common.h file.

[Ravi Kerur]

On Sat, Dec 13, 2014 at 2:39 AM, Neil Horman  wrote:
>
> On Fri, Dec 12, 2014 at 03:04:34PM -0800, r k wrote:
> > Subject: [PATCH] Minor fixes in rte_common.h file.
> >
> > Fix rte_is_power_of_2 since 0 is not.
> > Avoid branching instructions in RTE_MAX and RTE_MIN.
> >
> > Signed-off-by: Ravi Kerur 
> > ---
> >  lib/librte_eal/common/include/rte_common.h | 6 +++---
> >  lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
> >  lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
> >  3 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/rte_common.h
> > b/lib/librte_eal/common/include/rte_common.h
> > index 921b91f..e163f35 100644
> > --- a/lib/librte_eal/common/include/rte_common.h
> > +++ b/lib/librte_eal/common/include/rte_common.h
> > @@ -203,7 +203,7 @@ extern int RTE_BUILD_BUG_ON_detected_error;  static
> > inline int  rte_is_power_of_2(uint32_t n)  {
> > -   return ((n-1) & n) == 0;
> > +   return n && !(n & (n - 1));
> >  }
> >
> >  /**
> > @@ -259,7 +259,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MIN(a, b)
> ({ \
> > typeof (a) _a = (a); \
> > typeof (b) _b = (b); \
> > -   _a < _b ? _a : _b; \
> > +_b ^ ((_a ^ _b) & -(_a < _b)); \
> Are you sure this is actually faster than the branch version?  What about
> using
> a cmov instead?
>
>
 i am pretty sure modified code is faster than branching. I remember
cmov had performance issues esp. on Pentuim-4 not sure how new intel cpu's
perform.

> })
> >
> >  /**
> > @@ -268,7 +268,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MAX(a, b)
> ({ \
> > typeof (a) _a = (a); \
> > typeof (b) _b = (b); \
> > -   _a > _b ? _a : _b; \
> > +   _a ^ ((_a ^ _b) & -(_a < _b)); \
> Same as above
>
>  Same as above.

> > })
> >
> >  /*** Other general functions / macros / diff --git
> > a/lib/librte_pmd_e1000/igb_pf.c b/lib/librte_pmd_e1000/igb_pf.c index
> > bc3816a..546499c 100644
> > --- a/lib/librte_pmd_e1000/igb_pf.c
> > +++ b/lib/librte_pmd_e1000/igb_pf.c
> > @@ -321,11 +321,11 @@ igb_vf_set_mac_addr(struct rte_eth_dev *dev,
> uint32_t
> > vf, uint32_t *msgbuf)  static int  igb_vf_set_multicast(struct
> rte_eth_dev
> > *dev, __rte_unused uint32_t vf, uint32_t *msgbuf)  {
> > -   int i;
> > +   int16_t i;
> > uint32_t vector_bit;
> > uint32_t vector_reg;
> > uint32_t mta_reg;
> > -   int entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
> > +   int32_t entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
> > E1000_VT_MSGINFO_SHIFT;
> NAK, this has nothing to do with the included changelog
>

 It does, it causes compilation errors such as

/root/dpdk-new/dpdk/lib/librte_pmd_e1000/igb_pf.c: In function
\u2018igb_pf_mbx_process\u2019:
/root/dpdk-new/dpdk/lib/librte_pmd_e1000/igb_pf.c:350:23: error: array
subscript is above array bounds [-Werror=array-bounds]
   vfinfo->vf_mc_hashes[i] = hash_list[i];
   ^
cc1: all warnings being treated as errors

Also it is always better to use explicit int definitions esp. for 64bit
systems.



>
> > uint16_t *hash_list = (uint16_t *)[1];
> > struct e1000_hw *hw =
> > E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c
> > b/lib/librte_pmd_ixgbe/ixgbe_pf.c index 51da1fd..426caf9 100644
> > --- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
> > +++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
> > @@ -390,7 +390,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev,
> > __rte_unused uint32_t vf, uint32
> > struct ixgbe_hw *hw =
> > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > struct ixgbe_vf_info *vfinfo =
> > *(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
> > -   int nb_entries = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
> > +   int32_t nb_entries = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
> > IXGBE_VT_MSGINFO_SHIFT;
> ditto
> > uint16_t *hash_list = (uint16_t *)[1];
> > uint32_t mta_idx;
> > @@ -399,7 +399,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev,
> > __rte_unused uint32_t vf, uint32
> > const uint32_t IXGBE_MTA_BIT_SHIFT = 5;
> > const uint32_t IXGBE_MTA_BIT_MASK = (0x1 << IXGBE_MTA_BIT_SHIFT)
> -
> > 1;
> > uint32_t reg_val;
> > -   int i;
> > +   int16_t i;
> ditto
>
>  Same as above.

> >
> > /* only so many hash values supported */
> > nb_entries = RTE_MIN(nb_entries, IXGBE_MAX_VF_MC_ENTRIES);
> > --
> > 1.9.1
> >
>

[dpdk-dev] [PATCH v2] i40e: workaround for X710 performance issues

[Chen, Jing D]

Hi Helin,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Helin Zhang
> Sent: Monday, December 15, 2014 3:56 PM
> To: dev at dpdk.org
> Cc: Rowden, Aaron F
> Subject: [dpdk-dev] [PATCH v2] i40e: workaround for X710 performance
> issues
> 
> As the fixes of below performance issues on X710 may not be integrated
> in latest version of firmware, a workaround in software PMD is needed.
> It is to re-configure 3 specific registers after being initialized.
> - Cannot achieve line rate on X710.

packet size? 

> - Performance reduction when promiscuous mode is disabled.

You'd better add above descriptions in line with the code.

> Note that this workaround can be removed if the fixes are integrated
> in the firmware in future.
> 

I saw below code applied register setting in case it's 40G device. Can you give
more description on what device this patch would boost performance?
Will 10G fiber interface benefit from the change?

> Signed-off-by: Helin Zhang 
> ---
>  lib/librte_pmd_i40e/i40e_ethdev.c | 87
> +++
>  1 file changed, 87 insertions(+)
> 
> v2 changes:
> * Added a compile error fix.
> 
> diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
> b/lib/librte_pmd_i40e/i40e_ethdev.c
> index 008d62c..82c072b 100644
> --- a/lib/librte_pmd_i40e/i40e_ethdev.c
> +++ b/lib/librte_pmd_i40e/i40e_ethdev.c
> @@ -198,6 +198,7 @@ static int i40e_dev_filter_ctrl(struct rte_eth_dev *dev,
>   enum rte_filter_type filter_type,
>   enum rte_filter_op filter_op,
>   void *arg);
> +static void i40e_configure_registers(struct i40e_hw *hw);
> 
>  /* Default hash key buffer for RSS */
>  static uint32_t rss_key_default[I40E_PFQF_HKEY_MAX_INDEX + 1];
> @@ -443,6 +444,15 @@ eth_i40e_dev_init(__rte_unused struct eth_driver
> *eth_drv,
>   /* Clear PXE mode */
>   i40e_clear_pxe_mode(hw);
> 
> + /*
> +  * On X710, as old version of firmwares may have performance issues,
> +  * 3 registers need to be re-configured with new values. And the
> latest
> +  * version of firmware may not contain the fixes, workaround in SW
> +  * driver is needed. This workaround can be removed when the fixes
> are
> +  * integrated in firmware in future.
> +  */
> + i40e_configure_registers(hw);
> +
>   /* Get hw capabilities */
>   ret = i40e_get_cap(hw);
>   if (ret != I40E_SUCCESS) {
> @@ -5294,3 +5304,80 @@ i40e_pctype_to_flowtype(enum
> i40e_filter_pctype pctype)
> 
>   return flowtype_table[pctype];
>  }
> +
> +static int
> +i40e_debug_read_register(struct i40e_hw *hw, uint32_t addr, uint64_t
> *val)
> +{
> + struct i40e_aq_desc desc;
> + struct i40e_aqc_debug_reg_read_write *cmd =
> + (struct i40e_aqc_debug_reg_read_write
> *)
> + enum i40e_status_code status;
> +
> + i40e_fill_default_direct_cmd_desc(,
> i40e_aqc_opc_debug_read_reg);
> + cmd->address = rte_cpu_to_le_32(addr);
> + status = i40e_asq_send_command(hw, , NULL, 0, NULL);
> + if (status < 0)
> + return status;
> +
> + *val = ((uint64_t)(rte_le_to_cpu_32(cmd->value_high)) <<
> (CHAR_BIT *
> + sizeof(uint32_t))) + rte_le_to_cpu_32(cmd-
> >value_low);
> +
> + return status;
> +}
> +
> +/*
> + * On X710, as old version of firmwares may have performance issues,
> + * 3 registers need to be re-configured with new values. And the latest
> version
> + * of firmware may not contain the fixes, workaround in SW driver is
> needed.
> + * This workaround can be removed when the fixes are integrated in
> firmware in
> + * future.
> + */
> +static void
> +i40e_configure_registers(struct i40e_hw *hw)
> +{
> +#define I40E_GL_SWR_PRI_JOIN_MAP_0   0x26CE00
> +#define I40E_GL_SWR_PRI_JOIN_MAP_2   0x26CE08
> +#define I40E_GL_SWR_PM_UP_THR0x269FBC
> +#define I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE 0x1200
> +#define I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE 0x011f0200
> +#define I40E_GL_SWR_PM_UP_THR_VALUE  0x03030303
> +
> + static const struct {
> + uint32_t addr;
> + uint64_t val;
> + } reg_table[] = {
> + {I40E_GL_SWR_PRI_JOIN_MAP_0,
> I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE},
> + {I40E_GL_SWR_PRI_JOIN_MAP_2,
> I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE},
> + {I40E_GL_SWR_PM_UP_THR,
> I40E_GL_SWR_PM_UP_THR_VALUE},
> + };
> + uint64_t reg;
> + uint32_t i;
> + int ret;
> +
> + /* Below fix is for X710 only */
> + if (i40e_is_40G_device(hw->device_id))
> + return;
> +
> + for (i = 0; i < RTE_DIM(reg_table); i++) {
> + ret = i40e_debug_read_register(hw, reg_table[i].addr, );
> + if (ret < 0) {
> + PMD_DRV_LOG(ERR, "Failed to read from 0x%x\n",
> + reg_table[i].addr);
> + break;
> + }
> + 

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

[Thomas Monjalon]

2014-12-12 13:48, Sujith Sankar:
> This patch corrects the usage of the flag VFIO_PRESENT in enic driver.

Please, could you explain why the flag VFIO_PRESENT was not well used?

> This has uncovered a few warnings, and this patch corrects those too.
[...]
> --- a/lib/librte_pmd_enic/enic_main.c
> +++ b/lib/librte_pmd_enic/enic_main.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -46,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

This header was not designed to be included by PMDs.
It will break compilation on BSD.

>  #include "enic_compat.h"
>  #include "enic.h"
> @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct rte_pci_device 
> *hwdev,
>   /* Nothing to be done */
>  }
>  
> +#ifndef VFIO_PRESENT
>  static void
>  enic_intr_handler(__rte_unused struct rte_intr_handle *handle,
>   void *arg)
> @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct rte_intr_handle 
> *handle,
>  
>   enic_log_q_error(enic);
>  }
> +#endif

-- 
Thomas