[dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api

[Ananyev, Konstantin]

> -Original Message-
> From: Kulasek, TomaszX
> Sent: Tuesday, February 09, 2016 5:03 PM
> To: Ananyev, Konstantin; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> 
> 
> 
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Tuesday, February 2, 2016 14:50
> > To: Kulasek, TomaszX ; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> >
> > Hi Tomasz,
> >
> > > -Original Message-
> > > From: Kulasek, TomaszX
> > > Sent: Tuesday, February 02, 2016 10:01 AM
> > > To: Ananyev, Konstantin; dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> > >
> > > Hi Konstantin,
> > >
> > > > -Original Message-
> > > > From: Ananyev, Konstantin
> > > > Sent: Friday, January 15, 2016 19:45
> > > > To: Kulasek, TomaszX; dev at dpdk.org
> > > > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> > > >
> > > > Hi Tomasz,
> > > >
> > > > >
> > > > > + /* get new buffer space first, but keep old space around
> > */
> > > > > + new_bufs = rte_zmalloc("ethdev->txq_bufs",
> > > > > + sizeof(*dev->data->txq_bufs) * 
> > > > > nb_queues, 0);
> > > > > + if (new_bufs == NULL)
> > > > > + return -(ENOMEM);
> > > > > +
> > > >
> > > > Why not to allocate space for txq_bufs together with tx_queues (as
> > > > one chunk for both)?
> > > > As I understand there is always one to one mapping between them
> > anyway.
> > > > Would simplify things a bit.
> > > > Or even introduce a new struct to group with all related tx queue
> > > > info togetehr struct rte_eth_txq_data {
> > > > void *queue; /*actual pmd  queue*/
> > > > struct rte_eth_dev_tx_buffer buf;
> > > > uint8_t state;
> > > > }
> > > > And use it inside struct rte_eth_dev_data?
> > > > Would probably give a better data locality.
> > > >
> > >
> > > Introducing such a struct will require a huge rework of pmd drivers. I
> > don't think it's worth only for this one feature.
> >
> > Why not?
> > Things are getting more and more messy here: now we have a separate array
> > of pointer to queues, Separate array of queue states, you are going to add
> > separate array of tx buffers.
> > For me it seems logical to unite all these 3 fields into one sub-struct.
> >
> 
> I agree with you, and probably such a work will be nice also for rx queues, 
> but these two changes impacts on another part of dpdk.
> While buffered tx API is more client application helper.
> 
> For me these two thinks are different features and should be made separately 
> because:
> 1) They are independent and can be done separately,
> 2) They can (and should) be reviewed, tested and approved separately,
> 3) They are addressed to another type of people (tx buffering to application 
> developers, rte_eth_dev_data to pmd developers), so
> another people can be interested in having (or not) one or second feature

Such division seems a bit artificial to me :)
You are making changes in rte_ethdev.[c,h]  - I think that filed regrouping 
would make code cleaner and easier to read/maintain.

> 
> Even for bug tracking it will be cleaner to separate these two things. And 
> yes, it is logical to unite it, maybe also for rx queues, but
> should be discussed separately.
> 
> I've made a prototype with this rework, and the impact on the code not 
> related to this particular feature is too wide and strong to join
> them. I would rather to provide it as independent patch for further 
> discussion only on it, if needed.

Sure, separate patch is fine.
Why not to submit it as extra one is the series?


> 
> > >
> > >
> > > > > +/**
> > > > > + * @internal
> > > > > + * Structure used to buffer packets for future TX
> > > > > + * Used by APIs rte_eth_tx_buffer and rte_eth_tx_buffer_flush  */
> > > > > +struct rte_eth_dev_tx_buffer {
> > > > > + struct rte_mbuf *pkts[RTE_ETHDEV_TX_BUFSIZE];
> > > >
> > > > I think it is better to make size of pkts[] configurable at runtime.
> > > > There are a lot of different usage scenarios - hard to predict what
> > > > would be an optimal buffer size for all cases.
> > > >
> > >
> > > This buffer is allocated in eth_dev shared memory, so there are two
> > scenarios:
> > > 1) We have prealocated buffer with maximal size, and then we can set
> > > threshold level without restarting device, or
> > > 2) We need to set its size before starting device.
> >
> > >
> > > Second one is better, I think.
> >
> > Yep, I was thinking about 2) too.
> > Might be an extra parameter in struct rte_eth_txconf.
> >
> 
> Struct rte_eth_txconf is passed to ethdev after rte_eth_dev_tx_queue_config, 
> so we don't know its value when buffers are
> allocated.

Ok, and why allocation of the tx buffer can't be done at 
rte_eth_tx_queue_setup()? 

Actually just thought why not to let rte_eth_tx_buffer() to accept struct 
rte_eth_dev_tx_buffer * as a parameter:

[dpdk-dev] [PATCH v2 1/3] driver/net/mpipe: support native build on tilegx platform.

[Thomas Monjalon]

2016-02-09 21:15, Liming Sun:
> Looks like this patch serie has been merged into dpdk-next-net/rel_16_04.
> What would be the usual way to submit changes for new comments? Would it be 
> incremental changes (new commit) based on previous one? Thanks.

Good question.
I think it's better if Bruce drops or reverts the commits from dpdk-next-net
to let you re-submit a better new version.
Bruce, do you agree?

[dpdk-dev] Regarding mbuf allocation/free in secondary process

[Saravana Kumar]

Hi DPDK community,



I'd like to have DPDK NIC IO operations in (primary) process and
execution logic in (secondary) processes.
Primary process pushes NIC Rx mbufs to Secondary process through S/W ring

Seconary process allocates mbuf for Tx path and pushes down to Primary
process for NIC Tx


I have few doubts here:

1. If Secondary process dies because of SIGKILL then how can the mbufs
allocated in Secondary process can be freed.
   If it is normal signals like SIGINT/SIGTERM then we can be catch
those and free in those respective signal handlers

2. Secondary process needs to poll on the S/W ring. This can consume 100% cpu.
   Is there a way to avoid polling in secondary process for Rx path

Thanks

Sara

[dpdk-dev] [PATCH v4 2/2] driver/net/mpipe: some code optimization

[Liming Sun]

This commit includes two small code optimization.
1. use __insn_fetchadd4() instead of rte_atomic32_xxx() in
   mpipe_dp_enter/mpipe_dp_exit to avoid the nnecessary memory
   fence.
2. replace the calling of rte_pktmbuf_reset() in mpipe_recv_mbuf()
   with specific code to avoid some duplicated initializations.

Signed-off-by: Liming Sun 
Acked-by: Zhigang Lu 
---
 drivers/net/mpipe/mpipe_tilegx.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 5845511..8d006fa 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -451,13 +451,13 @@ static inline void
 mpipe_dp_enter(struct mpipe_dev_priv *priv)
 {
__insn_mtspr(SPR_DSTREAM_PF, 0);
-   rte_atomic32_inc(>dp_count);
+   __insn_fetchadd4(>dp_count, 1);
 }

 static inline void
 mpipe_dp_exit(struct mpipe_dev_priv *priv)
 {
-   rte_atomic32_dec(>dp_count);
+   __insn_fetchadd4(>dp_count, -1);
 }

 static inline void
@@ -484,12 +484,20 @@ mpipe_recv_mbuf(struct mpipe_dev_priv *priv, 
gxio_mpipe_idesc_t *idesc,
uint16_t size = gxio_mpipe_idesc_get_xfer_size(idesc);
struct rte_mbuf *mbuf = RTE_PTR_SUB(va, priv->rx_offset);

-   rte_pktmbuf_reset(mbuf);
mbuf->data_off = (uintptr_t)va - (uintptr_t)mbuf->buf_addr;
-   mbuf->port = in_port;
-   mbuf->data_len = size;
+   mbuf->nb_segs = 1;
+   mbuf->port = in_port;
+   mbuf->ol_flags = 0;
+   if (gxio_mpipe_idesc_get_ethertype(idesc) == ETHER_TYPE_IPv4)
+   mbuf->packet_type = RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L2_ETHER;
+   else if (gxio_mpipe_idesc_get_ethertype(idesc) == ETHER_TYPE_IPv6)
+   mbuf->packet_type = RTE_PTYPE_L3_IPV6 | RTE_PTYPE_L2_ETHER;
+   else
+   mbuf->packet_type = RTE_PTYPE_UNKNOWN;
mbuf->pkt_len  = size;
+   mbuf->data_len = size;
mbuf->hash.rss = gxio_mpipe_idesc_get_flow_hash(idesc);
+   mbuf->next = NULL;

PMD_DEBUG_RX("%s: RX mbuf %p, buffer %p, buf_addr %p, size %d\n",
 mpipe_name(priv), mbuf, va, mbuf->buf_addr, size);
-- 
1.8.3.1

[dpdk-dev] [PATCH v4 1/2] eal/tile: add rte_vect.h and enable CONFIG_RTE_LIBRTE_LPM

[Liming Sun]

rte_vect.h was missing earlier thus LPM was disabled and l3fwd is
not able to compile. This commit implements the vector api and
enable LPM in the tilegx configuration by default.

Signed-off-by: Liming Sun 
Acked-by: Zhigang Lu 
---
 config/defconfig_tile-tilegx-linuxapp-gcc  |  2 +-
 lib/librte_eal/common/include/arch/tile/rte_vect.h | 93 ++
 2 files changed, 94 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_eal/common/include/arch/tile/rte_vect.h

diff --git a/config/defconfig_tile-tilegx-linuxapp-gcc 
b/config/defconfig_tile-tilegx-linuxapp-gcc
index fb61bcd..39794f6 100644
--- a/config/defconfig_tile-tilegx-linuxapp-gcc
+++ b/config/defconfig_tile-tilegx-linuxapp-gcc
@@ -64,7 +64,7 @@ CONFIG_RTE_LIBRTE_ENIC_PMD=n

 # This following libraries are not available on the tile architecture.
 # So they're turned off.
-CONFIG_RTE_LIBRTE_LPM=n
+CONFIG_RTE_LIBRTE_LPM=y
 CONFIG_RTE_LIBRTE_ACL=n
 CONFIG_RTE_LIBRTE_SCHED=n
 CONFIG_RTE_LIBRTE_PORT=n
diff --git a/lib/librte_eal/common/include/arch/tile/rte_vect.h 
b/lib/librte_eal/common/include/arch/tile/rte_vect.h
new file mode 100644
index 000..9afee70
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/tile/rte_vect.h
@@ -0,0 +1,93 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) EZchip Semiconductor Ltd. 2016.
+ *
+ *   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 EZchip Semiconductor 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.
+*/
+
+#ifndef _RTE_VECT_H_
+#define _RTE_VECT_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef __int128 __m128i;
+
+#defineXMM_SIZEsizeof(__m128i)
+#defineXMM_MASK(XMM_SIZE - 1)
+
+typedef union rte_xmm {
+   __m128i x;
+   uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
+   uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
+} rte_xmm_t;
+
+/* Extracts the low order 64-bit integer. */
+#define _mm_cvtsi128_si64(a) ((rte_xmm_t*))->u64[0]
+
+/* Sets the 2 signed 64-bit integer values. */
+#define _mm_set_epi64x(i1, i0) ({ \
+   rte_xmm_t m;  \
+   m.u64[0] = i0;\
+   m.u64[1] = i1;\
+   (m.x);\
+})
+
+/* Sets the 4 signed 32-bit integer values. */
+#define _mm_set_epi32(i3, i2, i1, i0)  ({ \
+   rte_xmm_t m;  \
+   m.u32[0] = i0;\
+   m.u32[1] = i1;\
+   m.u32[2] = i2;\
+   m.u32[3] = i3;\
+   (m.x);\
+})
+
+/* Shifts right the 4 32-bit integers by count bits with zeros. */
+#define _mm_srli_epi32(v, cnt) ({  \
+   rte_xmm_t m; \
+   m.u64[0] = __insn_v4shru(((rte_xmm_t*)&(v))->u64[0], cnt); \
+   m.u64[1] = __insn_v4shru(((rte_xmm_t*)&(v))->u64[1], cnt); \
+   (m.x);   \
+})
+
+/* Shifts the 128-bit value in a right by imm bytes. */
+#define _mm_srli_si128(v, imm) ((v) >> (imm * sizeof(uint8_t)))
+
+/* Bitwise AND of the 128-bit value in a and the 128-bit value in b. */
+#define _mm_and_si128(a, b) ((a) & (b))
+
+/* Loads 128-bit value. */
+#define _mm_loadu_si128(p) (*(p))
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_VECT_H_ */
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 2/2] driver/net/mpipe: some code optimization

[Liming Sun]

This commit includes two small code optimization.
1. use __insn_fetchadd4() instead of rte_atomic32_xxx() in
   mpipe_dp_enter/mpipe_dp_exit to avoid the nnecessary memory
   fence.
2. replace the calling of rte_pktmbuf_reset() in mpipe_recv_mbuf()
   with specific code to avoid some duplicated initializations.
---
 drivers/net/mpipe/mpipe_tilegx.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 5845511..8d006fa 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -451,13 +451,13 @@ static inline void
 mpipe_dp_enter(struct mpipe_dev_priv *priv)
 {
__insn_mtspr(SPR_DSTREAM_PF, 0);
-   rte_atomic32_inc(>dp_count);
+   __insn_fetchadd4(>dp_count, 1);
 }

 static inline void
 mpipe_dp_exit(struct mpipe_dev_priv *priv)
 {
-   rte_atomic32_dec(>dp_count);
+   __insn_fetchadd4(>dp_count, -1);
 }

 static inline void
@@ -484,12 +484,20 @@ mpipe_recv_mbuf(struct mpipe_dev_priv *priv, 
gxio_mpipe_idesc_t *idesc,
uint16_t size = gxio_mpipe_idesc_get_xfer_size(idesc);
struct rte_mbuf *mbuf = RTE_PTR_SUB(va, priv->rx_offset);

-   rte_pktmbuf_reset(mbuf);
mbuf->data_off = (uintptr_t)va - (uintptr_t)mbuf->buf_addr;
-   mbuf->port = in_port;
-   mbuf->data_len = size;
+   mbuf->nb_segs = 1;
+   mbuf->port = in_port;
+   mbuf->ol_flags = 0;
+   if (gxio_mpipe_idesc_get_ethertype(idesc) == ETHER_TYPE_IPv4)
+   mbuf->packet_type = RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L2_ETHER;
+   else if (gxio_mpipe_idesc_get_ethertype(idesc) == ETHER_TYPE_IPv6)
+   mbuf->packet_type = RTE_PTYPE_L3_IPV6 | RTE_PTYPE_L2_ETHER;
+   else
+   mbuf->packet_type = RTE_PTYPE_UNKNOWN;
mbuf->pkt_len  = size;
+   mbuf->data_len = size;
mbuf->hash.rss = gxio_mpipe_idesc_get_flow_hash(idesc);
+   mbuf->next = NULL;

PMD_DEBUG_RX("%s: RX mbuf %p, buffer %p, buf_addr %p, size %d\n",
 mpipe_name(priv), mbuf, va, mbuf->buf_addr, size);
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 1/2] eal/tile: add rte_vect.h and enable CONFIG_RTE_LIBRTE_LPM

[Liming Sun]

rte_vect.h was missing earlier thus LPM was disabled and l3fwd is
not able to compile. This commit implements the vector api and
enable LPM in the tilegx configuration by default.

Signed-off-by: Liming Sun 
Acked-by: Zhigang Lu 
---
 config/defconfig_tile-tilegx-linuxapp-gcc  |  2 +-
 lib/librte_eal/common/include/arch/tile/rte_vect.h | 93 ++
 2 files changed, 94 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_eal/common/include/arch/tile/rte_vect.h

diff --git a/config/defconfig_tile-tilegx-linuxapp-gcc 
b/config/defconfig_tile-tilegx-linuxapp-gcc
index fb61bcd..39794f6 100644
--- a/config/defconfig_tile-tilegx-linuxapp-gcc
+++ b/config/defconfig_tile-tilegx-linuxapp-gcc
@@ -64,7 +64,7 @@ CONFIG_RTE_LIBRTE_ENIC_PMD=n

 # This following libraries are not available on the tile architecture.
 # So they're turned off.
-CONFIG_RTE_LIBRTE_LPM=n
+CONFIG_RTE_LIBRTE_LPM=y
 CONFIG_RTE_LIBRTE_ACL=n
 CONFIG_RTE_LIBRTE_SCHED=n
 CONFIG_RTE_LIBRTE_PORT=n
diff --git a/lib/librte_eal/common/include/arch/tile/rte_vect.h 
b/lib/librte_eal/common/include/arch/tile/rte_vect.h
new file mode 100644
index 000..9afee70
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/tile/rte_vect.h
@@ -0,0 +1,93 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) EZchip Semiconductor Ltd. 2016.
+ *
+ *   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 EZchip Semiconductor 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.
+*/
+
+#ifndef _RTE_VECT_H_
+#define _RTE_VECT_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef __int128 __m128i;
+
+#defineXMM_SIZEsizeof(__m128i)
+#defineXMM_MASK(XMM_SIZE - 1)
+
+typedef union rte_xmm {
+   __m128i x;
+   uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
+   uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
+} rte_xmm_t;
+
+/* Extracts the low order 64-bit integer. */
+#define _mm_cvtsi128_si64(a) ((rte_xmm_t*))->u64[0]
+
+/* Sets the 2 signed 64-bit integer values. */
+#define _mm_set_epi64x(i1, i0) ({ \
+   rte_xmm_t m;  \
+   m.u64[0] = i0;\
+   m.u64[1] = i1;\
+   (m.x);\
+})
+
+/* Sets the 4 signed 32-bit integer values. */
+#define _mm_set_epi32(i3, i2, i1, i0)  ({ \
+   rte_xmm_t m;  \
+   m.u32[0] = i0;\
+   m.u32[1] = i1;\
+   m.u32[2] = i2;\
+   m.u32[3] = i3;\
+   (m.x);\
+})
+
+/* Shifts right the 4 32-bit integers by count bits with zeros. */
+#define _mm_srli_epi32(v, cnt) ({  \
+   rte_xmm_t m; \
+   m.u64[0] = __insn_v4shru(((rte_xmm_t*)&(v))->u64[0], cnt); \
+   m.u64[1] = __insn_v4shru(((rte_xmm_t*)&(v))->u64[1], cnt); \
+   (m.x);   \
+})
+
+/* Shifts the 128-bit value in a right by imm bytes. */
+#define _mm_srli_si128(v, imm) ((v) >> (imm * sizeof(uint8_t)))
+
+/* Bitwise AND of the 128-bit value in a and the 128-bit value in b. */
+#define _mm_and_si128(a, b) ((a) & (b))
+
+/* Loads 128-bit value. */
+#define _mm_loadu_si128(p) (*(p))
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_VECT_H_ */
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 1/3] driver/net/mpipe: support native build on tilegx platform.

[Thomas Monjalon]

2016-02-09 18:37, Liming Sun:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] 
> A comment about the TILE-Mx would be welcome.
> Is it supported currently?
> Isn't it an ARM arch?
> 
> [lsun] Yes, it's ARM arch, but with similar mpipe driver.
> It's not fully supported yet. I'll remove this change and add it in a 
> different serie when it's ready.

OK
So we'll discuss how to integrate it later.

> > +# Compile combined lib by default.
> > +CONFIG_RTE_BUILD_COMBINE_LIBS=y
> 
> Why forcing this option in the defconfig file?
> 
> [lsun] It's just trying to make it handy for other applications like OVS or 
> ODP on top of DPDK. However we could remove this change if it's not the 
> recommended way.

Yes please remove it.

> >  ARCH  ?= tile
> > +
> > +HOST_ARCH := ${shell uname -m}
> > +ifneq ($(filter tile%,${HOST_ARCH}),) CROSS = else
> >  CROSS ?= tile-
> > +endif
> 
> I don't think the CROSS variable should have a default value.
> It really depends on the toolchain.
> 
> [lsun] Make sense. The current code (before the change) has default value 
> 'CROSS ?= tile-' defined, which cause some issue when doing native build. 
> Another way is to define it as "CROSS ?=" just like other platforms. So when 
> doing cross-compile, we could pass " CROSS=tile-" .

No need to keep a "CROSS ?=" line.
The variables defined in the command line get the priority.


> Talking about the toolchain, is it possible to build DPDK with the provided 
> binary toolchain http://www.tilera.com/scm/tilegx-x86_64.tar.bz2 ?
> This is the Tilera Open Source page: http://www.tilera.com/scm/
> 
> [lsun] I tried it just now. The gcc appears ok. But this tarball lacks of 
> some header files and libraries to compile DPDK.

Yes that's what I've experienced.

> We're looking into it to see whether it can be easily fixed.

Please keep us informed when the toolchain is ready. Thanks

[dpdk-dev] [PATCH v2 1/3] driver/net/mpipe: support native build on tilegx platform.

[Liming Sun]

Looks like this patch serie has been merged into dpdk-next-net/rel_16_04.
What would be the usual way to submit changes for new comments? Would it be 
incremental changes (new commit) based on previous one? Thanks.

From: Thomas Monjalon 
Sent: Tuesday, February 9, 2016 3:33 PM
To: Liming Sun
Cc: dev at dpdk.org; bruce.richardson at intel.com
Subject: Re: [dpdk-dev] [PATCH v2 1/3] driver/net/mpipe: support native build 
on tilegx platform.

2016-02-09 18:37, Liming Sun:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> A comment about the TILE-Mx would be welcome.
> Is it supported currently?
> Isn't it an ARM arch?
>
> [lsun] Yes, it's ARM arch, but with similar mpipe driver.
> It's not fully supported yet. I'll remove this change and add it in a 
> different serie when it's ready.

OK
So we'll discuss how to integrate it later.

> > +# Compile combined lib by default.
> > +CONFIG_RTE_BUILD_COMBINE_LIBS=y
>
> Why forcing this option in the defconfig file?
>
> [lsun] It's just trying to make it handy for other applications like OVS or 
> ODP on top of DPDK. However we could remove this change if it's not the 
> recommended way.

Yes please remove it.

> >  ARCH  ?= tile
> > +
> > +HOST_ARCH := ${shell uname -m}
> > +ifneq ($(filter tile%,${HOST_ARCH}),) CROSS = else
> >  CROSS ?= tile-
> > +endif
>
> I don't think the CROSS variable should have a default value.
> It really depends on the toolchain.
>
> [lsun] Make sense. The current code (before the change) has default value 
> 'CROSS ?= tile-' defined, which cause some issue when doing native build. 
> Another way is to define it as "CROSS ?=" just like other platforms. So when 
> doing cross-compile, we could pass " CROSS=tile-" .

No need to keep a "CROSS ?=" line.
The variables defined in the command line get the priority.


> Talking about the toolchain, is it possible to build DPDK with the provided 
> binary toolchain http://www.tilera.com/scm/tilegx-x86_64.tar.bz2 ?
> This is the Tilera Open Source page: http://www.tilera.com/scm/
>
> [lsun] I tried it just now. The gcc appears ok. But this tarball lacks of 
> some header files and libraries to compile DPDK.

Yes that's what I've experienced.

> We're looking into it to see whether it can be easily fixed.

Please keep us informed when the toolchain is ready. Thanks

[dpdk-dev] i40e: cannot change mtu to enable jumbo frame

[Zhu, Heqing]

Helin is still in Chinese New Year Vacation. Will the below command option help 
? 

4.5.9. port config - max-pkt-len
Set the maximum packet length:

testpmd> port config all max-pkt-len (value)
This is equivalent to the --max-pkt-len command-line option.


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Julien Meunier
Sent: Tuesday, February 9, 2016 9:36 AM
To: Zhang, Helin ; dev at dpdk.org
Subject: [dpdk-dev] i40e: cannot change mtu to enable jumbo frame

Hello Helin,

I tried to send jumbo frames to a i40e card. However, I observed that all 
frames are dropped. Moreover, set_mtu function is not implemented on i40e PMD.

 > testpmd --log-level 8 --huge-dir=/mnt/huge -n 4 -l 2,18 --socket-mem
1024,1024 -w :02:00.0 -w :02:00.2 -- -i --nb-cores=1
--nb-ports=2 --total-num-mbufs=65536

=
Configuration
=

+---+  +-+
|   |  | |
| tgen  |  | |
|   +--+ port 0  |
|   |  | |
|   |  | |
|   |  | |
|   |  | |
|   +--+ port 1  |
|   |  | |
+---+  +-+

DPDK: DPDK-v2.2

==
MTU = 1500
==
Packet sent from a tgen
 > p = Ether / IP / UDP / Raw(MTU + HDR(Ethernet)- HDR(IP) - HDR(UDP))  > 
 > len(p) = 1514

testpmd> start
PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 0, vlan_tci_outer: 0
testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...
PMD: i40e_update_vsi_stats(): *** VSI[13] stats start ***
PMD: i40e_update_vsi_stats(): rx_bytes:1518
PMD: i40e_update_vsi_stats(): rx_unicast:  1
PMD: i40e_update_vsi_stats(): *** VSI[13] stats end ***
PMD: i40e_dev_stats_get(): *** PF stats start ***
PMD: i40e_dev_stats_get(): rx_bytes:1514
PMD: i40e_dev_stats_get(): rx_unicast:  1
PMD: i40e_dev_stats_get(): rx_unknown_protocol: 1
PMD: i40e_dev_stats_get(): rx_size_1522: 1
PMD: i40e_dev_stats_get(): *** PF stats end ***

   -- Forward statistics for port 0  --
   RX-packets: 1  RX-dropped: 0 RX-total: 1
   TX-packets: 0  TX-dropped: 0 TX-total: 0


PMD: i40e_update_vsi_stats(): *** VSI[14] stats start ***
PMD: i40e_update_vsi_stats(): tx_bytes:1514
PMD: i40e_update_vsi_stats(): tx_unicast:  1
PMD: i40e_update_vsi_stats(): *** VSI[14] stats end ***
PMD: i40e_dev_stats_get(): *** PF stats start ***
PMD: i40e_dev_stats_get(): tx_bytes:1514
PMD: i40e_dev_stats_get(): tx_unicast:  1
PMD: i40e_dev_stats_get(): tx_size_1522: 1
PMD: i40e_dev_stats_get(): *** PF stats end ***

   -- Forward statistics for port 1 --
   RX-packets: 0  RX-dropped: 0 RX-total: 0
   TX-packets: 1  TX-dropped: 0 TX-total: 1



   + Accumulated forward statistics for all ports+
   RX-packets: 1  RX-dropped: 0 RX-total: 1
   TX-packets: 1  TX-dropped: 0 TX-total: 1



=> OK

==
MTU = 1600
==
Packet sent
 > p = Ether / IP / UDP / Raw(MTU + HDR(Ethernet)- HDR(IP) - HDR(UDP))  > 
 > len(p) = 1614

testpmd> port config mtu 0 1600
rte_eth_dev_set_mtu: Function not supported Set MTU failed. diag=-95
testpmd> port config mtu 1 1600
rte_eth_dev_set_mtu: Function not supported Set MTU failed. diag=-95
testpmd> start
testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...
PMD: i40e_update_vsi_stats(): *** VSI[13] stats start ***
PMD: i40e_update_vsi_stats(): rx_bytes:1618
PMD: i40e_update_vsi_stats(): rx_unicast:  1
PMD: i40e_update_vsi_stats(): *** VSI[13] stats end ***
PMD: i40e_dev_stats_get(): *** PF stats start ***
PMD: i40e_dev_stats_get(): rx_bytes:1614
PMD: i40e_dev_stats_get(): rx_unicast:  1
PMD: i40e_dev_stats_get(): rx_unknown_protocol: 1
PMD: i40e_dev_stats_get(): rx_size_big:  1
PMD: i40e_dev_stats_get(): *** PF stats end ***

   -- Forward statistics for port 0  --
   RX-packets: 1  RX-dropped: 0 RX-total: 1
   TX-packets: 0  TX-dropped: 0 TX-total: 0


PMD: i40e_update_vsi_stats(): *** VSI[14] stats start ***
PMD: i40e_update_vsi_stats(): tx_bytes:0
PMD: i40e_update_vsi_stats(): tx_unicast:  0
PMD: i40e_update_vsi_stats(): *** VSI[14] stats end ***
PMD: i40e_dev_stats_get(): *** PF stats start ***
PMD: 

[dpdk-dev] [PATCH v2 1/2] driver/net/mpipe: add rte_vect.h and enable CONFIG_RTE_LIBRTE_LPM

[Liming Sun]

Make sense. I'll split them into different patches.

Thanks!
Liming

-Original Message-
From: Bruce Richardson [mailto:bruce.richard...@intel.com] 
Sent: Tuesday, February 09, 2016 10:56 AM
To: Liming Sun
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 1/2] driver/net/mpipe: add rte_vect.h and 
enable CONFIG_RTE_LIBRTE_LPM

On Fri, Jan 08, 2016 at 09:39:07AM -0500, Liming Sun wrote:
> rte_vect.h was missing earlier thus LPM was disabled and l3fwd is not 
> able to compile. This commit implements the vector api and enable LPM 
> in the tilegx configuration by default. It also includes a minor 
> optimization to use __insn_fetchadd4() instead of
> rte_atomic32_xxx() in mpipe_dp_enter/mpipe_dp_exit to avoid the 
> unnecessary memory fence.

This looks like it should be two patches to me. One patch to add the missing 
dependency and get lpm to work. The second patch should then contain the driver 
optimization. Do you agree?

/Bruce

PS: the commit title prefix for the first patch should probably be "eal/tile"
rather than mpipe, since it's not directly affecting the mpipe driver.

> 
> Signed-off-by: Liming Sun 
> Acked-by: Zhigang Lu 
> ---
>  config/defconfig_tile-tilegx-linuxapp-gcc  |  2 +-
>  drivers/net/mpipe/mpipe_tilegx.c   | 18 +++--
>  lib/librte_eal/common/include/arch/tile/rte_vect.h | 93 
> ++
>  3 files changed, 107 insertions(+), 6 deletions(-)  create mode 
> 100644 lib/librte_eal/common/include/arch/tile/rte_vect.h
> 
[snip]
>+  mbuf->next = NULL;
>  
>   PMD_DEBUG_RX("%s: RX mbuf %p, buffer %p, buf_addr %p, size %d\n",
>mpipe_name(priv), mbuf, va, mbuf->buf_addr, size); diff 
> --git 
> a/lib/librte_eal/common/include/arch/tile/rte_vect.h 
> b/lib/librte_eal/common/include/arch/tile/rte_vect.h
> new file mode 100644
> index 000..32d768a
> --- /dev/null
> +++ b/lib/librte_eal/common/include/arch/tile/rte_vect.h
> @@ -0,0 +1,93 @@
> +/*
> + *   BSD LICENSE
> + *
> + *   Copyright (C) EZchip Semiconductor Ltd. 2015.

Maybe update the copyright year?

> + *
> + *   Redistribution and use in source and binary forms, with or without
> + *   modification, are permitted provided that the following conditions
[snip]

[dpdk-dev] [PATCH v9 2/2] vhost: Add VHOST PMD

[Tetsuya Mukawa]

The patch introduces a new PMD. This PMD is implemented as thin wrapper
of librte_vhost. It means librte_vhost is also needed to compile the PMD.
The vhost messages will be handled only when a port is started. So start
a port first, then invoke QEMU.

The PMD has 2 parameters.
 - iface:  The parameter is used to specify a path to connect to a
   virtio-net device.
 - queues: The parameter is used to specify the number of the queues
   virtio-net device has.
   (Default: 1)

Here is an example.
$ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i

To connect above testpmd, here is qemu command example.

$ qemu-system-x86_64 \

-chardev socket,id=chr0,path=/tmp/sock0 \
-netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
-device virtio-net-pci,netdev=net0,mq=on

Signed-off-by: Tetsuya Mukawa 
Acked-by: Ferruh Yigit 
---
 MAINTAINERS |   4 +
 config/common_linuxapp  |   6 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/rel_notes/release_2_3.rst|   4 +
 drivers/net/Makefile|   4 +
 drivers/net/vhost/Makefile  |  62 ++
 drivers/net/vhost/rte_eth_vhost.c   | 911 
 drivers/net/vhost/rte_eth_vhost.h   | 109 
 drivers/net/vhost/rte_pmd_vhost_version.map |  11 +
 mk/rte.app.mk   |   6 +
 10 files changed, 1118 insertions(+)
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index b90aeea..a44ce9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -348,6 +348,10 @@ Null PMD
 M: Tetsuya Mukawa 
 F: drivers/net/null/

+Vhost PMD
+M: Tetsuya Mukawa 
+F: drivers/net/vhost/
+
 Intel AES-NI Multi-Buffer
 M: Declan Doherty 
 F: drivers/crypto/aesni_mb/
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 74bc515..357b557 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -514,6 +514,12 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 CONFIG_RTE_LIBRTE_VHOST_DEBUG=n

 #
+# Compile vhost PMD
+# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
+#
+CONFIG_RTE_LIBRTE_PMD_VHOST=y
+
+#
 #Compile Xen domain0 support
 #
 CONFIG_RTE_LIBRTE_XEN_DOM0=n
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 33c9cea..5819cdb 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -47,6 +47,7 @@ Network Interface Controller Drivers
 nfp
 szedata2
 virtio
+vhost
 vmxnet3
 pcap_ring

diff --git a/doc/guides/rel_notes/release_2_3.rst 
b/doc/guides/rel_notes/release_2_3.rst
index 7945694..d43b7ad 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ This section should contain new features added in this 
release. Sample format:

   Enabled virtio 1.0 support for virtio pmd driver.

+* **Added vhost PMD.**
+
+  Added virtual PMD that wraps librte_vhost.
+

 Resolved Issues
 ---
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6e4497e..4300b93 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -52,5 +52,9 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
 DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt

+ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += vhost
+endif # $(CONFIG_RTE_LIBRTE_VHOST)
+
 include $(RTE_SDK)/mk/rte.sharelib.mk
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/net/vhost/Makefile b/drivers/net/vhost/Makefile
new file mode 100644
index 000..f49a69b
--- /dev/null
+++ b/drivers/net/vhost/Makefile
@@ -0,0 +1,62 @@
+#   BSD LICENSE
+#
+#   Copyright (c) 2010-2016 Intel Corporation.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of 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 

[dpdk-dev] [PATCH v9 1/2] ethdev: Add a new event type to notify a queue state changed event

[Tetsuya Mukawa]

This patch adds a below event type.
 - RTE_ETH_EVENT_QUEUE_STATE_CHANGE
This event is used for notifying a queue state changed event.

Signed-off-by: Tetsuya Mukawa 
Acked-by: Ferruh Yigit 
---
 lib/librte_ether/rte_ethdev.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8710dd7..2fbf42a 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2661,6 +2661,8 @@ rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
 enum rte_eth_event_type {
RTE_ETH_EVENT_UNKNOWN,  /**< unknown event type */
RTE_ETH_EVENT_INTR_LSC, /**< lsc interrupt event */
+   RTE_ETH_EVENT_QUEUE_STATE_CHANGE,
+   /**< queue state changed interrupt */
RTE_ETH_EVENT_MAX   /**< max value of this enum */
 };

-- 
2.1.4

[dpdk-dev] [PATCH v9 0/2] Add VHOST PMD

[Tetsuya Mukawa]

The patch introduces a new PMD. This PMD is implemented as thin wrapper
of librte_vhost.


PATCH v9 changes:
 - Fix a null pointer access issue implemented in v8 patch.

PATCH v8 changes:
 - Manage ether devices list instead of internal structures list.
 - Remove needless NULL checking.
 - Replace "pthread_exit" to "return NULL".
 - Replace rte_panic to RTE_LOG, also add error handling.
 - Remove duplicated lines.
 - Remove needless casting.
 - Follow coding style.
 - Remove needless parenthesis.

PATCH v7 changes:
 - Remove needless parenthesis.
 - Add release note.
 - Remove needless line wraps.
 - Add null pointer check in vring_state_changed().
 - Free queue memory in eth_queue_release().
 - Fix wrong variable name.
 - Fix error handling code of eth_dev_vhost_create() and
   rte_pmd_vhost_devuninit().
 - Remove needless null checking from rte_pmd_vhost_devinit/devuninit().
 - Use port id to create mac address.
 - Add doxygen style comments in "rte_eth_vhost.h".
 - Fix wrong comment in "mk/rte.app.mk".

PATCH v6 changes:
 - Remove rte_vhost_driver_pmd_callback_registe().
 - Support link status interrupt.
 - Support queue state changed interrupt.
 - Add rte_eth_vhost_get_queue_event().
 - Support numa node detection when new device is connected.

PATCH v5 changes:
 - Rebase on latest master.
 - Fix RX/TX routine to count RX/TX bytes.
 - Fix RX/TX routine not to count as error packets if enqueue/dequeue
   cannot send all packets.
 - Fix if-condition checking for multiqueues.
 - Add "static" to pthread variable.
 - Fix format.
 - Change default behavior not to receive queueing event from driver.
 - Split the patch to separate rte_eth_vhost_portid2vdev().

PATCH v4 changes:
 - Rebase on latest DPDK tree.
 - Fix cording style.
 - Fix code not to invoke multiple messaging handling threads.
 - Fix code to handle vdev parameters correctly.
 - Remove needless cast.
 - Remove needless if-condition before rt_free().

PATCH v3 changes:
 - Rebase on latest matser
 - Specify correct queue_id in RX/TX function.

PATCH v2 changes:
 - Remove a below patch that fixes vhost library.
   The patch was applied as a separate patch.
   - vhost: fix crash with multiqueue enabled
 - Fix typos.
   (Thanks to Thomas, Monjalon)
 - Rebase on latest tree with above bernard's patches.

PATCH v1 changes:
 - Support vhost multiple queues.
 - Rebase on "remove pci driver from vdevs".
 - Optimize RX/TX functions.
 - Fix resource leaks.
 - Fix compile issue.
 - Add patch to fix vhost library.

RFC PATCH v3 changes:
 - Optimize performance.
   In RX/TX functions, change code to access only per core data.
 - Add below API to allow user to use vhost library APIs for a port managed
   by vhost PMD. There are a few limitations. See "rte_eth_vhost.h".
- rte_eth_vhost_portid2vdev()
   To support this functionality, vhost library is also changed.
   Anyway, if users doesn't use vhost PMD, can fully use vhost library APIs.
 - Add code to support vhost multiple queues.
   Actually, multiple queues functionality is not enabled so far.

RFC PATCH v2 changes:
 - Fix issues reported by checkpatch.pl
   (Thanks to Stephen Hemminger)


Tetsuya Mukawa (2):
  ethdev: Add a new event type to notify a queue state changed event
  vhost: Add VHOST PMD

 MAINTAINERS |   4 +
 config/common_linuxapp  |   6 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/rel_notes/release_2_3.rst|   4 +
 drivers/net/Makefile|   4 +
 drivers/net/vhost/Makefile  |  62 ++
 drivers/net/vhost/rte_eth_vhost.c   | 911 
 drivers/net/vhost/rte_eth_vhost.h   | 109 
 drivers/net/vhost/rte_pmd_vhost_version.map |  11 +
 lib/librte_ether/rte_ethdev.h   |   2 +
 mk/rte.app.mk   |   6 +
 11 files changed, 1120 insertions(+)
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

-- 
2.1.4

[dpdk-dev] [PATCH v2 1/3] driver/net/mpipe: support native build on tilegx platform.

[Liming Sun]

Thanks Thomas for the comments.
Please see the response inline.

Thanks,
Liming

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Tuesday, February 09, 2016 11:16 AM
To: Liming Sun
Cc: dev at dpdk.org; bruce.richardson at intel.com
Subject: Re: [dpdk-dev] [PATCH v2 1/3] driver/net/mpipe: support native build 
on tilegx platform.

Hi,

Sorry for being late for commenting.

2016-01-08 09:30, Liming Sun:
> -EZchip TILE-Gx
> +EZchip TILE-Gx/Mx

A comment about the TILE-Mx would be welcome.
Is it supported currently?
Isn't it an ARM arch?

[lsun] Yes, it's ARM arch, but with similar mpipe driver.
It's not fully supported yet. I'll remove this change and add it in a different 
serie when it's ready.

>  M: Zhigang Lu 
> +M: Liming Sun 
>  F: lib/librte_eal/common/include/arch/tile/
>  F: drivers/net/mpipe/

[...]
> +# Compile combined lib by default.
> +CONFIG_RTE_BUILD_COMBINE_LIBS=y

Why forcing this option in the defconfig file?

[lsun] It's just trying to make it handy for other applications like OVS or ODP 
on top of DPDK. However we could remove this change if it's not the recommended 
way.

[...]
>  ARCH  ?= tile
> +
> +HOST_ARCH := ${shell uname -m}
> +ifneq ($(filter tile%,${HOST_ARCH}),) CROSS = else
>  CROSS ?= tile-
> +endif

I don't think the CROSS variable should have a default value.
It really depends on the toolchain.

[lsun] Make sense. The current code (before the change) has default value 
'CROSS ?= tile-' defined, which cause some issue when doing native build. 
Another way is to define it as "CROSS ?=" just like other platforms. So when 
doing cross-compile, we could pass " CROSS=tile-" .

Talking about the toolchain, is it possible to build DPDK with the provided 
binary toolchain http://www.tilera.com/scm/tilegx-x86_64.tar.bz2 ?
This is the Tilera Open Source page: http://www.tilera.com/scm/

[lsun] I tried it just now. The gcc appears ok. But this tarball lacks of some 
header files and libraries to compile DPDK.
We're looking into it to see whether it can be easily fixed.

[dpdk-dev] [PATCH 5/9] eal: get rid of pmd type

[Jan Viktorin]

On Fri, 29 Jan 2016 15:08:32 +0100
David Marchand  wrote:

> Now that we only have vdev drivers, there is no need for a pmd type in
> rte_driver.
> rte_driver is now purely a vdev thing, and could be renamed later
> (then .init would become .probe, .uninit would become .remove).
> 
> Signed-off-by: David Marchand 
> ---
>  drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c |  2 ++
>  drivers/net/af_packet/rte_eth_af_packet.c  |  2 ++
>  drivers/net/bonding/rte_eth_bond_pmd.c |  2 ++
>  drivers/net/mpipe/mpipe_tilegx.c   |  4 
>  drivers/net/null/rte_eth_null.c|  2 ++
>  drivers/net/pcap/rte_eth_pcap.c|  2 ++
>  drivers/net/ring/rte_eth_ring.c|  2 ++
>  drivers/net/szedata2/rte_eth_szedata2.c|  2 ++
>  drivers/net/xenvirt/rte_eth_xenvirt.c  |  2 ++
>  lib/librte_cryptodev/rte_cryptodev.c   | 14 ++
>  lib/librte_cryptodev/rte_cryptodev.h   |  2 ++
>  lib/librte_cryptodev/rte_cryptodev_pmd.h   |  4 
>  lib/librte_eal/common/eal_common_dev.c | 11 ---
>  lib/librte_eal/common/include/rte_dev.h|  4 
>  14 files changed, 52 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
> b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> index d8ccf05..94752de 100644
> --- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> +++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> @@ -661,7 +661,9 @@ cryptodev_aesni_mb_uninit(const char *name)
>  
>  static struct rte_driver cryptodev_aesni_mb_pmd_drv = {
>   .name = CRYPTODEV_NAME_AESNI_MB_PMD,
> +#ifndef RTE_NEXT_ABI
>   .type = PMD_VDEV,
> +#endif

What about something like:

#ifdef RTE_NEXT_ABI
#define RTE_PMD_SET_TYPE(t)
#else
#define RTE_PMD_SET_TYPE(t) .type = PMD_##t
#endif

and then just:

static struct rte_driver cryptodev_aesni_mb_pmd_drv = {
.name = CRYPTODEV_NAME_AESNI_MB_PMD,
RTE_PMD_SET_TYPE(VDEV),

>   .init = cryptodev_aesni_mb_init,
>   .uninit = cryptodev_aesni_mb_uninit
>  };
> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
> b/drivers/net/af_packet/rte_eth_af_packet.c
> index 767f36b..6603462 100644
> --- a/drivers/net/af_packet/rte_eth_af_packet.c
> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
> @@ -838,7 +838,9 @@ exit:
> [snip]
>
>  struct rte_cryptodev *
> +#ifndef RTE_NEXT_ABI

And maybe...

#ifndef RTE_NEXT_ABI
#define RTE_PMD_HAS_TYPE
#endif

#ifdef RTE_PMD_HAS_TYPE

>  rte_cryptodev_pmd_allocate(const char *name, enum pmd_type type, int 
> socket_id)
> +#else
> +rte_cryptodev_pmd_allocate(const char *name, int socket_id)
> +#endif
>  {
>   struct rte_cryptodev *cryptodev;
>   uint8_t dev_id;
> [snip]

Regards
Jan

[dpdk-dev] [PATCH 3/9] drivers: no more pdev drivers

[Jan Viktorin]

Maybe, a better subject?

drivers: init pdev drivers in constructors

On Fri, 29 Jan 2016 15:08:30 +0100
David Marchand  wrote:

> Now that pdev drivers have been converted to pci drivers, there is nothing
> left in their init functions that can't go in a constructor.
> pdev / vdev drivers init order is changed by this commit, but I can't see
> why we would need to preserve it.
> 
> Signed-off-by: David Marchand 
> ---
>  drivers/crypto/qat/rte_qat_cryptodev.c | 13 +++-
>  drivers/net/bnx2x/bnx2x_ethdev.c   | 26 +++-
>  drivers/net/cxgbe/cxgbe_ethdev.c   | 19 +++---
>  drivers/net/e1000/em_ethdev.c  | 13 +++-
>  drivers/net/e1000/igb_ethdev.c | 34 
>  drivers/net/enic/enic_ethdev.c | 18 +++--
>  drivers/net/fm10k/fm10k_ethdev.c   | 19 +++---
>  drivers/net/i40e/i40e_ethdev.c | 19 +++---
>  drivers/net/i40e/i40e_ethdev_vf.c  | 19 +++---
>  drivers/net/ixgbe/ixgbe_ethdev.c   | 36 
> +++---
>  drivers/net/mlx4/mlx4.c| 19 +++---
>  drivers/net/mlx5/mlx5.c| 19 +++---
>  drivers/net/nfp/nfp_net.c  | 14 +++--
>  drivers/net/virtio/virtio_ethdev.c | 22 -
>  drivers/net/vmxnet3/vmxnet3_ethdev.c   | 18 +++--
>  15 files changed, 47 insertions(+), 261 deletions(-)
> 
> diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c 
> b/drivers/crypto/qat/rte_qat_cryptodev.c
> index 6853aee..ded5d60 100644
> --- a/drivers/crypto/qat/rte_qat_cryptodev.c
> +++ b/drivers/crypto/qat/rte_qat_cryptodev.c
> @@ -124,17 +124,10 @@ static struct rte_cryptodev_driver rte_qat_pmd = {
>   .dev_private_size = sizeof(struct qat_pmd_private),
>  };
>  
> -static int
> -rte_qat_pmd_init(const char *name __rte_unused, const char *params 
> __rte_unused)
> +/* Driver registration */
> +static void __attribute__((constructor, used))
> +rte_qat_pmd_init(void)
>  {
>   PMD_INIT_FUNC_TRACE();
>   rte_eal_pci_register(_qat_pmd.pci_drv);
> - return 0;
>  }
> -
> -static struct rte_driver pmd_qat_drv = {
> - .type = PMD_PDEV,
> - .init = rte_qat_pmd_init,
> -};
> -
> -PMD_REGISTER_DRIVER(pmd_qat_drv);

What about introducing a macro for this?

RTE_REGISTER_PCI_DRIVER(rte_qad_pmd);

Regards
Jan

[dpdk-dev] [PATCH 2/2] kdp: add virtual PMD for kernel slow data path communication

[Ferruh Yigit]

On Tue, Feb 09, 2016 at 05:33:55PM +, Reshma Pattan wrote:
> Hi Ferruh,
>
Hi Reshma,

> On 1/27/2016 4:32 PM, Ferruh Yigit wrote:
>> This patch provides slow data path communication to the Linux kernel.
>> Patch is based on librte_kni, and heavily re-uses it.
>>
>> The main difference is librte_kni library converted into a PMD, to
>> provide ease of use for applications.
>>
>> Now any application can use slow path communication without any update
>> in application, because of existing eal support for virtual PMD.
>>
>> Also this PMD supports two methods to send packets to the Linux, first
>> one is custom FIFO implementation with help of KDP kernel module, second
>> one is Linux in-kernel tun/tap support. PMD first checks for KDP kernel
>> module, if fails it tries to create and use a tap interface.
>>
>> With FIFO method: PMD's rx_pkt_burst() get packets from FIFO,
>> and tx_pkt_burst() puts packet to the FIFO.
>> The corresponding Linux virtual network device driver code
>> also gets/puts packets from FIFO as they are coming from hardware.
>>
>> With tun/tap method: no external kernel module required, PMD reads from
>> and writes packets to the tap interface file descriptor. Tap interface
>> has performance penalty against FIFO implementation.
>>
>> Signed-off-by: Ferruh Yigit 
>> ---
>>   diff --git a/doc/guides/nics/pcap_ring.rst 
>> b/doc/guides/nics/pcap_ring.rst
>> index 46aa3ac..78b7b61 100644
>> --- a/doc/guides/nics/pcap_ring.rst
>> +++ b/doc/guides/nics/pcap_ring.rst
>> @@ -28,11 +28,11 @@
>> +
>> +
>> +DPDK application can be used to forward packages between these interfaces:
>> +
>
> Packages ==> packets.?
>
Right, I will fix, thanks.

>> diff --git a/drivers/net/kdp/rte_eth_kdp.c b/drivers/net/kdp/rte_eth_kdp.c
>> new file mode 100644
>> index 000..ac650d7
>> --- /dev/null
>> +++ b/drivers/net/kdp/rte_eth_kdp.c
>> @@ -0,0 +1,481 @@
>>
>
> No public API to create KDP PMD device. We should have one right?
>
Doesn't have to have one, KDP does not have a requirement to have right now.
It is possible to create PMD with eal --vdev parameter...

>> diff --git a/drivers/net/kdp/rte_kdp.h b/drivers/net/kdp/rte_kdp.h
>> new file mode 100644
>> index 000..b9db048
>> --- /dev/null
>> +++ b/drivers/net/kdp/rte_kdp.h
>> @@ -0,0 +1,126 @@
>>
>> +struct rte_kdp_tap *rte_kdp_tap_init(uint16_t port_id);
>> +struct rte_kdp *rte_kdp_init(uint16_t port_id);
>> +
>> +int rte_kdp_start(struct rte_kdp *kdp, struct rte_mempool *pktmbuf_pool,
>> +  const struct rte_kdp_conf *conf);
>> +
>> +unsigned rte_kdp_rx_burst(struct rte_kdp *kdp,
>> +struct rte_mbuf **mbufs, unsigned num);
>> +
>> +unsigned rte_kdp_tx_burst(struct rte_kdp *kdp,
>> +struct rte_mbuf **mbufs, unsigned num);
>> +
>> +int rte_kdp_release(struct rte_kdp *kdp);
>> +
>> +void rte_kdp_close(void);
>>
>
> These functions can be static.
>
No, this header used by multiple sources, the function declarations here are 
the ones in the scope of other file.

Thanks,
ferruh

[dpdk-dev] i40e: cannot change mtu to enable jumbo frame

[Julien Meunier]

Hello Helin,

I tried to send jumbo frames to a i40e card. However, I observed that 
all frames are dropped. Moreover, set_mtu function is not implemented on 
i40e PMD.

 > testpmd --log-level 8 --huge-dir=/mnt/huge -n 4 -l 2,18 --socket-mem 
1024,1024 -w :02:00.0 -w :02:00.2 -- -i --nb-cores=1 
--nb-ports=2 --total-num-mbufs=65536

=
Configuration
=

+---+  +-+
|   |  | |
| tgen  |  | |
|   +--+ port 0  |
|   |  | |
|   |  | |
|   |  | |
|   |  | |
|   +--+ port 1  |
|   |  | |
+---+  +-+

DPDK: DPDK-v2.2

==
MTU = 1500
==
Packet sent from a tgen
 > p = Ether / IP / UDP / Raw(MTU + HDR(Ethernet)- HDR(IP) - HDR(UDP))
 > len(p) = 1514

testpmd> start
PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 0, vlan_tci_outer: 0
testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...
PMD: i40e_update_vsi_stats(): *** VSI[13] stats start ***
PMD: i40e_update_vsi_stats(): rx_bytes:1518
PMD: i40e_update_vsi_stats(): rx_unicast:  1
PMD: i40e_update_vsi_stats(): *** VSI[13] stats end ***
PMD: i40e_dev_stats_get(): *** PF stats start ***
PMD: i40e_dev_stats_get(): rx_bytes:1514
PMD: i40e_dev_stats_get(): rx_unicast:  1
PMD: i40e_dev_stats_get(): rx_unknown_protocol: 1
PMD: i40e_dev_stats_get(): rx_size_1522: 1
PMD: i40e_dev_stats_get(): *** PF stats end ***

   -- Forward statistics for port 0  --
   RX-packets: 1  RX-dropped: 0 RX-total: 1
   TX-packets: 0  TX-dropped: 0 TX-total: 0


PMD: i40e_update_vsi_stats(): *** VSI[14] stats start ***
PMD: i40e_update_vsi_stats(): tx_bytes:1514
PMD: i40e_update_vsi_stats(): tx_unicast:  1
PMD: i40e_update_vsi_stats(): *** VSI[14] stats end ***
PMD: i40e_dev_stats_get(): *** PF stats start ***
PMD: i40e_dev_stats_get(): tx_bytes:1514
PMD: i40e_dev_stats_get(): tx_unicast:  1
PMD: i40e_dev_stats_get(): tx_size_1522: 1
PMD: i40e_dev_stats_get(): *** PF stats end ***

   -- Forward statistics for port 1 --
   RX-packets: 0  RX-dropped: 0 RX-total: 0
   TX-packets: 1  TX-dropped: 0 TX-total: 1



   + Accumulated forward statistics for all ports+
   RX-packets: 1  RX-dropped: 0 RX-total: 1
   TX-packets: 1  TX-dropped: 0 TX-total: 1



=> OK

==
MTU = 1600
==
Packet sent
 > p = Ether / IP / UDP / Raw(MTU + HDR(Ethernet)- HDR(IP) - HDR(UDP))
 > len(p) = 1614

testpmd> port config mtu 0 1600
rte_eth_dev_set_mtu: Function not supported
Set MTU failed. diag=-95
testpmd> port config mtu 1 1600
rte_eth_dev_set_mtu: Function not supported
Set MTU failed. diag=-95
testpmd> start
testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...
PMD: i40e_update_vsi_stats(): *** VSI[13] stats start ***
PMD: i40e_update_vsi_stats(): rx_bytes:1618
PMD: i40e_update_vsi_stats(): rx_unicast:  1
PMD: i40e_update_vsi_stats(): *** VSI[13] stats end ***
PMD: i40e_dev_stats_get(): *** PF stats start ***
PMD: i40e_dev_stats_get(): rx_bytes:1614
PMD: i40e_dev_stats_get(): rx_unicast:  1
PMD: i40e_dev_stats_get(): rx_unknown_protocol: 1
PMD: i40e_dev_stats_get(): rx_size_big:  1
PMD: i40e_dev_stats_get(): *** PF stats end ***

   -- Forward statistics for port 0  --
   RX-packets: 1  RX-dropped: 0 RX-total: 1
   TX-packets: 0  TX-dropped: 0 TX-total: 0


PMD: i40e_update_vsi_stats(): *** VSI[14] stats start ***
PMD: i40e_update_vsi_stats(): tx_bytes:0
PMD: i40e_update_vsi_stats(): tx_unicast:  0
PMD: i40e_update_vsi_stats(): *** VSI[14] stats end ***
PMD: i40e_dev_stats_get(): *** PF stats start ***
PMD: i40e_dev_stats_get(): tx_bytes:0
PMD: i40e_dev_stats_get(): tx_unicast:  0
PMD: i40e_dev_stats_get(): tx_size_big:  0
PMD: i40e_dev_stats_get(): *** PF stats end ***

   -- Forward statistics for port 1  --
   RX-packets: 0  RX-dropped: 0 RX-total: 0
   TX-packets: 0  TX-dropped: 0 TX-total: 0



   + Accumulated forward 

[dpdk-dev] [PATCH 2/2] kdp: add virtual PMD for kernel slow data path communication

[Reshma Pattan]

Hi Ferruh,

On 1/27/2016 4:32 PM, Ferruh Yigit wrote:
> This patch provides slow data path communication to the Linux kernel.
> Patch is based on librte_kni, and heavily re-uses it.
>
> The main difference is librte_kni library converted into a PMD, to
> provide ease of use for applications.
>
> Now any application can use slow path communication without any update
> in application, because of existing eal support for virtual PMD.
>
> Also this PMD supports two methods to send packets to the Linux, first
> one is custom FIFO implementation with help of KDP kernel module, second
> one is Linux in-kernel tun/tap support. PMD first checks for KDP kernel
> module, if fails it tries to create and use a tap interface.
>
> With FIFO method: PMD's rx_pkt_burst() get packets from FIFO,
> and tx_pkt_burst() puts packet to the FIFO.
> The corresponding Linux virtual network device driver code
> also gets/puts packets from FIFO as they are coming from hardware.
>
> With tun/tap method: no external kernel module required, PMD reads from
> and writes packets to the tap interface file descriptor. Tap interface
> has performance penalty against FIFO implementation.
>
> Signed-off-by: Ferruh Yigit 
> ---
>   
> diff --git a/doc/guides/nics/pcap_ring.rst b/doc/guides/nics/pcap_ring.rst
> index 46aa3ac..78b7b61 100644
> --- a/doc/guides/nics/pcap_ring.rst
> +++ b/doc/guides/nics/pcap_ring.rst
> @@ -28,11 +28,11 @@
> +
> +
> +DPDK application can be used to forward packages between these interfaces:
> +

 Packages ==> packets.?

> diff --git a/drivers/net/kdp/rte_eth_kdp.c b/drivers/net/kdp/rte_eth_kdp.c
> new file mode 100644
> index 000..ac650d7
> --- /dev/null
> +++ b/drivers/net/kdp/rte_eth_kdp.c
> @@ -0,0 +1,481 @@
>

 No public API to create KDP PMD device. We should have one right?

> diff --git a/drivers/net/kdp/rte_kdp.h b/drivers/net/kdp/rte_kdp.h
> new file mode 100644
> index 000..b9db048
> --- /dev/null
> +++ b/drivers/net/kdp/rte_kdp.h
> @@ -0,0 +1,126 @@
>
> +struct rte_kdp_tap *rte_kdp_tap_init(uint16_t port_id);
> +struct rte_kdp *rte_kdp_init(uint16_t port_id);
> +
> +int rte_kdp_start(struct rte_kdp *kdp, struct rte_mempool *pktmbuf_pool,
> +   const struct rte_kdp_conf *conf);
> +
> +unsigned rte_kdp_rx_burst(struct rte_kdp *kdp,
> + struct rte_mbuf **mbufs, unsigned num);
> +
> +unsigned rte_kdp_tx_burst(struct rte_kdp *kdp,
> + struct rte_mbuf **mbufs, unsigned num);
> +
> +int rte_kdp_release(struct rte_kdp *kdp);
> +
> +void rte_kdp_close(void);
>

 These functions can be static.

 Thanks,
 Reshma

[dpdk-dev] DPDK i40evf problem in receving packet

[Saurabh Mishra]

Hi Qian --

Any suggestions? This is bit urgent.

/Saurabh

On Sat, Feb 6, 2016 at 9:22 AM, Saurabh Mishra 
wrote:

> Hi Qian --
>
>
> Here's the data from Host:
>
> [root at oscompute3 ~]# ethtool -i p3p1
>
> driver: i40e
>
> version: 1.0.11-k
>
> firmware-version: f4.40 a1.4 n04.53 e80001dc0
>
> bus-info: :04:00.0
>
> supports-statistics: yes
>
> supports-test: yes
>
> supports-eeprom-access: yes
>
> supports-register-dump: yes
>
> supports-priv-flags: no
>
> [root at oscompute3 ~]# ethtool -i p3p2
>
> driver: i40e
>
> version: 1.0.11-k
>
> firmware-version: f4.40 a1.4 n04.53 e80001dc0
>
> bus-info: :04:00.1
>
> supports-statistics: yes
>
> supports-test: yes
>
> supports-eeprom-access: yes
>
> supports-register-dump: yes
>
> supports-priv-flags: no
>
> [root at oscompute3 ~]#
>
> EthApp> drvinfo
>
> Port 0 driver: rte_i40evf_pmd (ver: RTE 2.2.0)
>
> Port 1 driver: rte_i40evf_pmd (ver: RTE 2.2.0)
>
> EthApp>
>
> On Fri, Feb 5, 2016 at 4:59 PM, Xu, Qian Q  wrote:
>
>> What's your current firmware info, can u run ethtool -i port_interface to
>> check?
>>
>> Thanks
>> Qian
>>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Saurabh Mishra
>> Sent: Saturday, February 06, 2016 6:33 AM
>> To: dev at dpdk.org; users at dpdk.org
>> Subject: [dpdk-dev] DPDK i40evf problem in receving packet
>>
>> Hi,
>>
>> I'm seeing two problems:
>>
>> 1)  when use our kernel '3.10.88-8.0.0.0.6', we only receive first
>> packet but not subsequent ones at all after that. However, when I use
>> centos7.0, then l2fwd is able to receive all the packets.
>>
>> 2) I've also seen that on centos7.0, symmetric_mp itself is not working.
>> dev start fails with 280 error.
>>
>> i40evf is giving us lot of headache. The i40evf kernel driver works
>> without any problem. Host is a centos7 KVM. I've already upgraded firmware
>> to latest.
>>
>> [root at localhost ~]# uname -a
>>
>> Linux localhost.localdomain 3.10.0-327.4.5.el7.x86_64 #1 SMP Mon Jan 25
>> 22:07:14 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> [root at localhost ~]#
>>
>> [root at localhost ~]# ./symmetric_mp fakeelf --file-prefix=virtaddr -c2
>> -m2048 -n1 --base-virtaddr=0x7fa0 --proc-type=primary -- -p 3
>> --num-procs=1 --proc-id=0
>>
>> EAL: Detected lcore 0 as core 0 on socket 0
>>
>> EAL: Detected lcore 1 as core 0 on socket 0
>>
>> EAL: Support maximum 128 logical core(s) by configuration.
>>
>> EAL: Detected 2 lcore(s)
>>
>> EAL: No free hugepages reported in hugepages-1048576kB
>>
>> EAL: VFIO modules not all loaded, skip VFIO support...
>>
>> EAL: Setting up physically contiguous memory...
>>
>> EAL: Ask a virtual area of 0x2a80 bytes
>>
>> EAL: Virtual area found at 0x7fa0 (size = 0x2a80)
>>
>> EAL: Ask a virtual area of 0x20 bytes
>>
>> EAL: Virtual area found at 0x7fa02a80 (size = 0x20)
>>
>> EAL: Ask a virtual area of 0x5400 bytes
>>
>> EAL: Virtual area found at 0x7fa02aa0 (size = 0x5400)
>>
>> EAL: Ask a virtual area of 0x40 bytes
>>
>> EAL: Virtual area found at 0x7fa07ea0 (size = 0x40)
>>
>> EAL: Ask a virtual area of 0x20 bytes
>>
>> EAL: Virtual area found at 0x7fa07ee0 (size = 0x20)
>>
>> EAL: Ask a virtual area of 0x20 bytes
>>
>> EAL: Virtual area found at 0x7fa07f00 (size = 0x20)
>>
>> EAL: Ask a virtual area of 0x60 bytes
>>
>> EAL: Virtual area found at 0x7fa07f20 (size = 0x60)
>>
>> EAL: Ask a virtual area of 0x20 bytes
>>
>> EAL: Virtual area found at 0x7fa07f80 (size = 0x20)
>>
>> EAL: Ask a virtual area of 0x20 bytes
>>
>> EAL: Virtual area found at 0x7fa07fa0 (size = 0x20)
>>
>> EAL: Ask a virtual area of 0x40 bytes
>>
>> EAL: Virtual area found at 0x7fa07fc0 (size = 0x40)
>>
>> EAL: Requesting 1024 pages of size 2MB from socket 0
>>
>> EAL: TSC frequency is ~260 KHz
>>
>> EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using
>> unreliable clock cycles !
>>
>> EAL: Master lcore 1 is ready (tid=3e55900;cpuset=[1])
>>
>> EAL: PCI device :00:09.0 on NUMA socket -1
>>
>> EAL:   probe driver: 8086:154c rte_i40evf_pmd
>>
>> EAL:   PCI memory mapped at 0x7fa08000
>>
>> EAL:   PCI memory mapped at 0x7fa08001
>>
>> EAL: PCI device :00:0a.0 on NUMA socket -1
>>
>> EAL:   probe driver: 8086:154c rte_i40evf_pmd
>>
>> EAL:   PCI memory mapped at 0x7fa080014000
>>
>> EAL:   PCI memory mapped at 0x7fa080024000
>>
>> # Initialising port 0... Queue :1
>>
>> PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
>> satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=0.
>>
>> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
>>
>> PMD: i40e_set_rx_function(): Port[0] doesn't meet Vector Rx preconditions
>>
>> PMD: i40e_set_rx_function(): Rx Burst Bulk Alloc Preconditions are
>> satisfied. Rx Burst Bulk Alloc function will be used on port=0.
>>
>> PMD: i40e_set_tx_function(): Simple tx finally be used.

[dpdk-dev] [PATCH] doc: drop old naming of the project

[Bruce Richardson]

On Mon, Feb 08, 2016 at 02:39:02PM +0100, Thomas Monjalon wrote:
> It was requested by Intel, more than one year ago, to replace the name
> "Intel DPDK" by "DPDK".
> Some references to the old name were still in some docs and code comments,
> leading to confusion.
> 
> Fixes: ac8ada004c12 ("doc: remove Intel references from release notes")
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: Bruce Richardson 

[dpdk-dev] [PATCH v2 1/3] driver/net/mpipe: support native build on tilegx platform.

[Thomas Monjalon]

Hi,

Sorry for being late for commenting.

2016-01-08 09:30, Liming Sun:
> -EZchip TILE-Gx
> +EZchip TILE-Gx/Mx

A comment about the TILE-Mx would be welcome.
Is it supported currently?
Isn't it an ARM arch?

>  M: Zhigang Lu 
> +M: Liming Sun 
>  F: lib/librte_eal/common/include/arch/tile/
>  F: drivers/net/mpipe/

[...]
> +# Compile combined lib by default.
> +CONFIG_RTE_BUILD_COMBINE_LIBS=y

Why forcing this option in the defconfig file?

[...]
>  ARCH  ?= tile
> +
> +HOST_ARCH := ${shell uname -m}
> +ifneq ($(filter tile%,${HOST_ARCH}),)
> +CROSS =
> +else
>  CROSS ?= tile-
> +endif

I don't think the CROSS variable should have a default value.
It really depends on the toolchain.

Talking about the toolchain, is it possible to build DPDK with the
provided binary toolchain http://www.tilera.com/scm/tilegx-x86_64.tar.bz2 ?
This is the Tilera Open Source page: http://www.tilera.com/scm/

[dpdk-dev] [PATCH v2] af_packet: make the device detachable

[Wojciech Zmuda]

Implement rte_pmd_af_packet_devuninit() exposed through struct
rte_driver.uninit() and set dev_flags to RTE_ETH_DEV_DETACHABLE,
to allow af_packet device deinitialization with API function
rte_eth_dev_detach(). This fixes memory leak by freeing memory
allocated during initialization.
During device initialization copy device name to ethdev->data to make
it compatible with rte_eth_dev_allocated().

Signed-off-by: Wojciech Zmuda 
---
v2:
* Fixed typo and a comment.
* Added feature to the 2.3 release notes.
* Free memory allocated for rx and tx queues.

 doc/guides/rel_notes/release_2_3.rst  |  4 
 drivers/net/af_packet/rte_eth_af_packet.c | 37 ++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_2_3.rst 
b/doc/guides/rel_notes/release_2_3.rst
index 7945694..4694646 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ This section should contain new features added in this 
release. Sample format:

   Enabled virtio 1.0 support for virtio pmd driver.

+* **Added af_packet driver deinitialization function.**
+
+  Implemented rte_pmd_af_packet_devuninit() exposed through struct
+  rte_driver.uninit() to allow af_packet device deinitialization with API 
function.

 Resolved Issues
 ---
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index 767f36b..eaed916 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -667,11 +667,13 @@ rte_pmd_init_internals(const char *name,
data->nb_tx_queues = (uint16_t)nb_queues;
data->dev_link = pmd_link;
data->mac_addrs = &(*internals)->eth_addr;
+   strncpy(data->name,
+   (*eth_dev)->data->name, strlen((*eth_dev)->data->name));

(*eth_dev)->data = data;
(*eth_dev)->dev_ops = 
(*eth_dev)->driver = NULL;
-   (*eth_dev)->data->dev_flags = 0;
+   (*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
(*eth_dev)->data->drv_name = drivername;
(*eth_dev)->data->kdrv = RTE_KDRV_NONE;
(*eth_dev)->data->numa_node = numa_node;
@@ -836,10 +838,43 @@ exit:
return ret;
 }

+static int
+rte_pmd_af_packet_devuninit(const char *name)
+{
+   struct rte_eth_dev *eth_dev = NULL;
+   struct pmd_internals *internals;
+   unsigned q;
+
+   RTE_LOG(INFO, PMD, "Closing AF_PACKET ethdev on numa socket %u\n",
+   rte_socket_id());
+
+   if (name == NULL)
+   return -1;
+
+   /* find the ethdev entry */
+   eth_dev = rte_eth_dev_allocated(name);
+   if (eth_dev == NULL)
+   return -1;
+
+   internals = eth_dev->data->dev_private;
+   for (q = 0; q < internals->nb_queues; q++) {
+   rte_free(internals->rx_queue[q].rd);
+   rte_free(internals->tx_queue[q].rd);
+   }
+
+   rte_free(eth_dev->data->dev_private);
+   rte_free(eth_dev->data);
+
+   rte_eth_dev_release_port(eth_dev);
+
+   return 0;
+}
+
 static struct rte_driver pmd_af_packet_drv = {
.name = "eth_af_packet",
.type = PMD_VDEV,
.init = rte_pmd_af_packet_devinit,
+   .uninit = rte_pmd_af_packet_devuninit,
 };

 PMD_REGISTER_DRIVER(pmd_af_packet_drv);
-- 
1.9.1

[dpdk-dev] [PATCH v7 2/2] eal/linux: Add support for handling built-in kernel modules

[Kamil Rytarowski]

Thank you!

W dniu 09.02.2016 o 15:56, Thomas Monjalon pisze:
> 2016-01-28 14:13, krytarowski at caviumnetworks.com:
>> From: Kamil Rytarowski 
>>
>> Currently rte_eal_check_module() detects Linux kernel modules via reading
>> /proc/modules. Built-in ones aren't listed there and therefore they are not
>> being found by the script.
>>
>> Add support for checking built-in modules with parsing the sysfs files
>>
>> This commit obsoletes the /proc/modules parsing approach.
>>
>> Signed-off-by: Kamil Rytarowski 
>> Acked-by: David Marchand 
>> Acked-by: Yuanhan Liu 
> An include is missing:
> #include 
> After adding this line,
> Series applied, thanks
>

[dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api

[Kulasek, TomaszX]

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, February 2, 2016 14:50
> To: Kulasek, TomaszX ; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> 
> Hi Tomasz,
> 
> > -Original Message-
> > From: Kulasek, TomaszX
> > Sent: Tuesday, February 02, 2016 10:01 AM
> > To: Ananyev, Konstantin; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> >
> > Hi Konstantin,
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Friday, January 15, 2016 19:45
> > > To: Kulasek, TomaszX; dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> > >
> > > Hi Tomasz,
> > >
> > > >
> > > > +   /* get new buffer space first, but keep old space around
> */
> > > > +   new_bufs = rte_zmalloc("ethdev->txq_bufs",
> > > > +   sizeof(*dev->data->txq_bufs) * 
> > > > nb_queues, 0);
> > > > +   if (new_bufs == NULL)
> > > > +   return -(ENOMEM);
> > > > +
> > >
> > > Why not to allocate space for txq_bufs together with tx_queues (as
> > > one chunk for both)?
> > > As I understand there is always one to one mapping between them
> anyway.
> > > Would simplify things a bit.
> > > Or even introduce a new struct to group with all related tx queue
> > > info togetehr struct rte_eth_txq_data {
> > >   void *queue; /*actual pmd  queue*/
> > >   struct rte_eth_dev_tx_buffer buf;
> > >   uint8_t state;
> > > }
> > > And use it inside struct rte_eth_dev_data?
> > > Would probably give a better data locality.
> > >
> >
> > Introducing such a struct will require a huge rework of pmd drivers. I
> don't think it's worth only for this one feature.
> 
> Why not?
> Things are getting more and more messy here: now we have a separate array
> of pointer to queues, Separate array of queue states, you are going to add
> separate array of tx buffers.
> For me it seems logical to unite all these 3 fields into one sub-struct.
> 

I agree with you, and probably such a work will be nice also for rx queues, but 
these two changes impacts on another part of dpdk. While buffered tx API is 
more client application helper.

For me these two thinks are different features and should be made separately 
because:
1) They are independent and can be done separately,
2) They can (and should) be reviewed, tested and approved separately,
3) They are addressed to another type of people (tx buffering to application 
developers, rte_eth_dev_data to pmd developers), so another people can be 
interested in having (or not) one or second feature

Even for bug tracking it will be cleaner to separate these two things. And yes, 
it is logical to unite it, maybe also for rx queues, but should be discussed 
separately.

I've made a prototype with this rework, and the impact on the code not related 
to this particular feature is too wide and strong to join them. I would rather 
to provide it as independent patch for further discussion only on it, if needed.

> >
> >
> > > > +/**
> > > > + * @internal
> > > > + * Structure used to buffer packets for future TX
> > > > + * Used by APIs rte_eth_tx_buffer and rte_eth_tx_buffer_flush  */
> > > > +struct rte_eth_dev_tx_buffer {
> > > > +   struct rte_mbuf *pkts[RTE_ETHDEV_TX_BUFSIZE];
> > >
> > > I think it is better to make size of pkts[] configurable at runtime.
> > > There are a lot of different usage scenarios - hard to predict what
> > > would be an optimal buffer size for all cases.
> > >
> >
> > This buffer is allocated in eth_dev shared memory, so there are two
> scenarios:
> > 1) We have prealocated buffer with maximal size, and then we can set
> > threshold level without restarting device, or
> > 2) We need to set its size before starting device.
> 
> >
> > Second one is better, I think.
> 
> Yep, I was thinking about 2) too.
> Might be an extra parameter in struct rte_eth_txconf.
> 

Struct rte_eth_txconf is passed to ethdev after rte_eth_dev_tx_queue_config, so 
we don't know its value when buffers are allocated.
I'm looking for another solution.

> >
> > Tomasz

[dpdk-dev] [PATCH v2] af_packet: make the device detachable

[Bruce Richardson]

On Tue, Feb 09, 2016 at 05:09:06PM +0100, Wojciech Zmuda wrote:
> Implement rte_pmd_af_packet_devuninit() exposed through struct
> rte_driver.uninit() and set dev_flags to RTE_ETH_DEV_DETACHABLE,
> to allow af_packet device deinitialization with API function
> rte_eth_dev_detach(). This fixes memory leak by freeing memory
> allocated during initialization.
> During device initialization copy device name to ethdev->data to make
> it compatible with rte_eth_dev_allocated().
> 
> Signed-off-by: Wojciech Zmuda 
> ---
> v2:
> * Fixed typo and a comment.
> * Added feature to the 2.3 release notes.
> * Free memory allocated for rx and tx queues.
> 
>  doc/guides/rel_notes/release_2_3.rst  |  4 
>  drivers/net/af_packet/rte_eth_af_packet.c | 37 
> ++-
>  2 files changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/rel_notes/release_2_3.rst 
> b/doc/guides/rel_notes/release_2_3.rst
> index 7945694..4694646 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -39,6 +39,10 @@ This section should contain new features added in this 
> release. Sample format:
>  
>Enabled virtio 1.0 support for virtio pmd driver.
>  
> +* **Added af_packet driver deinitialization function.**
> +
> +  Implemented rte_pmd_af_packet_devuninit() exposed through struct
> +  rte_driver.uninit() to allow af_packet device deinitialization with API 
> function.
>  

The use of "deinitialization" sounds awkward, and the overall text maybe could 
be
made less technical. Maybe talk about "allowing dynamic removal" of af_packet
devices [or even hotplug of them]? 

/Bruce

[dpdk-dev] [PATCH v2 2/2] driver/net/mpipe: fix the crash/hung issue when testpmd quits

[Bruce Richardson]

On Fri, Jan 08, 2016 at 09:39:08AM -0500, Liming Sun wrote:
> 1. Fixed the compiling issue of the ethtool example on tilegx
>platform.
> 2. Fixed the hung/crash issue when quitting testpmd under high
>traffic rate. The buffer error bit needs to be checked before
>processing the idesc and releasing the buffer. Code logic is
>also simplified.
> 

Again, with two issues being solved, this looks like two patches. Can you
also describe exactly the causes of the individual issues in each patch and how
the patch fixes them. 
Please also include a fixes line for each patch as described here:

http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-body

Thanks,
/Bruce

[dpdk-dev] [PATCH v7 2/2] eal/linux: Add support for handling built-in kernel modules

[Thomas Monjalon]

2016-01-28 14:13, krytarowski at caviumnetworks.com:
> From: Kamil Rytarowski 
> 
> Currently rte_eal_check_module() detects Linux kernel modules via reading
> /proc/modules. Built-in ones aren't listed there and therefore they are not
> being found by the script.
> 
> Add support for checking built-in modules with parsing the sysfs files
> 
> This commit obsoletes the /proc/modules parsing approach.
> 
> Signed-off-by: Kamil Rytarowski 
> Acked-by: David Marchand 
> Acked-by: Yuanhan Liu 

An include is missing:
#include 
After adding this line,
Series applied, thanks

[dpdk-dev] [PATCH v2 1/2] driver/net/mpipe: add rte_vect.h and enable CONFIG_RTE_LIBRTE_LPM

[Bruce Richardson]

On Fri, Jan 08, 2016 at 09:39:07AM -0500, Liming Sun wrote:
> rte_vect.h was missing earlier thus LPM was disabled and l3fwd is
> not able to compile. This commit implements the vector api and
> enable LPM in the tilegx configuration by default. It also includes
> a minor optimization to use __insn_fetchadd4() instead of
> rte_atomic32_xxx() in mpipe_dp_enter/mpipe_dp_exit to avoid the
> unnecessary memory fence.

This looks like it should be two patches to me. One patch to add the missing
dependency and get lpm to work. The second patch should then contain the driver
optimization. Do you agree?

/Bruce

PS: the commit title prefix for the first patch should probably be "eal/tile"
rather than mpipe, since it's not directly affecting the mpipe driver.

> 
> Signed-off-by: Liming Sun 
> Acked-by: Zhigang Lu 
> ---
>  config/defconfig_tile-tilegx-linuxapp-gcc  |  2 +-
>  drivers/net/mpipe/mpipe_tilegx.c   | 18 +++--
>  lib/librte_eal/common/include/arch/tile/rte_vect.h | 93 
> ++
>  3 files changed, 107 insertions(+), 6 deletions(-)
>  create mode 100644 lib/librte_eal/common/include/arch/tile/rte_vect.h
> 
[snip]
>+  mbuf->next = NULL;
>  
>   PMD_DEBUG_RX("%s: RX mbuf %p, buffer %p, buf_addr %p, size %d\n",
>mpipe_name(priv), mbuf, va, mbuf->buf_addr, size);
> diff --git a/lib/librte_eal/common/include/arch/tile/rte_vect.h 
> b/lib/librte_eal/common/include/arch/tile/rte_vect.h
> new file mode 100644
> index 000..32d768a
> --- /dev/null
> +++ b/lib/librte_eal/common/include/arch/tile/rte_vect.h
> @@ -0,0 +1,93 @@
> +/*
> + *   BSD LICENSE
> + *
> + *   Copyright (C) EZchip Semiconductor Ltd. 2015.

Maybe update the copyright year?

> + *
> + *   Redistribution and use in source and binary forms, with or without
> + *   modification, are permitted provided that the following conditions
[snip]

[dpdk-dev] [PATCH v2 1/3] driver/net/mpipe: support native build on tilegx platform.

[Bruce Richardson]

On Fri, Jan 08, 2016 at 09:30:36AM -0500, Liming Sun wrote:
> This submit updates the CROSS setting to support native build on
> TileGx platform. It also enable the combined library by default.
> 
> Signed-off-by: Liming Sun 
> Acked-by: Zhigang Lu 

Series applied to dpdk-next-net/rel_16_04.

/Bruce

[dpdk-dev] [PATCH v2] docs: add statistics read frequency to fm10k guide

[Harry van Haaren]

This patch documents that the statistics of fm10k based NICs must be
read regularly in order to avoid an undetected 32 bit integer-overflow.

Signed-off-by: Harry van Haaren 
---

v2:
-Moved notes to Known Issues section of Release Notes.

 doc/guides/nics/fm10k.rst| 16 
 doc/guides/rel_notes/release_2_3.rst |  4 
 2 files changed, 20 insertions(+)

diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst
index 4206b7f..4250c9e 100644
--- a/doc/guides/nics/fm10k.rst
+++ b/doc/guides/nics/fm10k.rst
@@ -65,3 +65,19 @@ The FM1 family of NICS support a maximum of a 15K jumbo 
frame. The value
 is fixed and cannot be changed. So, even when the ``rxmode.max_rx_pkt_len``
 member of ``struct rte_eth_conf`` is set to a value lower than 15364, frames
 up to 15364 bytes can still reach the host interface.
+
+Statistic Polling Frequency
+~~~
+
+The FM1 NICs expose a set of statistics via the PCI BARs. These statistics
+are read from the hardware registers when ``rte_eth_stats_get()`` or
+``rte_eth_xstats_get()`` is called. The packet counting registers are 32 bits
+while the byte counting registers are 48 bits. As a result, the statistics must
+be polled regularly in order to ensure the consistency of the returned reads.
+
+Given the PCIe Gen3 x8, about 50Gbps of traffic can occur. With 64 byte packets
+this gives almost 100 million packets/second, causing 32 bit integer overflow
+after approx 40 seconds. To ensure these overflows are detected and accounted
+for in the statistics, it is necessary to read statistic regularly. It is
+suggested to read stats every 20 seconds, which will gaurantee the statistics
+are accurate.
diff --git a/doc/guides/rel_notes/release_2_3.rst 
b/doc/guides/rel_notes/release_2_3.rst
index 99de186..6748b89 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -31,6 +31,10 @@ Other
 Known Issues
 

+* **FM10K: Statistics Polling Frequency**
+
+  A section has been added to the NIC guide for fm10k about the maximum
+  time between reading statistics and 32 bit packet counter overflows.

 API Changes
 ---
-- 
2.5.0

[dpdk-dev] [PATCH] docs: add statistics read frequency to fm10k guide

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, February 8, 2016 4:01 PM
> To: Van Haaren, Harry 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] docs: add statistics read frequency to
> fm10k guide
> 
> 2016-02-08 15:42, Harry van Haaren:
> > This patch documents that the statistics of fm10k based NICs must be
> > read regularly in order to avoid an undetected 32 bit integer-overflow.
> >
> > Signed-off-by: Harry van Haaren 
> > ---
> >  doc/guides/nics/fm10k.rst| 16 
> >  doc/guides/rel_notes/release_2_3.rst |  4 
> 
> Thanks for improving the doc.
> I think we should not add it to the release notes. Other opinions?


In general it shouldn't be required to add a note about doc changes to the 
release note.

In this case the note part may make more sense in the "Known Issues" section of 
the release note.

John.
-- 

[dpdk-dev] [PATCH] tools: fix syntax errors and add support for Python 3

[Thomas Monjalon]

2016-01-27 20:59, yurai:
> This patch fixes syntax errors from tools/setup.sh during binding ethernet 
> device
> on systems where Python 3 is default. Backward compability with Python 2 is 
> preserved.
> 
> Signed-off-by: Dawid Jurczak 

Applied, thanks

[dpdk-dev] [PATCH v2 4/4] virtio: use pci ioport api

[Tetsuya Mukawa]

On 2016/02/07 16:48, David Marchand wrote:
> Move all os / arch specifics to eal.
>
> Signed-off-by: David Marchand 
> ---
>  drivers/net/virtio/virtio_pci.c | 339 
> +++-
>  drivers/net/virtio/virtio_pci.h |  38 +
>  2 files changed, 55 insertions(+), 322 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
> index b1610dd..e04c0db 100644
> --- a/drivers/net/virtio/virtio_pci.c
> +++ b/drivers/net/virtio/virtio_pci.c
> @@ -49,74 +49,35 @@
>
> @@ -311,132 +191,20 @@ legacy_virtio_has_msix(const struct rte_pci_addr *loc)
>  
>  /* Extract I/O port numbers from sysfs */
>  static int
> -virtio_resource_init_by_uio(struct rte_pci_device *pci_dev)
> +legacy_virtio_resource_init(struct rte_pci_device *pci_dev,
> + struct virtio_hw *hw)

One more legacy_virtio_resource_init() is defined like below.

#ifdef RTE_EXEC_ENV_LINUXAPP

#else

static int
legacy_virtio_resource_init(struct rte_pci_device *pci_dev __rte_unused)
{
/* no setup required */
return 0;
}
#endif

Should we change this also?

Thanks,
Tetsuya

[dpdk-dev] [PATCH] tools: Fix typo in dpdk_nic_bind.py script.

[Thomas Monjalon]

2016-02-09 11:10, Bruce Richardson:
> On Mon, Feb 08, 2016 at 04:33:46PM -0800, Jeff Shaw wrote:
> > We should call sys.exit(), not divide sys by exit().

Obviously :)

> > Signed-off-by: Jeff Shaw 
> 
> Acked-by: Bruce Richardson 

Applied, thanks

[dpdk-dev] [PATCH v2] doc: introduce networking driver matrix

[Thomas Monjalon]

2016-01-27 21:07, Thomas Monjalon:
> In order to better compare the drivers and check what is missing
> for a common baseline, we need to fill a matrix.
> 
> A CSS trick is used to fit the HTML page.
> The PDF output needs some LaTeX wizardry.
> 
> Signed-off-by: Thomas Monjalon 
> ---
> v2: add vector PMDs

Nobody complains after 2 weeks, so I guess the idea is welcomed.
Applied

The LaTeX formatting still needs to be fixed to view the entire table
in the PDF doc.

This empty table will have a value when it will be properly filled.
Please, maintainers of drivers, your help is requested here.
We now have 2 months to fill each driver columns with crosses (X).
Thanks

[dpdk-dev] [PATCH v2] doc: minor correction in document

[Thomas Monjalon]

2016-02-02 13:11, Ferruh Yigit:
> * remove outdated chapter reference to Multi-process support.
>   Fixes: fc1f2750a3ec ("doc: programmers guide")
> 
> * html output converts "--" to "-", this is wrong when explaining the
>   command arguments, used fixed width quotes for them.
> 
> v2:
> * for "--" use fixed width quotes instead of option list.
> * expand fixed width quotes usage to other "--" use cases.
> 
> Signed-off-by: Ferruh Yigit 

Applied, thanks

[dpdk-dev] [PATCH v2] e1000: enable promiscuous and allmulticast support for VF

[Yury Kylulin]

Enable promiscuous and allmulticast mode control from the VF using
rte_eth_promiscuous_enable()/rte_eth_promiscuous_disable() and
rte_eth_allmulticast_enable()/rte_eth_allmulticast_disable().

For promiscuous mode host/PF igb driver should be built with
IGB_ENABLE_VF_PROMISC.

For allmulticast mode "allmulti" flag should be set for appropriate PF
ifconfig eth0 allmulti

Signed-off-by: Yury Kylulin 
---
v2
* Added promiscuous mode control
* Switching logic is the same like in igb PF driver

 drivers/net/e1000/igb_ethdev.c |   49 
 1 file changed, 49 insertions(+)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index d1bbcda..677f9a2 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -152,6 +152,10 @@ static int igbvf_dev_configure(struct rte_eth_dev *dev);
 static int igbvf_dev_start(struct rte_eth_dev *dev);
 static void igbvf_dev_stop(struct rte_eth_dev *dev);
 static void igbvf_dev_close(struct rte_eth_dev *dev);
+static void igbvf_promiscuous_enable(struct rte_eth_dev *dev);
+static void igbvf_promiscuous_disable(struct rte_eth_dev *dev);
+static void igbvf_allmulticast_enable(struct rte_eth_dev *dev);
+static void igbvf_allmulticast_disable(struct rte_eth_dev *dev);
 static int eth_igbvf_link_update(struct e1000_hw *hw);
 static void eth_igbvf_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *rte_stats);
@@ -369,6 +373,10 @@ static const struct eth_dev_ops igbvf_eth_dev_ops = {
.dev_start= igbvf_dev_start,
.dev_stop = igbvf_dev_stop,
.dev_close= igbvf_dev_close,
+   .promiscuous_enable   = igbvf_promiscuous_enable,
+   .promiscuous_disable  = igbvf_promiscuous_disable,
+   .allmulticast_enable  = igbvf_allmulticast_enable,
+   .allmulticast_disable = igbvf_allmulticast_disable,
.link_update  = eth_igb_link_update,
.stats_get= eth_igbvf_stats_get,
.xstats_get   = eth_igbvf_xstats_get,
@@ -2829,6 +2837,47 @@ igbvf_dev_close(struct rte_eth_dev *dev)
igb_dev_free_queues(dev);
 }

+static void
+igbvf_promiscuous_enable(struct rte_eth_dev *dev)
+{
+   struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* Set both unicast and multicast promisc */
+   e1000_promisc_set_vf(hw, e1000_promisc_enabled);
+}
+
+static void
+igbvf_promiscuous_disable(struct rte_eth_dev *dev)
+{
+   struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* If in allmulticast mode leave multicast promisc */
+   if (dev->data->all_multicast == 1)
+   e1000_promisc_set_vf(hw, e1000_promisc_multicast);
+   else
+   e1000_promisc_set_vf(hw, e1000_promisc_disabled);
+}
+
+static void
+igbvf_allmulticast_enable(struct rte_eth_dev *dev)
+{
+   struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* In promiscuous mode multicast promisc already set */
+   if (dev->data->promiscuous == 0)
+   e1000_promisc_set_vf(hw, e1000_promisc_multicast);
+}
+
+static void
+igbvf_allmulticast_disable(struct rte_eth_dev *dev)
+{
+   struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* In promiscuous mode leave multicast promisc enabled */
+   if (dev->data->promiscuous == 0)
+   e1000_promisc_set_vf(hw, e1000_promisc_disabled);
+}
+
 static int igbvf_set_vfta(struct e1000_hw *hw, uint16_t vid, bool on)
 {
struct e1000_mbx_info *mbx = >mbx;
-- 
1.7.9.5

[dpdk-dev] [PATCH] doc: add a further ACL example

[Thomas Monjalon]

> > Add a further ACL example where the elements of the search key are not
> > entirely fitting into the 4 consecutive bytes of all input fields.
> > 
> > Signed-off-by: Antonio Fischetti 
> 
> Acked-by: John McNamara 

Applied, thanks

[dpdk-dev] [PATCH] mk: add makefile extention support

[Keith Wiles]

Adding support to the build system to allow for Makefile.XXX
extention to a subtree, which already has Makefiles. These
Makefiles could be from the autotools and others places. Using
the Makefile extention RTE_MKFILE_SUFFIX in a makefile subtree
using 'export RTE_MKFILE_SUFFIX=.XXX' to use Makefile.XXX in
that subtree.

The main reason I needed this feature was to integrate a autotool
open source projects with DPDK and keep the original Makefiles.

Signed-off-by: Keith Wiles 
---
 mk/internal/rte.extvars.mk |  2 +-
 mk/rte.bsdmodule.mk|  6 +++---
 mk/rte.extsubdir.mk|  2 +-
 mk/rte.module.mk   |  6 +++---
 mk/rte.sdkbuild.mk | 10 +-
 mk/rte.sdkconfig.mk|  6 +++---
 mk/rte.sdkdepdirs.mk   | 10 +-
 mk/rte.sdkgcov.mk  |  2 +-
 mk/rte.sdktest.mk  |  2 +-
 mk/rte.subdir.mk   | 14 +++---
 10 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/mk/internal/rte.extvars.mk b/mk/internal/rte.extvars.mk
index 040d39f..3361551 100644
--- a/mk/internal/rte.extvars.mk
+++ b/mk/internal/rte.extvars.mk
@@ -48,7 +48,7 @@ ifeq ("$(origin M)", "command line")
 RTE_EXTMK := $(abspath $(M))
 endif
 endif
-RTE_EXTMK ?= $(RTE_SRCDIR)/Makefile
+RTE_EXTMK ?= $(RTE_SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX)
 export RTE_EXTMK

 # RTE_SDK_BIN must point to .config, include/ and lib/.
diff --git a/mk/rte.bsdmodule.mk b/mk/rte.bsdmodule.mk
index 86b92ff..e8a504a 100644
--- a/mk/rte.bsdmodule.mk
+++ b/mk/rte.bsdmodule.mk
@@ -80,7 +80,7 @@ build: _postbuild

 # build module
 $(MODULE).ko: $(SRCS_LINKS)
-   $(Q)if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; 
fi
+   $(Q)if [ ! -f $(notdir Makefile)$(RTE_MKFILE_SUFFIX) ]; then ln -nfs 
$(SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX) . ; fi
$(Q)if [ ! -f $(notdir BSDmakefile) ]; then ln -nfs 
$(SRCDIR)/BSDmakefile . ; fi
$(Q)MAKEFLAGS= $(BSDMAKE)

@@ -100,11 +100,11 @@ clean: _postclean
 # do a make clean and remove links
 .PHONY: doclean
 doclean:
-   $(Q)if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; 
fi
+   $(Q)if [ ! -f $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then ln -nfs 
$(SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX) . ; fi
$(Q)$(MAKE) -C $(RTE_KERNELDIR) M=$(CURDIR) O=$(RTE_KERNELDIR) clean
$(Q)$(foreach FILE,$(SRCS-y) $(SRCS-n) $(SRCS-),\
if [ -h $(notdir $(FILE)) ]; then rm -f $(notdir $(FILE)) ; fi 
;)
-   $(Q)if [ -h $(notdir Makefile) ]; then rm -f $(notdir Makefile) ; fi
+   $(Q)if [ -h $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then rm -f 
$(notdir Makefile$(RTE_MKFILE_SUFFIX)) ; fi
$(Q)rm -f $(_BUILD_TARGETS) $(_INSTALL_TARGETS) $(_CLEAN_TARGETS) \
$(INSTALL-FILES-all)

diff --git a/mk/rte.extsubdir.mk b/mk/rte.extsubdir.mk
index f50f006..55d4e16 100644
--- a/mk/rte.extsubdir.mk
+++ b/mk/rte.extsubdir.mk
@@ -45,7 +45,7 @@ clean: $(DIRS-y)
 $(DIRS-y):
@echo "== $@"
$(Q)$(MAKE) -C $(@) \
-   M=$(CURDIR)/$(@)/Makefile \
+   M=$(CURDIR)/$(@)/Makefile$(RTE_MKFILE_SUFFIX) \
O=$(BASE_OUTPUT)/$(CUR_SUBDIR)/$(@)/$(RTE_TARGET) \
BASE_OUTPUT=$(BASE_OUTPUT) \
CUR_SUBDIR=$(CUR_SUBDIR)/$(@) \
diff --git a/mk/rte.module.mk b/mk/rte.module.mk
index 53ed4fe..6477bbe 100644
--- a/mk/rte.module.mk
+++ b/mk/rte.module.mk
@@ -76,7 +76,7 @@ build: _postbuild

 # build module
 $(MODULE).ko: $(SRCS_LINKS)
-   @if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; fi
+   @if [ ! -f $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then ln -nfs 
$(SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX) . ; fi
@$(MAKE) -C $(RTE_KERNELDIR) M=$(CURDIR) O=$(RTE_KERNELDIR) \
CC="$(KERNELCC)" CROSS_COMPILE=$(CROSS) V=$(if $V,1,0)

@@ -97,11 +97,11 @@ clean: _postclean
 # do a make clean and remove links
 .PHONY: doclean
 doclean:
-   @if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; fi
+   @if [ ! -f $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then ln -nfs 
$(SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX) . ; fi
$(Q)$(MAKE) -C $(RTE_KERNELDIR) M=$(CURDIR) O=$(RTE_KERNELDIR) clean
@$(foreach FILE,$(SRCS-y) $(SRCS-n) $(SRCS-),\
if [ -h $(notdir $(FILE)) ]; then rm -f $(notdir $(FILE)) ; fi 
;)
-   @if [ -h $(notdir Makefile) ]; then rm -f $(notdir Makefile) ; fi
+   @if [ -h $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then rm -f $(notdir 
Makefile$(RTE_MKFILE_SUFFIX)) ; fi
@rm -f $(_BUILD_TARGETS) $(_INSTALL_TARGETS) $(_CLEAN_TARGETS) \
$(INSTALL-FILES-all)

diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 85f603c..3860843 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -76,15 +76,15 @@ clean: $(CLEANDIRS)
 $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
-   $(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
+   

[dpdk-dev] [PATCH v2] mempool: reduce rte_mempool structure size

[Keith Wiles]

Patch v2 to add some comments and setup for RTE_NEXT_ABI changes.

The rte_mempool structure is changed, which will cause an ABI change
for this structure. Providing backward compat is not reasonable
here as this structure is used in multiple defines/inlines.

Allow mempool cache support to be dynamic depending on if the
mempool being created needs cache support. Saves about 1.5M of
memory used by the rte_mempool structure.

Allocating small mempools which do not require cache can consume
larges amounts of memory if you have a number of these mempools.

Signed-off-by: Keith Wiles 
---
 app/test/test_mempool.c |  5 ++
 config/defconfig_x86_64-native-linuxapp-gcc |  5 ++
 lib/librte_mempool/rte_mempool.c| 83 ++---
 lib/librte_mempool/rte_mempool.h| 57 +++-
 4 files changed, 143 insertions(+), 7 deletions(-)

diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 72f8fb6..2829d40 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -122,8 +122,13 @@ test_mempool_basic(void)
return -1;

printf("get private data\n");
+#ifdef RTE_NEXT_ABI
+   if (rte_mempool_get_priv(mp) != (char *)mp +
+   MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size))
+#else
if (rte_mempool_get_priv(mp) !=
(char*) mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num))
+#endif
return -1;

printf("get physical address of an object\n");
diff --git a/config/defconfig_x86_64-native-linuxapp-gcc 
b/config/defconfig_x86_64-native-linuxapp-gcc
index 60baf5b..02e9ace 100644
--- a/config/defconfig_x86_64-native-linuxapp-gcc
+++ b/config/defconfig_x86_64-native-linuxapp-gcc
@@ -40,3 +40,8 @@ CONFIG_RTE_ARCH_64=y

 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
+CONFIG_RTE_BUILD_SHARED_LIB=y
+CONFIG_RTE_NEXT_ABI=n
+CONFIG_RTE_EAL_IGB_UIO=n
+CONFIG_RTE_LIBRTE_KNI=n
+CONFIG_RTE_KNI_KMOD=n
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aff5f6d..c61dc44 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -452,12 +452,17 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
/* compilation-time checks */
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
  RTE_CACHE_LINE_MASK) != 0);
+#ifdef RTE_NEXT_ABI
+   RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
+ RTE_CACHE_LINE_MASK) != 0);
+#else
 #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
  RTE_CACHE_LINE_MASK) != 0);
RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
  RTE_CACHE_LINE_MASK) != 0);
 #endif
+#endif /* RTE_NEXT_ABI */
 #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
  RTE_CACHE_LINE_MASK) != 0);
@@ -527,9 +532,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
 */
int head = sizeof(struct rte_mempool);
int new_size = (private_data_size + head) % page_size;
-   if (new_size) {
+   if (new_size)
private_data_size += page_size - new_size;
-   }
}

/* try to allocate tailq entry */
@@ -544,7 +548,12 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
 * store mempool objects. Otherwise reserve a memzone that is large
 * enough to hold mempool header and metadata plus mempool objects.
 */
+#ifdef RTE_NEXT_ABI
+   mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size);
+   mempool_size += private_data_size;
+#else
mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num) + private_data_size;
+#endif /* RTE_NEXT_ABI */
mempool_size = RTE_ALIGN_CEIL(mempool_size, RTE_MEMPOOL_ALIGN);
if (vaddr == NULL)
mempool_size += (size_t)objsz.total_size * n;
@@ -598,9 +607,22 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
mp->private_data_size = private_data_size;

+#ifdef RTE_NEXT_ABI
+   /*
+* local_cache pointer is set even if cache_size is zero.
+* The local_cache points to just past the elt_pa[] array.
+*/
+   mp->local_cache = (struct rte_mempool_cache *)
+   ((char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, 0));
+
+   /* calculate address of the first element for continuous mempool. */
+   obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size) +
+   private_data_size;
+#else
/* calculate address of the first element for continuous mempool. */
obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num) +

[dpdk-dev] DPDK Community Call - Linux Foundation

[Dave Neary]

Is there any substantive feedback on this? It seems like silence =
consensus (or that the people who might care more are not on this list).

My suggestion is to go to the next stage, start drafting a membership
agreement and identify potential members to recruit. Will the Linux
Foundation take point on recruiting members, or does that fall to the
community too?

Thanks,
Dave.

On 02/05/2016 12:20 PM, Bob Monkman wrote:
> Right. Yes, I can access it just fine.
> Thx,
> 
> 
> Robert (Bob) Monkman
> Enterprise Segment Marketing Manager
> 150 Rose Orchard Way
> San Jose, Ca 95134
> M: +1.510.676.5490
> 
> 
> -Original Message-
> From: O'Driscoll, Tim [mailto:tim.odriscoll at intel.com]
> Sent: Friday, February 05, 2016 9:09 AM
> To: Bob Monkman; dev at dpdk.org; Laura Kempke; Michael Dolan
> Subject: RE: DPDK Community Call - Linux Foundation
> 
> 
>> -Original Message-
>> From: Bob Monkman [mailto:Bob.Monkman at arm.com]
>> Sent: Friday, February 5, 2016 4:30 PM
>> To: O'Driscoll, Tim; dev at dpdk.org; Laura Kempke; Michael Dolan
>> Subject: RE: DPDK Community Call - Linux Foundation
>>
>> Thanks very much for the minutes. Can we get Laura's draft deck re:
>> budget and tradeoffs/options?
> 
> There's no slide deck, just the spreadsheet at: 
> https://docs.google.com/a/linuxfoundation.org/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit?usp=sharing.
>  This outlines the minimum (column B) and optional (column C) alternatives 
> that Laura presented on Tuesday.
> 
> I believe access to the spreadsheet is open to everybody, but if anybody runs 
> into issues I'm sure Laura can help to grant access.
> 
> 
> Tim
> 
>>
>> Robert (Bob) Monkman
>> Enterprise Segment Marketing Manager
>> 150 Rose Orchard Way
>> San Jose, Ca 95134
>> M: +1.510.676.5490
>>
>>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
>> Sent: Thursday, February 04, 2016 2:16 PM
>> To: dev at dpdk.org; Laura Kempke; Michael Dolan
>> Subject: Re: [dpdk-dev] DPDK Community Call - Linux Foundation
>>
>> Here are some brief minutes of our discussion on Tuesday. Apologies
>> for the delay in sending these out.
>>
>> Attendees: Bob Monkman, Bruce Richardson, Dave Neary, Ferruh Yigit,
>> Jim St Leger, John Bromhead, John McNamara, Keith Wiles, Konstantin
>> Ananyev, Laura Kempke, M Jay, Martin Horne, Mike Dolan, Mike Glynn,
>> Tetsuya Mukawa, Thomas Monjalon, Tim O'Driscoll, Yoshihiro Nakajima
>> Note: This list is taken from the GoToMeeting tool, but since people
>> joined/left at different times it may not be complete.
>>
>>
>> The background to the call is that we had a discussion at the
>> Userspace event in Dublin on using Linux Foundation to provide a
>> lightweight governance model for DPDK. This would cover marketing,
>> event planning, trademarks, other legal issues etc. It would not cover
>> any technical governance of the project.
>>
>> Following this and a follow-up call we had in December, a small group
>> of us (Dave Neary, Thomas Monjalon, Stephen Hemminger, Vincent Jardin,
>> me) met with the Linux Foundation to create a draft budget which is
>> available at: https://docs.google.com/spreadsheets/d/1-
>> 3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256.
>>
>> Laura walked through the spreadsheet at the meeting. Column B
>> represents the minimum budget requirement for DPDK and totals $227k.
>> Column C shows a number of optional additions and totals $766k. Points
>> of discussion
>> included:
>> - The minimum option assumes that some of the event costs are covered
>> by registration fees and sponsorship.
>> - Jim asked about LF hosting DPDK IT infrastructure. This isn't
>> currently included (row 23) but could be added if desired.
>> - The item for hackathons (row 29) is just a placeholder. The general
>> consensus seemed to be that we wouldn't need these.
>>
>> Taking the minimum budget requirement of ~$227k, that would mean we'd
>> be looking for ~10-15 companies to contribute, each paying a flat-rate
>> membership fee of ~$15-25k.
>>
>> There was a question on what member companies would get in return for
>> their contribution. We need to do some further work on this, but the
>> likelihood is that they would get a seat on a board which would
>> determine how the DPDK budget is spent. The scope of this board would
>> be limited to marketing/event/legal issues. Technical governance would
>> continue to be handled separately via our Maintainers and our
>> Architecture Board.
>>
>> Most people on the call felt that the proposal to use LF was a good
>> idea and was worth pursuing further. However, we only had a small
>> number of people on the call so that may not be representative of the
>> views of the entire community. Therefore, if anybody has further
>> thoughts or input on this, please feel free to reply to this email.
>>
>> Keith suggested holding a poll so that we can quantify the level of
>> interest and give people a way to 

[dpdk-dev] [PATCH] tools: Fix typo in dpdk_nic_bind.py script.

[Bruce Richardson]

On Mon, Feb 08, 2016 at 04:33:46PM -0800, Jeff Shaw wrote:
> We should call sys.exit(), not divide sys by exit().
> 
> Signed-off-by: Jeff Shaw 

Acked-by: Bruce Richardson 

[dpdk-dev] [PATCH] mlx4: fix unneeded function error with clang v3.6

[Bruce Richardson]

On Tue, Feb 09, 2016 at 09:39:26AM +0100, Adrien Mazarguil wrote:
> On Mon, Feb 08, 2016 at 10:11:49PM +, Bruce Richardson wrote:
> > When compiling with clang 3.6, the mlx4 driver gives the following error
> > message about an unneeded function.
> > 
> >   CC mlx4.o
> > .../drivers/net/mlx4/mlx4.c:136:20: fatal error: function
> >   'wr_id_t_check' is not needed and will not be emitted
> > [-Wunneeded-internal-declaration]
> > static inline void wr_id_t_check(void)
> >^
> > 1 error generated.
> > 
> > The function is to compile-time check the size of wr_id_t, so use
> > the standard DPDK BUILD_BUG_ON macro to do so in the init function
> > instead.
> > 
> > Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
> > 
> > Signed-off-by: Bruce Richardson 
> 
> Thanks.
> 
> Acked-by: Adrien Mazarguil 
> 
> -- 
Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH v7 2/2] vhost: Add VHOST PMD

[Tetsuya Mukawa]

On 2016/02/08 18:42, Ferruh Yigit wrote:
> On Fri, Feb 05, 2016 at 03:28:37PM +0900, Tetsuya Mukawa wrote:
>> On 2016/02/04 20:17, Ferruh Yigit wrote:
>>> On Thu, Feb 04, 2016 at 04:26:31PM +0900, Tetsuya Mukawa wrote:
>>>
>>> Hi Tetsuya,
>>>
 The patch introduces a new PMD. This PMD is implemented as thin wrapper
 of librte_vhost. It means librte_vhost is also needed to compile the PMD.
 The vhost messages will be handled only when a port is started. So start
 a port first, then invoke QEMU.

 The PMD has 2 parameters.
  - iface:  The parameter is used to specify a path to connect to a
virtio-net device.
  - queues: The parameter is used to specify the number of the queues
virtio-net device has.
(Default: 1)

 Here is an example.
 $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i

 To connect above testpmd, here is qemu command example.

 $ qemu-system-x86_64 \
 
 -chardev socket,id=chr0,path=/tmp/sock0 \
 -netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
 -device virtio-net-pci,netdev=net0,mq=on

 Signed-off-by: Tetsuya Mukawa 
>>> Please find some more comments, mostly minor nits,
>>>
>>> please feel free to add my ack for next version of this patch:
>>> Acked-by: Ferruh Yigit 
>>>
>>> <...>
 diff --git a/drivers/net/vhost/rte_eth_vhost.c 
 b/drivers/net/vhost/rte_eth_vhost.c
 new file mode 100644
 index 000..b2305c2
 --- /dev/null
 +++ b/drivers/net/vhost/rte_eth_vhost.c
>>> <...>
 +
 +struct pmd_internal {
 +  TAILQ_ENTRY(pmd_internal) next;
 +  char *dev_name;
 +  char *iface_name;
 +  uint8_t port_id;
>>> You can also get rid of port_id too, if you keep list of rte_eth_dev.
>>> But this is not so important, keep as it is if you want to.
>> Thank you so much for checking and good suggestions.
>> I will follow your comments without below.
>>
 +
 +  volatile uint16_t once;
 +};
 +
>>> <...>
 +
 +static int
 +new_device(struct virtio_net *dev)
 +{
>>> <...>
 +
 +  for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
 +  vq = eth_dev->data->rx_queues[i];
 +  if (vq == NULL)
>>> can vq be NULL? It is allocated in rx/tx_queue_setup() and there is already 
>>> a NULL check there?
>> I doubt user may not setup all queues.
>> In this case, we need above checking.
>>
 +  continue;
 +  vq->device = dev;
 +  vq->internal = internal;
 +  rte_vhost_enable_guest_notification(dev, vq->virtqueue_id, 0);
 +  }
 +  for (i = 0; i < eth_dev->data->nb_tx_queues; i++) {
 +  vq = eth_dev->data->tx_queues[i];
 +  if (vq == NULL)
 +  continue;
>> Same here.
>>
 +  vq->device = dev;
 +  vq->internal = internal;
 +  rte_vhost_enable_guest_notification(dev, vq->virtqueue_id, 0);
 +  }
 +
 +  dev->flags |= VIRTIO_DEV_RUNNING;
 +  dev->priv = eth_dev;
 +  eth_dev->data->dev_link.link_status = 1;
 +
 +  for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
 +  vq = eth_dev->data->rx_queues[i];
 +  if (vq == NULL)
 +  continue;
>> But we can remove this.
> If in above loop, vq can be NULL because user not setup the queue, it will be 
> NULL in here too, isn't it?
> Why we can remove NULL check here?

Yes, you are right.
Will fix it and submit again.

Thanks,
Tetsuya


 +  rte_atomic32_set(>allow_queuing, 1);
 +  }
 +  for (i = 0; i < eth_dev->data->nb_tx_queues; i++) {
 +  vq = eth_dev->data->tx_queues[i];
 +  if (vq == NULL)
 +  continue;
>> And this.
>>
>>> <...>
 +  if (dev->data->rx_queues[i] == NULL)
 +  continue;
 +  vq = dev->data->rx_queues[i];
 +  stats->q_ipackets[i] = vq->rx_pkts;
 +  rx_total += stats->q_ipackets[i];
 +
 +  stats->q_ibytes[i] = vq->rx_bytes;
 +  rx_total_bytes += stats->q_ibytes[i];
 +  }
 +
 +  for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
 +   i < dev->data->nb_tx_queues; i++) {
 +  if (dev->data->tx_queues[i] == NULL)
>>> more queue NULL check here, I am not sure if these are necessary
>> Same here, in the case user doesn't setup all queues, I will leave this.
>>
>> Anyway, I will fix below code.
>>  - Manage ether devices list instead of internal structures list.
>>  - Remove needless NULL checking.
>>  - Replace "pthread_exit" to "return NULL".
>>  - Replace rte_panic to RTE_LOG, also add error handling.
>>  - Remove duplicated lines.
>>  - Remove needless casting.
>>  - Follow coding style.
>>  - Remove needless parenthesis.
>>
>> And leave below.
>>  - some NULL checking before accessing 

[dpdk-dev] [PATCH 1/2] kdp: add kernel data path kernel module

[Ferruh Yigit]

On Mon, Feb 08, 2016 at 05:14:54PM +, Reshma Pattan wrote:

Hi Reshma,

>
>
> On 1/27/2016 4:32 PM, Ferruh Yigit wrote:
>> This kernel module is based on KNI module, but this one is stripped
>> version of it and only for data messages, no control functionality
>> provided.
>>
>> FIFO implementation of the KNI is kept exact same, but ethtool related
>> code removed and virtual network management related code simplified.
>>
>> This module contains kernel support to create network devices and
>> this module has a simple driver for virtual network device, the driver
>> simply puts/gets packets to/from FIFO instead of real hardware.
>>
>> FIFO is created owned by userspace application, which is for this case
>> KDP PMD.
>>
>> In long term this patch intends to replace the KNI and KNI will be
>> depreciated.
>>
>> Signed-off-by: Ferruh Yigit 
>> ---
>>   
>> diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kdp_common.h 
>> b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kdp_common.h
>> new file mode 100644
>> index 000..0c77f58
>> --- /dev/null
>> +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kdp_common.h
>>
>> +/**
>> + * KDP name is part of memzone name.
>> + */
>> +#define RTE_KDP_NAMESIZE 32
>> +
>> +#ifndef RTE_CACHE_LINE_SIZE
>> +#define RTE_CACHE_LINE_SIZE 64   /**< Cache line size. */
>> +#endif
>
> Jerin Jacob has patch for cleaning of MACRO RTE_CACHE_LINE_SIZE and having 
> CONFIG_RTE_CACHE_LINE_SIZE
>
> in config file. You may need to remove this,once those changes are available 
> in code.
>
Thanks, when that patch applied, I can rebase code.
>> +
>> +/*
>> + * The kernel image of the rte_mbuf struct, with only the relevant fields.
>> + * Padding is necessary to assure the offsets of these fields
>> + */
>> +struct rte_kdp_mbuf {
>> +void *buf_addr __attribute__((__aligned__(RTE_CACHE_LINE_SIZE)));
>> +char pad0[10];
>> +
>> +/**< Start address of data in segment buffer. */
>> +uint16_t data_off;
>> +char pad1[4];
>> +uint64_t ol_flags;  /**< Offload features. */
>
> You are not using ol_flags down in the code. Should this be removed?
>
Can't remove, this struct should match with rte_mbuf

>> +char pad2[4];
>> +
>> +/**< Total pkt len: sum of all segment data_len. */
>> +uint32_t pkt_len;
>> +
>> +/**< Amount of data in segment buffer. */
>> +uint16_t data_len;
>> +
>> +/* fields on second cache line */
>> +char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_SIZE)));
>> +void *pool;
>> +void *next;
>> +};
>> +
>
> Does all structures should have "__rte_cache_aligned" in their declarations? 
> Like other DPDK structs?
>
This is kernel module. Doesn't know about userspace library macros.
>
>> diff --git a/lib/librte_eal/linuxapp/kdp/kdp_dev.h 
>> b/lib/librte_eal/linuxapp/kdp/kdp_dev.h
>> new file mode 100644
>> index 000..52952b4
>> --- /dev/null
>> +++ b/lib/librte_eal/linuxapp/kdp/kdp_dev.h
>>
>> +
>> +#define KDP_ERR(args...) printk(KERN_DEBUG "KDP: Error: " args)
>> +#define KDP_PRINT(args...) printk(KERN_DEBUG "KDP: " args)
>> +
>> +#ifdef RTE_KDP_KO_DEBUG
>> +#define KDP_DBG(args...) printk(KERN_DEBUG "KDP: " args)
>
> Is it good to haveKERN_DEBUG "KDP:Debug: " like Errors?
>
I think extra "Debug" prefix is not required here.

>
>> diff --git a/lib/librte_eal/linuxapp/kdp/kdp_fifo.h 
>> b/lib/librte_eal/linuxapp/kdp/kdp_fifo.h
>> new file mode 100644
>> index 000..a5fe080
>> --- /dev/null
>> +++ b/lib/librte_eal/linuxapp/kdp/kdp_fifo.h
>>
>> +/**
>> + * Adds num elements into the fifo. Return the number actually written
>> + */
>> +static inline unsigned
>> +kdp_fifo_put(struct rte_kdp_fifo *fifo, void **data, unsigned num)
>> +{
>> +unsigned i = 0;
>> +unsigned fifo_write = fifo->write;
>> +unsigned fifo_read = fifo->read;
>> +unsigned new_write = fifo_write;
>> +
>> +for (i = 0; i < num; i++) {
>> +new_write = (new_write + 1) & (fifo->len - 1);
>> +
>> +if (new_write == fifo_read)
>> +break;
>> +fifo->buffer[fifo_write] = data[i];
>> +fifo_write = new_write;
>> +}
>> +fifo->write = fifo_write;
>> +
>> +return i;
>> +}
>
> you can add header for all function declarations inside header file with 
> below format. Same for other header files and functions.
>
> *@Description
>
> *@params
>
> *@Return value
>
This is private header.
>
>> diff --git a/lib/librte_eal/linuxapp/kdp/kdp_misc.c 
>> b/lib/librte_eal/linuxapp/kdp/kdp_misc.c
>> new file mode 100644
>> index 000..d97d1c0
>> --- /dev/null
>> +++ b/lib/librte_eal/linuxapp/kdp/kdp_misc.c
>> +static int
>> +kdp_compat_ioctl(struct inode *inode, unsigned int ioctl_num,
>> +unsigned long ioctl_param)
>> +{
>> +/* 32 bits app on 64 bits OS to be supported later */
>> +KDP_PRINT("Not implemented.\n");
>
> Should this be warning/ERR instead of PRINT?
>
>> diff --git 

[dpdk-dev] [PATCH v2] hash: fix CRC32c computation

[Didier Pallard]

As demonstrated by the following code, CRC32c computation is not valid
when buffer length is not a multiple of 4 bytes:
(Output obtained by code below)

CRC of 1 NULL bytes expected: 0x527d5351
soft: 527d5351
rte accelerated: 48674bc7
rte soft: 48674bc7
CRC of 2 NULL bytes expected: 0xf16177d2
soft: f16177d2
rte accelerated: 48674bc7
rte soft: 48674bc7
CRC of 2x1 NULL bytes expected: 0xf16177d2
soft: f16177d2
rte accelerated: 8c28b28a
rte soft: 8c28b28a
CRC of 3 NULL bytes expected: 0x6064a37a
soft: 6064a37a
rte accelerated: 48674bc7
rte soft: 48674bc7
CRC of 4 NULL bytes expected: 0x48674bc7
soft: 48674bc7
rte accelerated: 48674bc7
rte soft: 48674bc7

Values returned by rte_hash_crc functions does not match the one
computed by a trivial crc32c implementation.

ARM code is not tested.

code showing the problem:

uint8_t null_test[32] = {0};

static uint32_t crc32c_trivial(uint8_t *buffer, uint32_t length, uint32_t crc)
{
uint32_t i, j;
for (i = 0; i < length; ++i)
{
crc = crc ^ buffer[i];
for (j = 0; j < 8; j++)
crc = (crc >> 1) ^ 0x8000 ^ ((~crc & 1) * 0x82f63b78);
}
return crc;
}

void hash_test(void);
void hash_test(void)
{
printf("CRC of 1 nul byte expected: 0x527d5351\n");
printf("soft: %08x\n", crc32c_trivial(null_test, 1, 0));
rte_hash_crc_init_alg();
printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 1, 
0x));
rte_hash_crc_set_alg(CRC32_SW);
printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 1, 0x));

printf("CRC of 2 nul bytes expected: 0xf16177d2\n");
printf("soft: %08x\n", crc32c_trivial(null_test, 2, 0));
rte_hash_crc_init_alg();
printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 2, 
0x));
rte_hash_crc_set_alg(CRC32_SW);
printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 2, 0x));

printf("CRC of 2x1 nul bytes expected: 0xf16177d2\n");
printf("soft: %08x\n", crc32c_trivial(null_test, 1, 
crc32c_trivial(null_test, 1, 0)));
rte_hash_crc_init_alg();
printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 1, 
rte_hash_crc(null_test, 1, 0x)));
rte_hash_crc_set_alg(CRC32_SW);
printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 1, 
rte_hash_crc(null_test, 1, 0x)));

printf("CRC of 3 nul bytes expected: 0x6064a37a\n");
printf("soft: %08x\n", crc32c_trivial(null_test, 3, 0));
rte_hash_crc_init_alg();
printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 3, 
0x));
rte_hash_crc_set_alg(CRC32_SW);
printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 3, 0x));

printf("CRC of 4 nul bytes expected: 0x48674bc7\n");
printf("soft: %08x\n", crc32c_trivial(null_test, 4, 0));
rte_hash_crc_init_alg();
printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 4, 
0x));
rte_hash_crc_set_alg(CRC32_SW);
printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 4, 0x));
}

Signed-off-by: Didier Pallard 
Acked-by: David Marchand 
---

v2: Fix ARM64 compilation issue.

v1: Initial version.

 lib/librte_hash/rte_crc_arm64.h |  64 
 lib/librte_hash/rte_hash_crc.h  | 125 +++-
 2 files changed, 162 insertions(+), 27 deletions(-)

diff --git a/lib/librte_hash/rte_crc_arm64.h b/lib/librte_hash/rte_crc_arm64.h
index 02e26bc..7dd6334 100644
--- a/lib/librte_hash/rte_crc_arm64.h
+++ b/lib/librte_hash/rte_crc_arm64.h
@@ -50,6 +50,28 @@ extern "C" {
 #include 

 static inline uint32_t
+crc32c_arm64_u8(uint8_t data, uint32_t init_val)
+{
+   asm(".arch armv8-a+crc");
+   __asm__ volatile(
+   "crc32cb %w[crc], %w[crc], %w[value]"
+   : [crc] "+r" (init_val)
+   : [value] "r" (data));
+   return init_val;
+}
+
+static inline uint32_t
+crc32c_arm64_u16(uint16_t data, uint32_t init_val)
+{
+   asm(".arch armv8-a+crc");
+   __asm__ volatile(
+   "crc32ch %w[crc], %w[crc], %w[value]"
+   : [crc] "+r" (init_val)
+   : [value] "r" (data));
+   return init_val;
+}
+
+static inline uint32_t
 crc32c_arm64_u32(uint32_t data, uint32_t init_val)
 {
asm(".arch armv8-a+crc");
@@ -103,6 +125,48 @@ rte_hash_crc_init_alg(void)
 }

 /**
+ * Use single crc32 instruction to perform a hash on a 1 byte value.
+ * Fall back to software crc32 implementation in case arm64 crc intrinsics is
+ * not supported
+ *
+ * @param data
+ *   Data to perform hash on.
+ * @param init_val
+ *   Value to initialise hash generator.
+ * @return
+ *   32bit calculated hash value.
+ */
+static inline uint32_t
+rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
+{
+  

[dpdk-dev] [PATCH v8 4/4] eal/linux: vfio: add pci ioport support

[David Marchand]

On Mon, Feb 8, 2016 at 3:13 PM, Burakov, Anatoly
 wrote:
>> Include vfio map/rd/wr support for pci ioport.
>>
>> Signed-off-by: Santosh Shukla 
>> ---
>> v7->v8:
>> - Remove rte_pci_ioport malloc and rte_free()/unmap() func from v7.
>> - removed umap from git header.
>>
>>  lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   36 ++---
>> ---
>>  1 file changed, 24 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>> b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>> index 4832313..9571ed8 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>> @@ -74,6 +74,7 @@ EAL_REGISTER_TAILQ(rte_vfio_tailq)
>>  #define VFIO_GROUP_FMT "/dev/vfio/%u"
>>  #define VFIO_NOIOMMU_GROUP_FMT "/dev/vfio/noiommu-%u"
>>  #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
>> +#define VFIO_GET_REGION_IDX(x) (x >> 40)
>>
>>  /* per-process VFIO config */
>>  static struct vfio_config vfio_cfg;
>> @@ -999,30 +1000,41 @@ int
>>  pci_vfio_ioport_map(struct rte_pci_device *dev, int bar,
>>   struct rte_pci_ioport *p)
>>  {
>> - RTE_SET_USED(dev);
>> - RTE_SET_USED(bar);
>> - RTE_SET_USED(p);
>> - return -1;
>> + if (bar < VFIO_PCI_BAR0_REGION_INDEX ||
>> + bar > VFIO_PCI_BAR5_REGION_INDEX) {
>> + RTE_LOG(ERR, EAL, "invalid bar (%d)!\n", bar);
>> + return -1;
>> + }
>> +
>> + p->dev = dev;
>> + p->offset = VFIO_GET_REGION_ADDR(bar);
>> + return 0;
>>  }
>>

I still think we don't need this p->dev = dev.
But that's not important.


> Acked-by: Anatoly Burakov 

Acked-by: David Marchand 


-- 
David Marchand

[dpdk-dev] [PATCH 2/9] pci: register all pdev as pci drivers

[David Marchand]

On Mon, Feb 8, 2016 at 12:03 PM, Jan Viktorin  
wrote:
> On Fri, 29 Jan 2016 15:08:29 +0100
> David Marchand  wrote:
>
>> pdev drivers are actually pci drivers.
>> Wrappers for ethdev and crypto pci drivers, that assume a 1 to 1
>> association between pci device and upper device, have been added so that
>> current drivers are not impacted.
>
> It took me a while to find out what's going on in this patch. I could
> see several not-so-related changes down the e-mail. I'd suggest to split
> it this way:
>
> 1) separate coding style fixes
> 2) rename init/uninit to probe/remove (preserve the 'static' there)
> 3) remove rte_eth_driver_register invocations
> 4) separate VDEV and PDEV for cryptodev
> 5) play with the NEXT_ABI (remove those 'static' keywords?)
>
> A more detailed commit log would help too. But this would
> be automatically solved by the separation, I think.

Yes, I rushed for this patchset to still be in the proposal window ...
Sorry, I will split for next version.


> See comments below...

Globally, all my answers are "Yes, will do and it will be easier with
smaller patches".
Just added some comments where appropriate.


>> diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c 
>> b/drivers/crypto/qat/rte_qat_cryptodev.c
>> index e500c1e..6853aee 100644
>> --- a/drivers/crypto/qat/rte_qat_cryptodev.c
>> +++ b/drivers/crypto/qat/rte_qat_cryptodev.c
>> @@ -113,10 +113,12 @@ crypto_qat_dev_init(__attribute__((unused)) struct 
>> rte_cryptodev_driver *crypto_
>>  }
>>
>>  static struct rte_cryptodev_driver rte_qat_pmd = {
>> - {
>> + .pci_drv = {
>
> I believe that you are making the driver independent on the exact
> location of the pci_drv member in the rte_cryptodev_drivers struct. Is
> it true? Why is that important?

Yes, plus all other drivers are doing this, there were little
exception to this convention, so I just aligned here.


>>   .name = "rte_qat_pmd",
>>   .id_table = pci_id_qat_map,
>>   .drv_flags = RTE_PCI_DRV_NEED_MAPPING,
>> + .devinit = rte_cryptodev_pci_probe,
>> + .devuninit = rte_cryptodev_pci_remove,
>>   },
>>   .cryptodev_init = crypto_qat_dev_init,
>>   .dev_private_size = sizeof(struct qat_pmd_private),
>> @@ -126,7 +128,8 @@ static int
>>  rte_qat_pmd_init(const char *name __rte_unused, const char *params 
>> __rte_unused)
>>  {
>>   PMD_INIT_FUNC_TRACE();
>> - return rte_cryptodev_pmd_driver_register(_qat_pmd, PMD_PDEV);
>> + rte_eal_pci_register(_qat_pmd.pci_drv);
>> + return 0;
>
> So, I finally discovered that this change somehow separates the PCI
> (PDEV) and VDEV initialization. Is that correct?

Yes.
I will separate crypto updates from netdev updates since crypto
framework has a slight different way of initialising.


>> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
>> index 756b234..17e4f4d 100644
>> --- a/lib/librte_ether/rte_ethdev.c
>> +++ b/lib/librte_ether/rte_ethdev.c
>> @@ -239,9 +239,9 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
>>   return 0;
>>  }
>>
>> -static int
>> -rte_eth_dev_init(struct rte_pci_driver *pci_drv,
>> -  struct rte_pci_device *pci_dev)
>> +int
>> +rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
>> +   struct rte_pci_device *pci_dev)
>
> As I've suggested at the beginning, what about "first just rename then
> make it public (non-static)"? I don't see the connection between the
> rename and the NEXT_ABI conditional.

I don't think we need NEXT_ABI checks here.
I am not breaking anything here, just adding a new symbol.

I will introduce this new symbol, then convert all existing
pdev/eth_driver to pdev/pci_driver in a second patch.


-- 
David Marchand

[dpdk-dev] [PATCH] mlx4: fix unneeded function error with clang v3.6

[Adrien Mazarguil]

On Mon, Feb 08, 2016 at 10:11:49PM +, Bruce Richardson wrote:
> When compiling with clang 3.6, the mlx4 driver gives the following error
> message about an unneeded function.
> 
>   CC mlx4.o
> .../drivers/net/mlx4/mlx4.c:136:20: fatal error: function
>   'wr_id_t_check' is not needed and will not be emitted
> [-Wunneeded-internal-declaration]
> static inline void wr_id_t_check(void)
>^
> 1 error generated.
> 
> The function is to compile-time check the size of wr_id_t, so use
> the standard DPDK BUILD_BUG_ON macro to do so in the init function
> instead.
> 
> Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
> 
> Signed-off-by: Bruce Richardson 

Thanks.

Acked-by: Adrien Mazarguil 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v2 0/9] pci cleanup and blacklist rework

[David Marchand]

Hello Jan,

On Mon, Feb 8, 2016 at 2:31 PM, Jan Viktorin  wrote:
> I am confused a bit. I started to review the "[PATCH 0/9] prepare for 
> rte_device
> / rte_driver" series and then I've noticed there are 2 patch series having 
> "pci:
> no need for dynamic tailq init" patch there. But then, there is this v2 that 
> does
> not have this patch. What is the right one? What should I look at. Is related?

I splitted this initial series, because I want to dissociate the work
trying to get to rte_driver/rte_device from other work that modifies
pci code (blacklist rework and "autobind").

I think you want to look at [1], but, if you want the global picture,
first apply [1], then [2] ([2] is the v2 patchset which supersedes the
initial patchset that had this "pci:
no need for dynamic tailq init" patch in it).

[1] http://dpdk.org/ml/archives/dev/2016-January/032387.html
[2] http://dpdk.org/ml/archives/dev/2016-January/032398.html


Regards,
-- 
David Marchand

[dpdk-dev] [PATCH] af_packet: make the device detachable

[Iremonger, Bernard]

 Hi Wojciech



> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wojciech Zmuda
> > Sent: Tuesday, January 5, 2016 2:05 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] af_packet: make the device detachable
> >
> > Fix memory leak when detaching virtual device. Set dev_flags to
> > RTE_ETH_DEV_DETACHABLE and implement pmd_af_packet_drv.uninit
> method.
> > Copy device name to ethdev->data to make it compatibile with
> 
> Typo, compatibile should be compatible.
> 
> > rte_eth_dev_allocated().
> >
> > Signed-off-by: Wojciech Zmuda 
> > ---
> >  drivers/net/af_packet/rte_eth_af_packet.c | 29
> > -
> >  1 file changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
> > b/drivers/net/af_packet/rte_eth_af_packet.c
> > index 767f36b..7ef65ff 100644
> > --- a/drivers/net/af_packet/rte_eth_af_packet.c
> > +++ b/drivers/net/af_packet/rte_eth_af_packet.c
> > @@ -667,11 +667,13 @@ rte_pmd_init_internals(const char *name,
> > data->nb_tx_queues = (uint16_t)nb_queues;
> > data->dev_link = pmd_link;
> > data->mac_addrs = &(*internals)->eth_addr;
> > +   strncpy(data->name,
> > +   (*eth_dev)->data->name, strlen((*eth_dev)->data-
> > >name));
> >
> > (*eth_dev)->data = data;
> > (*eth_dev)->dev_ops = 
> > (*eth_dev)->driver = NULL;
> > -   (*eth_dev)->data->dev_flags = 0;
> > +   (*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
> > (*eth_dev)->data->drv_name = drivername;
> > (*eth_dev)->data->kdrv = RTE_KDRV_NONE;
> > (*eth_dev)->data->numa_node = numa_node; @@ -836,10 +838,35
> @@ exit:
> > return ret;
> >  }
> >
> > +static int
> > +rte_pmd_af_packet_devuninit(const char *name) {
> > +   struct rte_eth_dev *eth_dev = NULL;
> > +
> > +   RTE_LOG(INFO, PMD, "Closing AF_PACKET ethdev on numa socket
> > %u\n",
> > +   rte_socket_id());
> > +
> > +   if (name == NULL)
> > +   return -1;
> > +
> > +   /* reserve an ethdev entry */
> 
> Above comment should be   /* find the ethdev entry */
> 
> > +   eth_dev = rte_eth_dev_allocated(name);
> > +   if (eth_dev == NULL)
> > +   return -1;
> > +
> 
> In rte_pmd_init_internals() memory is allocated for rx and tx queues this
> should also be freed.
> 
> Line 606: rx_queue->rd = rte_zmalloc_socket(name, rdsize, 0, numa_node);
> Line 620:tx_queue->rd = rte_zmalloc_socket(name, rdsize, 0, numa_node);
> 
>   rte_free((*internals)->rx_queue[q].rd);
>   rte_free((*internals)->tx_queue[q].rd);
> 
> > +   rte_free(eth_dev->data->dev_private);
> > +   rte_free(eth_dev->data);
> > +
> > +   rte_eth_dev_release_port(eth_dev);
> > +
> > +   return 0;
> > +}
> > +
> >  static struct rte_driver pmd_af_packet_drv = {
> > .name = "eth_af_packet",
> > .type = PMD_VDEV,
> > .init = rte_pmd_af_packet_devinit,
> > +   .uninit = rte_pmd_af_packet_devuninit,
> >  };
> >
> >  PMD_REGISTER_DRIVER(pmd_af_packet_drv);
> > --
> > 1.9.1

Forgot to mention that there should probably be and entry in the 2.3 release 
notes, new features section, for this.

Regards,

Bernard.

[dpdk-dev] [PATCH v2 4/4] virtio: use pci ioport api

[David Marchand]

On Tue, Feb 9, 2016 at 4:52 AM, Tetsuya Mukawa  wrote:
> On 2016/02/07 16:48, David Marchand wrote:
> One more legacy_virtio_resource_init() is defined like below.
>
> #ifdef RTE_EXEC_ENV_LINUXAPP
> 
> #else
> 
> static int
> legacy_virtio_resource_init(struct rte_pci_device *pci_dev __rte_unused)
> {
> /* no setup required */
> return 0;
> }
> #endif
>
> Should we change this also?

Yes, I noticed this while doing the patches but forgot to update ...
Thanks.

In the end, I think that we end up with common code in this case for
both bsd and linux.

The only thing remaining in virtio that depends on "#ifdef os" is the
msix detection.
I do not have time to look at this, so I suppose this will have to wait.


-- 
David Marchand