[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?

[Matthew Hall]

I had all kinds of very weird failures using the 64 bit clang target related to 
missing CPUFLAGS. For a while I hacked around it by adding a whole ton of -D 
for missing RTE CPUFLAGS macros. But then some further DPDK changes came and 
caused clang bud failures I could not debug and I had to give up and switch 
back to GCC. While I can't confirm this exact error I can 100% confirm very 
similar errors using Ubuntu 15.10 and the included clang with it. 

I think the general problem is that there isn't much in the way of regression 
testing for the build on this compile target. So unless it breaks for just the 
right expert at the right time nobody finds it and tracks it down. 

Matthew. 

On Feb 15, 2016, at 2:14 AM, Van Haaren, Harry  
wrote:

>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
>> In file included from
>> /home/marc/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:42:
>> /home/marc/dpdk/x86_64-native-linuxapp-clang/include/rte_memcpy.h:870:2:
>> error: implicit declaration of function '_mm_alignr_epi8' is invalid in
>> C99
>>  [-Werror,-Wimplicit-function-declaration]
>>MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
>>^
> 
> Can reproduce this here, Ubuntu clang version 3.6.2-1 
> (tags/RELEASE_362/final) (based on LLVM 3.6.2)
> This issue seems to be caused by a lack of intrinsic CFLAGS, clang and GCC 
> build output with make V=1 on the same machine (unnecessary output stripped):
> 
> 
> clang -Wp,-MD,./.eal_pci.o.d.tmp -m64 -pthread  -march=native 
> -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 
> -DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2
> 
> 
> gcc -Wp,-MD,./.eal_pci.o.d.tmp -m64 -pthread -fPIC  -march=native 
> -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 
> -DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3 
> -DRTE_MACHINE_CPUFLAG_SSE4_1 -DRTE_MACHINE_CPUFLAG_SSE4_2 
> -DRTE_MACHINE_CPUFLAG_AES -DRTE_MACHINE_CPUFLAG_PCLMULQDQ 
> -DRTE_MACHINE_CPUFLAG_AVX -DRTE_MACHINE_CPUFLAG_RDRAND 
> -DRTE_MACHINE_CPUFLAG_FSGSBASE -DRTE_MACHINE_CPUFLAG_F16C 
> -DRTE_MACHINE_CPUFLAG_AVX2 
> -DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSE3,RTE_CPUFLAG_SSSE3,RTE_CPUFLAG_SSE4_1,RTE_CPUFLAG_SSE4_2,RTE_CPUFLAG_AES,RTE_CPUFLAG_PCLMULQDQ,RTE_CPUFLAG_AVX,RTE_CPUFLAG_RDRAND,RTE_CPUFLAG_FSGSBASE,RTE_CPUFLAG_F16C,RTE_CPUFLAG_AVX2
> 
> 
> There is no copy-paste error above: the clang intrinsic CFLAGS is much 
> shorter than GCC.
> 
> Strangely, this issue also exists when building i686 gcc target *on a 32bit 
> host/VM*. Git bisect shows that this issue exists on 32bit target / 32bit 
> host since commit 9144d6b, which optimized eal/x86 rte_memcpy.
> 
> It looks like the build-system is not correctly identifying the intrinsics to 
> build with. I've had a look through mk/toolchain/clang/*  and 
> mk/rte.cpuflags.mk  but haven't seen anything I think could be the cause...
> 
> Perhaps somebody with familiarity with the build system could take a look?
> 
> -Harry

[dpdk-dev] [PATCH v2 00/11] update ixgbe base driver

[Bruce Richardson]

On Sun, Feb 14, 2016 at 04:54:55PM +0800, Wenzhuo Lu wrote:
> *add x550em_a device support
> *add x550em_x V2 device support
> *sw-firmware sync for resource sharing
> *set VF mac addr only when acked by PF
> *ignore manageability for phy power on
> *add register definition for SGMII busy
> *fix setting flow dir flag twice
> *set MDIO speed after MAC reset
> *abstract out link read/write ops
> 
> V2:
>  Rework the tittles and comments.
>  Split the release note update to each patch.
> 
> Wenzhuo Lu (11):
>   ixgbe/base: add x550em_a device support
>   ixgbe/base: add x550em_x V2 device support
>   ixgbe/base: sw-firmware sync for resource sharing
>   ixgbe/base: set VF mac addr only when acked by PF
>   ixgbe/base: ignore manageability for phy power on
>   ixgbe/base: add register definition for SGMII busy
>   ixgbe/base: fix setting flow dir flag twice
>   ixgbe/base: set MDIO speed after MAC reset
>   ixgbe/base: abstract out link read/write ops
>   ixgbe/base: update readme
>   ixgbe: support new devices and mac types
>
Base code update applied to dpdk-next-net/rel_16_04

Thanks,
/Bruce

[dpdk-dev] [PATCH] ENIC PMD receive path performance improvements.

[johndale]

- Simplify and reduce code path length of receive function.
- Put all receive stuff in enic_rx.c
- Reduce the number of posted_index updates (pay attention to rx_free_thresh)
- Remove the container structure around the rq mbuf ring
- Prefetch next Mbuf and descriptors while processing the current one
- Lookup table for converting CQ flags to mbuf flags.

Signed-off-by: johndale 
---
 drivers/net/enic/Makefile   |   1 +
 drivers/net/enic/base/vnic_rq.c |  99 ++
 drivers/net/enic/base/vnic_rq.h | 147 +-
 drivers/net/enic/enic.h |  16 +-
 drivers/net/enic/enic_ethdev.c  |  21 +-
 drivers/net/enic/enic_main.c| 319 +--
 drivers/net/enic/enic_res.h |  16 +-
 drivers/net/enic/enic_rx.c  | 413 
 8 files changed, 555 insertions(+), 477 deletions(-)
 create mode 100644 drivers/net/enic/enic_rx.c

diff --git a/drivers/net/enic/Makefile b/drivers/net/enic/Makefile
index f0ee093..f316274 100644
--- a/drivers/net/enic/Makefile
+++ b/drivers/net/enic/Makefile
@@ -53,6 +53,7 @@ VPATH += $(SRCDIR)/src
 #
 SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_ethdev.c
 SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_main.c
+SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_rx.c
 SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_clsf.c
 SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_res.c
 SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += base/vnic_cq.c
diff --git a/drivers/net/enic/base/vnic_rq.c b/drivers/net/enic/base/vnic_rq.c
index 1441604..cb62c5e 100644
--- a/drivers/net/enic/base/vnic_rq.c
+++ b/drivers/net/enic/base/vnic_rq.c
@@ -35,77 +35,21 @@
 #include "vnic_dev.h"
 #include "vnic_rq.h"

-static int vnic_rq_alloc_bufs(struct vnic_rq *rq)
-{
-   struct vnic_rq_buf *buf;
-   unsigned int i, j, count = rq->ring.desc_count;
-   unsigned int blks = VNIC_RQ_BUF_BLKS_NEEDED(count);
-
-   for (i = 0; i < blks; i++) {
-   rq->bufs[i] = kzalloc(VNIC_RQ_BUF_BLK_SZ(count), GFP_ATOMIC);
-   if (!rq->bufs[i])
-   return -ENOMEM;
-   }
-
-   for (i = 0; i < blks; i++) {
-   buf = rq->bufs[i];
-   for (j = 0; j < VNIC_RQ_BUF_BLK_ENTRIES(count); j++) {
-   buf->index = i * VNIC_RQ_BUF_BLK_ENTRIES(count) + j;
-   buf->desc = (u8 *)rq->ring.descs +
-   rq->ring.desc_size * buf->index;
-   if (buf->index + 1 == count) {
-   buf->next = rq->bufs[0];
-   break;
-   } else if (j + 1 == VNIC_RQ_BUF_BLK_ENTRIES(count)) {
-   buf->next = rq->bufs[i + 1];
-   } else {
-   buf->next = buf + 1;
-   buf++;
-   }
-   }
-   }
-
-   rq->to_use = rq->to_clean = rq->bufs[0];
-
-   return 0;
-}
-
-int vnic_rq_mem_size(struct vnic_rq *rq, unsigned int desc_count,
-   unsigned int desc_size)
-{
-   int mem_size = 0;
-
-   mem_size += vnic_dev_desc_ring_size(>ring, desc_count, desc_size);
-
-   mem_size += VNIC_RQ_BUF_BLKS_NEEDED(rq->ring.desc_count) *
-   VNIC_RQ_BUF_BLK_SZ(rq->ring.desc_count);
-
-   return mem_size;
-}
-
 void vnic_rq_free(struct vnic_rq *rq)
 {
struct vnic_dev *vdev;
-   unsigned int i;

vdev = rq->vdev;

vnic_dev_free_desc_ring(vdev, >ring);

-   for (i = 0; i < VNIC_RQ_BUF_BLKS_MAX; i++) {
-   if (rq->bufs[i]) {
-   kfree(rq->bufs[i]);
-   rq->bufs[i] = NULL;
-   }
-   }
-
rq->ctrl = NULL;
 }

 int vnic_rq_alloc(struct vnic_dev *vdev, struct vnic_rq *rq, unsigned int 
index,
unsigned int desc_count, unsigned int desc_size)
 {
-   int err;
+   int rc;
char res_name[NAME_MAX];
static int instance;

@@ -121,18 +65,9 @@ int vnic_rq_alloc(struct vnic_dev *vdev, struct vnic_rq 
*rq, unsigned int index,
vnic_rq_disable(rq);

snprintf(res_name, sizeof(res_name), "%d-rq-%d", instance++, index);
-   err = vnic_dev_alloc_desc_ring(vdev, >ring, desc_count, desc_size,
+   rc = vnic_dev_alloc_desc_ring(vdev, >ring, desc_count, desc_size,
rq->socket_id, res_name);
-   if (err)
-   return err;
-
-   err = vnic_rq_alloc_bufs(rq);
-   if (err) {
-   vnic_rq_free(rq);
-   return err;
-   }
-
-   return 0;
+   return rc;
 }

 void vnic_rq_init_start(struct vnic_rq *rq, unsigned int cq_index,
@@ -154,9 +89,6 @@ void vnic_rq_init_start(struct vnic_rq *rq, unsigned int 
cq_index,
iowrite32(fetch_index, >ctrl->fetch_index);
iowrite32(posted_index, >ctrl->posted_index);

-   rq->to_use = rq->to_clean =
-   >bufs[fetch_index / VNIC_RQ_BUF_BLK_ENTRIES(count)]
-   [fetch_index 

[dpdk-dev] [PATCH] Enic PMD Rx performance improvements

[johndale]

This is a rewrite of the receive path of the Enic PMD to simplify the
code and improve packet rate. Sorry I couldn't figure a way to organize
it as a series of patches, so I'm submitting it as a single patch.
thanks,
john

johndale (1):
  ENIC PMD receive path performance improvements.

 drivers/net/enic/Makefile   |   1 +
 drivers/net/enic/base/vnic_rq.c |  99 ++
 drivers/net/enic/base/vnic_rq.h | 147 +-
 drivers/net/enic/enic.h |  16 +-
 drivers/net/enic/enic_ethdev.c  |  21 +-
 drivers/net/enic/enic_main.c| 319 +--
 drivers/net/enic/enic_res.h |  16 +-
 drivers/net/enic/enic_rx.c  | 413 
 8 files changed, 555 insertions(+), 477 deletions(-)
 create mode 100644 drivers/net/enic/enic_rx.c

-- 
2.7.0

[dpdk-dev] TX performance regression caused by the mbuf cachline split

[Paul Emmerich]

Hi,

here's a kind of late follow-up. I've only recently found the need 
(mostly for the better support of XL710 NICs (which I still dislike but 
people are using them...)) to seriously address DPDK 2.x support in MoonGen.

On 13.05.15 11:03, Ananyev, Konstantin wrote:
> Before start to discuss your findings, there is one thing in your test app 
> that looks strange to me:
> You use BATCH_SIZE==64 for TX packets, but your mempool cache_size==32.
> This is not really a good choice, as it means that for each iteration your 
> mempool cache will be exhausted,
> and you'll endup doing ring_dequeue().
> I'd suggest you use something like ' 2 * BATCH_SIZE' for mempools cache size,
> that should improve your numbers (at least it did to me).

Thanks for pointing that out. However, my real app did not have this bug 
and I also saw the performance improvement there.

> Though, I suppose that scenario might be improved without manual 'prefetch' - 
> by reordering code a bit.
> Below are 2 small patches, that introduce rte_pktmbuf_bulk_alloc() and 
> modifies your test app to use it.
> Could you give it a try and see would it help to close a gap between 1.7.1 
> and 2.0?
> I don't have box with the same off-hand, but on my IVB box results are quite 
> promising:
> on 1.2 GHz for simple_tx there is practically no difference in results 
> (-0.33%),
> for full_tx the drop reduced to 2%.
> That's comparing DPDK1.7.1+testpapp with cache_size=2*batch_size vs
> latest DPDK+ testpapp with cache_size=2*batch_size+bulk_alloc.

The bulk_alloc patch is great and helps. I'd love to see such a function 
in DPDK.

I agree that this is a better solution than prefetching. I also can't 
see a difference with/without prefetching when using bulk alloc.


  Paul

[dpdk-dev] [PATCH v8 2/4] ethdev: Fill speed capability bitmaps in the PMDs

[Rahul Lakkireddy]

Hi Marc,

On Sunday, February 02/14/16, 2016 at 23:17:37 +0100, Marc Sune wrote:
> Added speed capabilities to all pmds supporting physical NICs:
> 
> * e1000
> * ixgbe
> * i40
> * bnx2x
> * cxgbe
> * mlx4
> * mlx5
> * nfp
> * fm10k
> 
> Signed-off-by: Marc Sune 
> ---
>  drivers/net/bnx2x/bnx2x_ethdev.c |  1 +
>  drivers/net/cxgbe/cxgbe_ethdev.c |  1 +
>  drivers/net/e1000/em_ethdev.c|  6 ++
>  drivers/net/e1000/igb_ethdev.c   |  6 ++
>  drivers/net/fm10k/fm10k_ethdev.c |  4 
>  drivers/net/i40e/i40e_ethdev.c   |  9 +
>  drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
>  drivers/net/mlx4/mlx4.c  |  4 
>  drivers/net/mlx5/mlx5_ethdev.c   |  5 +
>  drivers/net/nfp/nfp_net.c|  2 ++
>  10 files changed, 48 insertions(+)
> 

[...]

> diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c 
> b/drivers/net/cxgbe/cxgbe_ethdev.c
> index 97ef152..203e119 100644
> --- a/drivers/net/cxgbe/cxgbe_ethdev.c
> +++ b/drivers/net/cxgbe/cxgbe_ethdev.c
> @@ -171,6 +171,7 @@ static void cxgbe_dev_info_get(struct rte_eth_dev 
> *eth_dev,
>  
>   device_info->rx_desc_lim = cxgbe_desc_lim;
>   device_info->tx_desc_lim = cxgbe_desc_lim;
> + device_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
>  }
>  

Not all Chelsio NICs support _both_ 10G and 40G speed capabilities on a
single card.  You can query pi->link_cfg.supported to get the supported
speeds.  Check out print_port_info() in cxgbe_main.c to help you fill
in your speed capabilities for Chelsio NICs.

Thanks,
Rahul

[dpdk-dev] Per-queue bandwidth limit on XL710 NICs?

[Paul Emmerich]

Hi,

I'm using the per-queue rate control feature found in ixgbe-style NICs 
(rte_eth_set_queue_rate_limit) quite extensively in my packet generator 
MoonGen.

I've read some parts of the XL710 datasheet and I guess it should be 
possible to implement this for this chip. I think there are two ways to 
achieves this:

1) Limiting the main VSI and thus the whole port by calling 
i40e_aq_config_vsi_bw_limit() in the driver works fine. Thus, creating 
multiple VSIs for each rate-controlled queue would be a possible solution.
I'm not sure if that works without major modifications to the driver. I 
probably need a VEB for that which currently isn't supported in the driver.

2) Use multiple TCs for the used VSI. That would limit us to 8 rate 
limits but that would be okay. Probably the simpler solution.

Can anyone with more insight into the XL710 hardware give me some hints 
on implementing this?


  Paul

[dpdk-dev] [PATCH v8 2/4] ethdev: Fill speed capability bitmaps in the PMDs

[Marc]

Rahul, Neilo, Jing D, et al

On 15 February 2016 at 15:43, Rahul Lakkireddy  wrote:

> Hi Marc,
>
> On Sunday, February 02/14/16, 2016 at 23:17:37 +0100, Marc Sune wrote:
> > Added speed capabilities to all pmds supporting physical NICs:
> >
> > * e1000
> > * ixgbe
> > * i40
> > * bnx2x
> > * cxgbe
> > * mlx4
> > * mlx5
> > * nfp
> > * fm10k
> >
> > Signed-off-by: Marc Sune 
> > ---
> >  drivers/net/bnx2x/bnx2x_ethdev.c |  1 +
> >  drivers/net/cxgbe/cxgbe_ethdev.c |  1 +
> >  drivers/net/e1000/em_ethdev.c|  6 ++
> >  drivers/net/e1000/igb_ethdev.c   |  6 ++
> >  drivers/net/fm10k/fm10k_ethdev.c |  4 
> >  drivers/net/i40e/i40e_ethdev.c   |  9 +
> >  drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
> >  drivers/net/mlx4/mlx4.c  |  4 
> >  drivers/net/mlx5/mlx5_ethdev.c   |  5 +
> >  drivers/net/nfp/nfp_net.c|  2 ++
> >  10 files changed, 48 insertions(+)
> >
>
> [...]
>
> > diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c
> b/drivers/net/cxgbe/cxgbe_ethdev.c
> > index 97ef152..203e119 100644
> > --- a/drivers/net/cxgbe/cxgbe_ethdev.c
> > +++ b/drivers/net/cxgbe/cxgbe_ethdev.c
> > @@ -171,6 +171,7 @@ static void cxgbe_dev_info_get(struct rte_eth_dev
> *eth_dev,
> >
> >   device_info->rx_desc_lim = cxgbe_desc_lim;
> >   device_info->tx_desc_lim = cxgbe_desc_lim;
> > + device_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
> >  }
> >
>
> Not all Chelsio NICs support _both_ 10G and 40G speed capabilities on a
> single card.  You can query pi->link_cfg.supported to get the supported
> speeds.  Check out print_port_info() in cxgbe_main.c to help you fill
> in your speed capabilities for Chelsio NICs.
>

This patch series has been long delayed, and I've been requested to merge
it for next release if possible. Most of the feedback has been coming late
(not for cxgbe, which is introduced in this new v8, but it did for most of
the rest of drivers).

My proposal is simply to add in this patch series ALL possible speeds for
that driver. Other patches can be later submitted to adjust speeds
according to specific device model.

marc


>
> Thanks,
> Rahul
>

[dpdk-dev] vm_power_manager uses channel_commands.h which is not placed in installed copy of DPDK

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, February 15, 2016 1:21 PM
> To: Panu Matilainen ; Carew, Alan
> ; De Lara Guarch, Pablo
> 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] vm_power_manager uses channel_commands.h which is
> not placed in installed copy of DPDK
> 
>
> > I can certainly submit a patch to disable it by default in the configs
> > (seems reasonable unmaintained code would default to off) and add a
> > deprecation note along the lines of "if no maintainer steps up, this
> > code will be removed in 16.07" if you like :)
> 
> Before sending such notice, we should wait for comments of some known
> contributors to librte_power.
> Alan, Pablo, what is your opinion?

Hi,

We will look from a maintainer from the Intel DPDK team and try resolve the
open issues.

Regards,

John

[dpdk-dev] [PATCH 3/3] i40e: use crc checksum disable flag

[Paul Emmerich]

Signed-off-by: Paul Emmerich 
---
 drivers/net/i40e/i40e_rxtx.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 40cffc1..52f7955 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -799,6 +799,11 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
*td_offset |= (tx_offload.l2_len >> 1)
<< I40E_TX_DESC_LENGTH_MACLEN_SHIFT;

+   /* Enable L2 checksum offload */
+   if (!(ol_flags & PKT_TX_NO_CRC_CSUM))
+   *td_cmd |= I40E_TX_DESC_CMD_ICRC;
+
+
/* Enable L3 checksum offloads */
if (ol_flags & PKT_TX_IP_CKSUM) {
*td_cmd |= I40E_TX_DESC_CMD_IIPT_IPV4_CSUM;
@@ -1613,9 +1618,6 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
I40E_TX_FLAG_L2TAG1_SHIFT;
}

-   /* Always enable CRC offload insertion */
-   td_cmd |= I40E_TX_DESC_CMD_ICRC;
-
/* Enable checksum offloading */
cd_tunneling_params = 0;
if (ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK) {
-- 
1.9.1

[dpdk-dev] [PATCH 2/3] ixgbe: use crc checksum disable flag

[Paul Emmerich]

Signed-off-by: Paul Emmerich 
---
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 57c9430..800e224 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -730,8 +730,9 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
 * are only set in the last Data Descriptor:
 *   - IXGBE_TXD_CMD_RS
 */
-   cmd_type_len = IXGBE_ADVTXD_DTYP_DATA |
-   IXGBE_ADVTXD_DCMD_IFCS | IXGBE_ADVTXD_DCMD_DEXT;
+   cmd_type_len = IXGBE_ADVTXD_DTYP_DATA | IXGBE_ADVTXD_DCMD_DEXT;
+   if (!(ol_flags & PKT_TX_NO_CRC_CSUM))
+   cmd_type_len |= IXGBE_ADVTXD_DCMD_IFCS;

 #ifdef RTE_LIBRTE_IEEE1588
if (ol_flags & PKT_TX_IEEE1588_TMST)
-- 
1.9.1

[dpdk-dev] [PATCH 1/3] add tx crc disable flag

[Paul Emmerich]

Signed-off-by: Paul Emmerich 
---
 lib/librte_mbuf/rte_mbuf.c | 1 +
 lib/librte_mbuf/rte_mbuf.h | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index f506517..744fb4e 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -270,6 +270,7 @@ const char *rte_get_rx_ol_flag_name(uint64_t mask)
 const char *rte_get_tx_ol_flag_name(uint64_t mask)
 {
switch (mask) {
+   case PKT_TX_NO_CRC_CSUM: return "PKT_TX_NO_CRC_CSUM";
case PKT_TX_VLAN_PKT: return "PKT_TX_VLAN_PKT";
case PKT_TX_IP_CKSUM: return "PKT_TX_IP_CKSUM";
case PKT_TX_TCP_CKSUM: return "PKT_TX_TCP_CKSUM";
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index ab6de67..096d84a 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -106,6 +106,12 @@ extern "C" {
 /* add new TX flags here */

 /**
+ * Disable CRC checksum offload
+ */
+#define PKT_TX_NO_CRC_CSUM   (1ULL << 49)
+
+
+/**
  * TCP segmentation offload. To enable this offload feature for a
  * packet to be transmitted on hardware supporting TSO:
  *  - set the PKT_TX_TCP_SEG flag in mbuf->ol_flags (this flag implies
-- 
1.9.1

[dpdk-dev] [PATCH 0/3] add flag to disable CRC checksum offloading

[Paul Emmerich]

This patch adds a new tx checksum offloading flag: PKT_TX_NO_CRC_CSUM.
This allows disabling CRC checksum offloading on a per-packet basis.
Doing this can be useful if you want to send out invalid packets on
purpose, e.g. in a packet generator/test framework.


Paul Emmerich (3):
  add tx crc disable flag
  ixgbe: use crc checksum disable flag
  i40e: use crc checksum disable flag

[dpdk-dev] [PATCH v2] aesni_mb: strict-aliasing rule compilation fix

[Declan Doherty]

Fixes: 924e84f87306 ("aesni_mb: add driver for multi buffer based crypto")

When compiling the AESNI_MB PMD with GCC 4.4.7 on Centos 6.7 a "dereferencing
pointer ?obj_p? does break strict-aliasing rules" warning occurs in the
get_session() function.

Signed-off-by: Declan Doherty 
---
Adding "Fixes" details to patch

 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 15 +--
 1 file changed, 9 insertions(+), 6 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..18ce176 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -299,7 +299,7 @@ aesni_mb_set_session_parameters(const struct aesni_mb_ops 
*mb_ops,
 static struct aesni_mb_session *
 get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *crypto_op)
 {
-   struct aesni_mb_session *sess;
+   struct aesni_mb_session *sess = NULL;

if (crypto_op->type == RTE_CRYPTO_OP_WITH_SESSION) {
if (unlikely(crypto_op->session->type !=
@@ -308,16 +308,19 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op 
*crypto_op)

sess = (struct aesni_mb_session *)crypto_op->session->_private;
} else  {
-   struct rte_cryptodev_session *c_sess = NULL;
+   void *_sess = NULL;

-   if (rte_mempool_get(qp->sess_mp, (void **)_sess))
+   if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;

-   sess = (struct aesni_mb_session *)c_sess->_private;
+   sess = (struct aesni_mb_session *)
+   ((struct rte_cryptodev_session *)_sess)->_private;

if (unlikely(aesni_mb_set_session_parameters(qp->ops,
-   sess, crypto_op->xform) != 0))
-   return NULL;
+   sess, crypto_op->xform) != 0)) {
+   rte_mempool_put(qp->sess_mp, _sess);
+   sess = NULL;
+   }
}

return sess;
-- 
2.5.0

[dpdk-dev] [PATCH] aesni_mb: fix wrong return value

[Pablo de Lara]

cryptodev_aesni_mb_init was returning the device id of
the device just created, but rte_eal_vdev_init
(the function that calls the first one), was expecting 0 or
negative value.
This made impossible to create more than one aesni_mb device
from command line.

Fixes: 924e84f87306 ("aesni_mb: add driver for multi buffer based crypto")

Signed-off-by: Pablo de Lara 
---
 app/test/test_cryptodev.c  | 7 ---
 app/test/test_cryptodev_perf.c | 5 +++--
 doc/guides/rel_notes/release_16_04.rst | 6 ++
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 2 +-
 examples/l2fwd-crypto/main.c   | 4 ++--
 5 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index fd5b7ec..62f8fb0 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -143,7 +143,8 @@ testsuite_setup(void)
 {
struct crypto_testsuite_params *ts_params = _params;
struct rte_cryptodev_info info;
-   unsigned i, nb_devs, dev_id = 0;
+   unsigned i, nb_devs, dev_id;
+   int ret;
uint16_t qp_id;

memset(ts_params, 0, sizeof(*ts_params));
@@ -177,10 +178,10 @@ testsuite_setup(void)
RTE_CRYPTODEV_AESNI_MB_PMD);
if (nb_devs < 2) {
for (i = nb_devs; i < 2; i++) {
-   int dev_id = rte_eal_vdev_init(
+   ret = rte_eal_vdev_init(
CRYPTODEV_NAME_AESNI_MB_PMD, NULL);

-   TEST_ASSERT(dev_id >= 0,
+   TEST_ASSERT(ret == 0,
"Failed to create instance %u of"
" pmd : %s",
i, CRYPTODEV_NAME_AESNI_MB_PMD);
diff --git a/app/test/test_cryptodev_perf.c b/app/test/test_cryptodev_perf.c
index 1744e13..728bcf0 100644
--- a/app/test/test_cryptodev_perf.c
+++ b/app/test/test_cryptodev_perf.c
@@ -107,6 +107,7 @@ testsuite_setup(void)
struct crypto_testsuite_params *ts_params = _params;
struct rte_cryptodev_info info;
unsigned i, nb_devs, valid_dev_id = 0;
+   int ret;
uint16_t qp_id;

ts_params->mbuf_mp = rte_mempool_lookup("CRYPTO_PERF_MBUFPOOL");
@@ -138,10 +139,10 @@ testsuite_setup(void)
nb_devs = 
rte_cryptodev_count_devtype(RTE_CRYPTODEV_AESNI_MB_PMD);
if (nb_devs < 2) {
for (i = nb_devs; i < 2; i++) {
-   int dev_id = rte_eal_vdev_init(
+   ret = rte_eal_vdev_init(
CRYPTODEV_NAME_AESNI_MB_PMD, NULL);

-   TEST_ASSERT(dev_id >= 0,
+   TEST_ASSERT(ret == 0,
"Failed to create instance %u of pmd : 
%s",
i, CRYPTODEV_NAME_AESNI_MB_PMD);
}
diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 27fc624..123a6fd 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -59,6 +59,12 @@ EAL
 Drivers
 ~~~

+* **aesni_mb: Fixed wrong return value when creating a device.**
+
+  cryptodev_aesni_mb_init() was returning the device id of the device created,
+  instead of 0 (when success), that rte_eal_vdev_init() expects.
+  This made impossible the creation of more than one aesni_mb device
+  from command line.

 Libraries
 ~
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 2ede7c1..a655ed8 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -628,7 +628,7 @@ cryptodev_aesni_mb_create(const char *name, unsigned 
socket_id)
internals->max_nb_queue_pairs = RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS;
internals->max_nb_sessions = RTE_AESNI_MB_PMD_MAX_NB_SESSIONS;

-   return dev->data->dev_id;
+   return 0;
 init_error:
MB_LOG_ERR("driver %s: cryptodev_aesni_create failed", name);

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index d70fc9a..3f53e4e 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1178,9 +1178,9 @@ initialize_cryptodevs(struct l2fwd_crypto_options 
*options, unsigned nb_ports)
return -1;
} else if (options->cdev_type == RTE_CRYPTODEV_AESNI_MB_PMD) {
for (i = 0; i < nb_ports; i++) {
-   int id = rte_eal_vdev_init(CRYPTODEV_NAME_AESNI_MB_PMD,
+   int retval = 
rte_eal_vdev_init(CRYPTODEV_NAME_AESNI_MB_PMD,
NULL);
-   if (id < 0)
+   if (retval < 0)
  

[dpdk-dev] [PATCH v3 0/4] Various fixes for L2fwd-crypto

[Declan Doherty]

On 12/02/16 09:17, Pablo de Lara wrote:
> This patchset includes param handling, typo and
> statistics fixes in the L2fwd-crypto sample app.
>
> Changes in v3:
> - Reset all accumulated stats
>
> Changes in v2:
> - Include "Fixes" line
>
>
> Pablo de Lara (4):
>l2fwd-crypto: fix total stats
>l2fwd-crypto: fix incorrect params in command line help
>l2fwd-crypto: fix auth params setting
>l2fwd-crypto: fix typos
>
>   examples/l2fwd-crypto/main.c | 26 --
>   1 file changed, 16 insertions(+), 10 deletions(-)
>

Series Acked-by: Declan Doherty 

[dpdk-dev] [dpdk-announce] call to join Linux Foundation

[Thomas Monjalon]

After few meetings and emails, it has been agreed to work with
the Linux Foundation to assist the growing community of the DPDK.

The outlines and the budget are described in this email by Tim O'Driscoll:
http://dpdk.org/ml/archives/dev/2016-February/032720.html

We need around ten companies to contribute to this small effort and
become a supporter of the initiative.

As suggested by Dave Neary, the next step is to draft a membership
agreement and identify the members of this new lightweight foundation:
http://dpdk.org/ml/archives/dev/2016-February/032909.html

Please, it would be great to use this thread to announce the official
commitment of your company to support the DPDK community!

[dpdk-dev] [PATCH v2 2/5] EAL: Add new EAL "--qtest-virtio" option

[Tan, Jianfeng]

Hi Tetsuya,

On 2/10/2016 11:40 AM, Tetsuya Mukawa wrote:
> To work with qtest virtio-net PMD, virtual address that maps hugepages
> should be between (1 << 31) to (1 << 44). This patch adds one more option

Is there any reference about this limitation? And is it also true for 32 
bit machine?

Thanks,
Jianfeng

[dpdk-dev] i40e RSS for IPv6 packets

[Shaham Fridenberg]

Hey guys,

I'm using dpdk 2.1.0 and it seems that RSS for IPv6 packets on i40e NIC does 
not work.

All packets are passed to RX queue 0.

Is that a known issue? Is there some RSS configuration needed?

Thanks,
Shaham

[dpdk-dev] rebasing of dpdk-next-net tree

[Bruce Richardson]

Hi all

just a brief note about the dpdk-next-net tree. As many of you will have noticed
I have starting committing patches to the networking drivers into the
dpdk-next-net tree. For the current release cycle, these will be put onto the
branch rel_16_04.

Please note, though, that this branch will be rebased occasionally, as I
see the need to pull in content from dpdk.org mainline. I will attempt to keep
rebases to a minimum, but they will occur as needed from time to time.

If this causes issues for anyone, please let me know, so that we can come up
with a policy for the dpdk-next-* trees (of which next-net is only the first)
which works for both contributors and maintainers/committers.

Thanks,
/Bruce

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

[David Marchand]

Move all os / arch specifics to eal.

Signed-off-by: David Marchand 
Reviewed-by: Santosh Shukla 
Tested-by: Santosh Shukla 
---
Changes since v2:
- fixed bsd init issue (reported by Tetsuya M.)

---
 drivers/net/virtio/virtio_pci.c | 356 +++-
 drivers/net/virtio/virtio_pci.h |  38 +
 2 files changed, 59 insertions(+), 335 deletions(-)

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index b4d4476..85fbe88 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -49,74 +49,35 @@
 #define PCI_CAPABILITY_LIST0x34
 #define PCI_CAP_ID_VNDR0x09

-#define VIRTIO_PCI_REG_ADDR(hw, reg) \
-   (unsigned short)((hw)->io_base + (reg))
-
-#define VIRTIO_READ_REG_1(hw, reg) \
-   inb((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_1(hw, reg, value) \
-   outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
-
-#define VIRTIO_READ_REG_2(hw, reg) \
-   inw((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_2(hw, reg, value) \
-   outw_p((unsigned short)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
-
-#define VIRTIO_READ_REG_4(hw, reg) \
-   inl((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_4(hw, reg, value) \
-   outl_p((unsigned int)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
+/*
+ * The remaining space is defined by each driver as the per-driver
+ * configuration space.
+ */
+#define VIRTIO_PCI_CONFIG(hw) (((hw)->use_msix) ? 24 : 20)

 static void
 legacy_read_dev_config(struct virtio_hw *hw, size_t offset,
   void *dst, int length)
 {
-   uint64_t off;
-   uint8_t *d;
-   int size;
-
-   off = VIRTIO_PCI_CONFIG(hw) + offset;
-   for (d = dst; length > 0; d += size, off += size, length -= size) {
-   if (length >= 4) {
-   size = 4;
-   *(uint32_t *)d = VIRTIO_READ_REG_4(hw, off);
-   } else if (length >= 2) {
-   size = 2;
-   *(uint16_t *)d = VIRTIO_READ_REG_2(hw, off);
-   } else {
-   size = 1;
-   *d = VIRTIO_READ_REG_1(hw, off);
-   }
-   }
+   rte_eal_pci_ioport_read(>io, dst, length,
+   VIRTIO_PCI_CONFIG(hw) + offset);
 }

 static void
 legacy_write_dev_config(struct virtio_hw *hw, size_t offset,
const void *src, int length)
 {
-   uint64_t off;
-   const uint8_t *s;
-   int size;
-
-   off = VIRTIO_PCI_CONFIG(hw) + offset;
-   for (s = src; length > 0; s += size, off += size, length -= size) {
-   if (length >= 4) {
-   size = 4;
-   VIRTIO_WRITE_REG_4(hw, off, *(const uint32_t *)s);
-   } else if (length >= 2) {
-   size = 2;
-   VIRTIO_WRITE_REG_2(hw, off, *(const uint16_t *)s);
-   } else {
-   size = 1;
-   VIRTIO_WRITE_REG_1(hw, off, *s);
-   }
-   }
+   rte_eal_pci_ioport_write(>io, src, length,
+VIRTIO_PCI_CONFIG(hw) + offset);
 }

 static uint64_t
 legacy_get_features(struct virtio_hw *hw)
 {
-   return VIRTIO_READ_REG_4(hw, VIRTIO_PCI_HOST_FEATURES);
+   uint64_t dst;
+
+   rte_eal_pci_ioport_read(>io, , 4, VIRTIO_PCI_HOST_FEATURES);
+   return dst;
 }

 static void
@@ -127,19 +88,23 @@ legacy_set_features(struct virtio_hw *hw, uint64_t 
features)
"only 32 bit features are allowed for legacy virtio!");
return;
}
-   VIRTIO_WRITE_REG_4(hw, VIRTIO_PCI_GUEST_FEATURES, features);
+   rte_eal_pci_ioport_write(>io, , 4,
+VIRTIO_PCI_GUEST_FEATURES);
 }

 static uint8_t
 legacy_get_status(struct virtio_hw *hw)
 {
-   return VIRTIO_READ_REG_1(hw, VIRTIO_PCI_STATUS);
+   uint8_t dst;
+
+   rte_eal_pci_ioport_read(>io, , 1, VIRTIO_PCI_STATUS);
+   return dst;
 }

 static void
 legacy_set_status(struct virtio_hw *hw, uint8_t status)
 {
-   VIRTIO_WRITE_REG_1(hw, VIRTIO_PCI_STATUS, status);
+   rte_eal_pci_ioport_write(>io, , 1, VIRTIO_PCI_STATUS);
 }

 static void
@@ -151,148 +116,63 @@ legacy_reset(struct virtio_hw *hw)
 static uint8_t
 legacy_get_isr(struct virtio_hw *hw)
 {
-   return VIRTIO_READ_REG_1(hw, VIRTIO_PCI_ISR);
+   uint8_t dst;
+
+   rte_eal_pci_ioport_read(>io, , 1, VIRTIO_PCI_ISR);
+   return dst;
 }

 /* Enable one vector (0) for Link State Intrerrupt */
 static uint16_t
 legacy_set_config_irq(struct virtio_hw *hw, uint16_t vec)
 {
-   VIRTIO_WRITE_REG_2(hw, VIRTIO_MSI_CONFIG_VECTOR, vec);
-   return VIRTIO_READ_REG_2(hw, VIRTIO_MSI_CONFIG_VECTOR);
+   uint16_t dst;
+
+   rte_eal_pci_ioport_write(>io, , 2, VIRTIO_MSI_CONFIG_VECTOR);
+   

[dpdk-dev] [PATCH v3 3/4] eal: introduce pci ioport api

[David Marchand]

Most of the code is inspired on virtio driver.
rte_pci_ioport structure is filled at map time with anything needed for later
read / write calls.
At the moment, offset field is used to store a x86 ioport (uint16_t) and will
be reused for other arches.

TODO: check multi process, check intr_handle init/exit,

Signed-off-by: David Marchand 
Tested-by: Santosh Shukla 
---
Changes since v2:
- removed remaining reference to rte_ioport_t

Changes since v1:
- dropped rte_ioport and removed the arch headers, if performance is an
  issue, we will see how to enhance this in later patches
- rte_pci_ioport object now reaches driver implementation (uio / vfio)
- sanity checks are in uio map function, no reason to have those checks in
  read/write functions

---
 lib/librte_eal/bsdapp/eal/eal_pci.c | 135 +++
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |   4 +
 lib/librte_eal/common/include/rte_pci.h |  65 +
 lib/librte_eal/linuxapp/eal/eal_pci.c   | 170 
 lib/librte_eal/linuxapp/eal/eal_pci_init.h  |  16 +++
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c   | 132 +-
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c  |  37 ++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |   4 +
 8 files changed, 560 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 95c32c1..58f2ec9 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -51,6 +51,11 @@
 #include 
 #include 

+#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
+#include 
+#include 
+#endif
+
 #include 
 #include 
 #include 
@@ -479,6 +484,136 @@ int rte_eal_pci_write_config(const struct rte_pci_device 
*dev,
return -1;
 }

+int
+rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar,
+  struct rte_pci_ioport *p)
+{
+   int ret;
+
+   switch (dev->kdrv) {
+#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
+   case RTE_KDRV_NIC_UIO:
+   if ((uintptr_t) dev->mem_resource[bar].addr <= UINT16_MAX) {
+   p->offset = (uintptr_t)dev->mem_resource[bar].addr;
+   ret = 0;
+   } else
+   ret = -1;
+   break;
+#endif
+   default:
+   ret = -1;
+   break;
+   }
+
+   if (!ret)
+   p->dev = dev;
+
+   return ret;
+}
+
+static void
+pci_uio_ioport_read(struct rte_pci_ioport *p,
+   void *data, size_t len, off_t offset)
+{
+#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
+   uint8_t *d;
+   int size;
+   unsigned short reg = p->offset + offset;
+
+   for (d = data; len > 0; d += size, reg += size, len -= size) {
+   if (len >= 4) {
+   size = 4;
+   *(uint32_t *)d = inl(reg);
+   } else if (len >= 2) {
+   size = 2;
+   *(uint16_t *)d = inw(reg);
+   } else {
+   size = 1;
+   *d = inb(reg);
+   }
+   }
+#else
+   RTE_SET_USED(p);
+   RTE_SET_USED(data);
+   RTE_SET_USED(len);
+   RTE_SET_USED(offset);
+#endif
+}
+
+void
+rte_eal_pci_ioport_read(struct rte_pci_ioport *p,
+   void *data, size_t len, off_t offset)
+{
+   switch (p->dev->kdrv) {
+   case RTE_KDRV_NIC_UIO:
+   pci_uio_ioport_read(p, data, len, offset);
+   break;
+   default:
+   break;
+   }
+}
+
+static void
+pci_uio_ioport_write(struct rte_pci_ioport *p,
+const void *data, size_t len, off_t offset)
+{
+#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
+   const uint8_t *s;
+   int size;
+   unsigned short reg = p->offset + offset;
+
+   for (s = data; len > 0; s += size, reg += size, len -= size) {
+   if (len >= 4) {
+   size = 4;
+   outl(*(const uint32_t *)s, reg);
+   } else if (len >= 2) {
+   size = 2;
+   outw(*(const uint16_t *)s, reg);
+   } else {
+   size = 1;
+   outb(*s, reg);
+   }
+   }
+#else
+   RTE_SET_USED(p);
+   RTE_SET_USED(data);
+   RTE_SET_USED(len);
+   RTE_SET_USED(offset);
+#endif
+}
+
+void
+rte_eal_pci_ioport_write(struct rte_pci_ioport *p,
+const void *data, size_t len, off_t offset)
+{
+   switch (p->dev->kdrv) {
+   case RTE_KDRV_NIC_UIO:
+   pci_uio_ioport_write(p, data, len, offset);
+   break;
+   default:
+   break;
+   }
+}
+
+int
+rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
+{
+   int ret;
+
+   switch (p->dev->kdrv) {
+#if defined(RTE_ARCH_X86_64) || 

[dpdk-dev] [PATCH v3 2/4] virtio: fix incorrect check when mapping pci resources

[David Marchand]

According to the api, rte_eal_pci_map_device is only successful when returning
0.

Fixes: 6ba1f63b5ab0 ("virtio: support specification 1.0")
Signed-off-by: David Marchand 
Acked-by: Yuanhan Liu 
---
 drivers/net/virtio/virtio_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 762e91c..b4d4476 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -795,7 +795,7 @@ virtio_read_caps(struct rte_pci_device *dev, struct 
virtio_hw *hw)
struct virtio_pci_cap cap;
int ret;

-   if (rte_eal_pci_map_device(dev) < 0) {
+   if (rte_eal_pci_map_device(dev)) {
PMD_INIT_LOG(DEBUG, "failed to map pci device!");
return -1;
}
-- 
1.9.1

[dpdk-dev] [PATCH v3 1/4] virtio/bsd: fix typo

[David Marchand]

Fixes: c52afa68d763 ("virtio: move left PCI stuff in the right file")
Signed-off-by: David Marchand 
Acked-by: Yuanhan Liu 
---
 drivers/net/virtio/virtio_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 455e40d..762e91c 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -439,7 +439,7 @@ legacy_virtio_resource_init(struct rte_pci_device *pci_dev)

 #else
 static int
-legayc_virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
+legacy_virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
 {
/* nic_uio does not enable interrupts, return 0 (false). */
return 0;
-- 
1.9.1

[dpdk-dev] [PATCH v3 0/4] rework ioport access for virtio

[David Marchand]

Introduce a new pci ioport api in eal to mask all arch / kernel driver
specifics.

- rte_eal_pci_ioport_map is responsible for initialising an rte_pci_ioport
  object that is used in subsequent calls, this function must be tweaked per
  architecture and per kernel driver,
- rte_eal_pci_ioport_read / rte_eal_pci_ioport_write uses a rte_pci_ioport
  object to read / write those resources,
- rte_eal_pci_ioport_unmap releases resources used by a rte_pci_ioport
  object if necessary.

There is still some more work to ensure intr handle are properly initialized
and released when used in conjonction with rte_eal_map_device() api calls.

BSD code has been neither run nor compiled, please can someone confirm I did
not break too much stuff ?

virtio legacy code has been updated accordingly.
With this, virtio code should be ready for other archs now.

So in the end, all that is missing on linux is some vfio update for support
of all architectures that have vfio.

Changes since v2:
- rebased on HEAD
- fixed a remaining reference to rte_ioport_t in comment
- fixed virtio driver for bsd

Changes since v1:
- dropped rte_ioport and removed the arch headers, if performance is an
  issue, we will see how to enhance this in later patches


Regards, 
-- 
David Marchand

David Marchand (4):
  virtio/bsd: fix typo
  virtio: fix incorrect check when mapping pci resources
  eal: introduce pci ioport api
  virtio: use pci ioport api

 drivers/net/virtio/virtio_pci.c | 358 
 drivers/net/virtio/virtio_pci.h |  38 +--
 lib/librte_eal/bsdapp/eal/eal_pci.c | 135 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |   4 +
 lib/librte_eal/common/include/rte_pci.h |  65 +
 lib/librte_eal/linuxapp/eal/eal_pci.c   | 170 +++
 lib/librte_eal/linuxapp/eal/eal_pci_init.h  |  16 ++
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c   | 132 -
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c  |  37 +++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |   4 +
 10 files changed, 620 insertions(+), 339 deletions(-)

-- 
1.9.1

[dpdk-dev] vm_power_manager uses channel_commands.h which is not placed in installed copy of DPDK

[Thomas Monjalon]

2016-02-15 13:56, Panu Matilainen:
> On 02/15/2016 12:15 PM, Thomas Monjalon wrote:
> > 2016-02-15 10:29, Panu Matilainen:
> >> On 02/14/2016 01:38 AM, Matthew Hall wrote:
> >>> Hello,
> >>>
> >>> I found a peculiarity in the vm_power_manager example on DPDK 2.2 if you 
> >>> use an installed copy of DPDK to compile the examples instead of the 
> >>> master copy (while trying to update some outdated stuff in my build 
> >>> system).
> > [...]
> >>> Did anybody run into this before?
> >>
> >> Yes, the problem exists at least since DPDK 2.1 but somehow never
> >> remembered to report / do something about it.
> >>
> >> Basically either vm_power_manager example is messing with things its not
> >> supposed to, or librte_power library isn't exporting everything needed
> >> to fully use the it. Unfortunately both the library and the example are
> >> lacking a maintainer :-/
> >
> > Exact, you got the point.
> > I suggest to disable this feature in your config.
> 
> I take it you mean disabling librte_power entirely, not just the example?

Yes

> > If it's really annoying, you are allowed to request the removal of the code.
> > I believe someone would maintain it if he has an interest.
> 
> I can certainly submit a patch to disable it by default in the configs 
> (seems reasonable unmaintained code would default to off) and add a 
> deprecation note along the lines of "if no maintainer steps up, this 
> code will be removed in 16.07" if you like :)

Before sending such notice, we should wait for comments of some known
contributors to librte_power.
Alan, Pablo, what is your opinion?

[dpdk-dev] [PATCH v2 2/2] i40evf: support interrupt based pf reset request

[David Marchand]

Hello,

On Sun, Feb 14, 2016 at 4:25 AM, Wu, Jingjing  wrote:
>> -Original Message-
>> From: David Marchand [mailto:david.marchand at 6wind.com]
>> Having this infrastructure is one thing, but the initial problem was that the
>> driver did not recover from this reset event.
>> The linux i40e vf driver handles this kind of event itself.
>> Could we have something similar ?
>>
>
> Considering about the how to use DPDK PMD, and how to setup resource, we can
> know that lots of resources are managed by application. I think based on 
> current
> PMD driver framework, driver cannot reset without application's help.

I reported an issue on ixgbe.
What you provide here is a workaround for i40e.
I am not even sure this can be applied to ixgbe.

Does it mean that anytime we have a problem with drivers, workarounds
should be applied to ethdev / eal ... so that you don't have to handle
anything in the drivers ?
This is not the first time I complain about this kind of design issues.


> If we need to support driver recovery automatically, we'd better to find a 
> way to do that.
> Do you have any idea?

First, list those "lots of resources" that "are managed by application".
If your driver needs to keep track of those, this is i40e driver job
to do this internally without requiring ethdev to be modified.

If this proves to be generic enough, maybe moving part of this to
ethdev will then make sense.


Thanks.

-- 
David Marchand

[dpdk-dev] [PATCH] vhost: remove vhost_net_device_ops

[Yuanhan Liu]

On Wed, Feb 10, 2016 at 11:27:08AM -0800, Rich Lane wrote:
> The indirection is unnecessary because there is only one implementation of the
> vhost common code. Removing it makes the code more readable.

This is a good cleanup! A minor nit is that I saw few long lines
exceeding 80 chars.

--yliu

[dpdk-dev] vm_power_manager uses channel_commands.h which is not placed in installed copy of DPDK

[Panu Matilainen]

On 02/15/2016 12:15 PM, Thomas Monjalon wrote:
> 2016-02-15 10:29, Panu Matilainen:
>> On 02/14/2016 01:38 AM, Matthew Hall wrote:
>>> Hello,
>>>
>>> I found a peculiarity in the vm_power_manager example on DPDK 2.2 if you 
>>> use an installed copy of DPDK to compile the examples instead of the master 
>>> copy (while trying to update some outdated stuff in my build system).
> [...]
>>> Did anybody run into this before?
>>
>> Yes, the problem exists at least since DPDK 2.1 but somehow never
>> remembered to report / do something about it.
>>
>> Basically either vm_power_manager example is messing with things its not
>> supposed to, or librte_power library isn't exporting everything needed
>> to fully use the it. Unfortunately both the library and the example are
>> lacking a maintainer :-/
>
> Exact, you got the point.
> I suggest to disable this feature in your config.

I take it you mean disabling librte_power entirely, not just the example?

> If it's really annoying, you are allowed to request the removal of the code.
> I believe someone would maintain it if he has an interest.

I can certainly submit a patch to disable it by default in the configs 
(seems reasonable unmaintained code would default to off) and add a 
deprecation note along the lines of "if no maintainer steps up, this 
code will be removed in 16.07" if you like :)

- Panu -

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

[Olivier MATZ]

Hi David,

On 02/15/2016 11:21 AM, Hunt, David wrote:
> On 15/02/2016 10:15, Olivier MATZ wrote:
>> On 02/15/2016 10:58 AM, Hunt, David wrote:
>>>  I'm working on that at the moment with the external mempool handler
>>> code. However, it crossed my mind that we have a choice to use symbol
>>> versioning OR use NEXT_ABI. Would one method be preferred over the
>>> other?
>>
>> I think symbol versioning should always be preferred when possible.
>>
>> In your case, as far as I remember, your are updating the rte_mempool
>> structure, which is accessed by static inline functions. I don't think
>> it is easily manageable with symbol versioning. Moreover, the ABI will
>> already be broken by Keith's patch, so I think it's less problematic
>> to have other patches breaking the ABI at the same time.
> 
> OK, Thanks for that. I'll use NEXT_ABI in this case so. :)

Just to let you know in case you missed it: Keith's patch (v3 [1] and
v4 [2]) finally does not have the NEXT_ABI ifdefs, because it was
too heavy.

So for your patches it will also depend on the complexity of the
changes. You can have a try with NEXT_ABI and see if the code is
still maintainable or not. If not, the process is to push a deprecation
notice for 16.04 and the code for 16.07.

Regards,
Olivier

[1] v3: http://dpdk.org/ml/archives/dev/2016-February/033004.html
[2] v4: http://dpdk.org/ml/archives/dev/2016-February/033102.html

[dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load

[Ananyev, Konstantin]

Hi lads,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, February 15, 2016 10:03 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; Ananyev, Konstantin
> Subject: Re: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX 
> checksum off-load
> 
> 2016-02-15 05:32, Lu, Wenzhuo:
> > From: Ananyev, Konstantin
> > > From reading X550 spec, I don't really understand what for we need to 
> > > specify is
> > > it GRE or VXLAN packet, so probably we don't need that flag for now at 
> > > all?
> > The reason is we need to set the tunnel type in the Advanced Transmit Data 
> > Descriptor.

Yes, I saw that in x550 spec, though I really doubt it is needed to calculate 
etiher outer IP,
or inner IP/L4 checksum.
After all TUNNELLEN includes all tunnel headers plus inner L2 length.
The only reason I can think it might be useful for  HW is when packets are sent 
from one
VF to another. 
In that case, HW probably would try to avoid extra packet scanning and rely on 
information from SW.
As mentioned in x550 spec, section's  note:
"...In virtualization mode, packets might be received from other local VMs. The 
X550 does not
check the L5 header for these packets and does not report NFS header. If such 
packets carry
IP tunneling (IPv4 - IPv6), they are reported as IPV4E. The packets received 
from local VM
are indicated by the LB bit in the status field. To be identified, the CC bit 
in the transmit
descriptor must be set and if it is a tunnel packet, the TUNNEL.OUTERIPCS must 
be set also."
Though I am not sure we do need to support that case.
That's why probably the easiest way would be to avoid setting 'Tunnel Type' 
field at all.

> 
> Why don't we use packet type?

Yes, that's probably another possible way, if we really decide to setup this 
info at TX descriptor.

BTW, reading x550 spec, I think ixgbe RX code that setups packet_type need to 
be updated too.
Right now it can't handle vxlan/gre tunnelling case.

Konstantin

> 
> > > If we really do, might bw worth to organise it like KT_TX_L4_CKSUM (as 
> > > enum)
> > > and reserve few values for future expansion (2 or 3 bits?).
> > Now there're only VxLAN and NVGRE supported. So, only 1 bit is occupied for 
> > that. Not sure if more types will be supported in the
> future. Any suggestions? Thanks.
> 
> Yes there can be a lot of tunnel types.
> Please check RTE_PTYPE_TUNNEL_*
> 

[dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API

[Marc]

On 15 February 2016 at 09:46, N?lio Laranjeiro 
wrote:

> On Sun, Feb 14, 2016 at 11:17:38PM +0100, Marc Sune wrote:
> > This patch redesigns the API to set the link speed/s configure
> > for an ethernet port. Specifically:
> >
> > - it allows to define a set of advertised speeds for
> >   auto-negociation.
> > - it allows to disable link auto-negociation (single fixed speed).
> > - default: auto-negociate all supported speeds.
> >
> >[...]
> > diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> > index c5688a7..01c3a5c 100644
> > --- a/drivers/net/mlx4/mlx4.c
> > +++ b/drivers/net/mlx4/mlx4.c
> > @@ -4265,8 +4265,8 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *info)
> >   if (priv_get_ifname(priv, ) == 0)
> >   info->if_index = if_nametoindex(ifname);
> >
> > - info->speed_capa = ETH_SPEED_CAP_10G |ETH_SPEED_CAP_40G |
> > - ETH_SPEED_CAP_56G;
> > + info->speed_capa = ETH_LINK_SPEED_10G |ETH_LINK_SPEED_40G |
> > + ETH_LINK_SPEED_56G;
> >
> >   priv_unlock(priv);
> >  }
> > @@ -4636,6 +4636,8 @@ mlx4_link_update_unlocked(struct rte_eth_dev *dev,
> int wait_to_complete)
> >   dev_link.link_speed = link_speed;
> >   dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
> >   ETH_LINK_HALF_DUPLEX :
> ETH_LINK_FULL_DUPLEX);
> > + dev_link.link_autoneg = ~(dev->data->dev_conf.link_speeds &
> > + ETH_LINK_SPEED_NO_AUTONEG);
> >   if (memcmp(_link, >data->dev_link, sizeof(dev_link))) {
> >   /* Link status changed. */
> >   dev->data->dev_link = dev_link;
> >[...]
>
> The same modification are missing in mlx5.
>
>
Damn.. are the required closed-source libraries for MLX4/5 available
somewhere or is there a chance automatic builds can also compile drivers
that require external dependencies (like this MLX)?

It is very prone to errors having to guess what is going to happen without
being able to compile these drivers.

Marc

--
> N?lio Laranjeiro
> 6WIND
>

[dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API

[Olga Shern]

Hi Marc, 

You can download MLNX_OFED from Mellanox web site:
http://www.mellanox.com/page/products_dyn?product_family=26=linux_sw_drivers

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marc
Sent: Monday, February 15, 2016 1:00 PM
To: N?lio Laranjeiro
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API

On 15 February 2016 at 09:46, N?lio Laranjeiro 
wrote:

> On Sun, Feb 14, 2016 at 11:17:38PM +0100, Marc Sune wrote:
> > This patch redesigns the API to set the link speed/s configure for 
> > an ethernet port. Specifically:
> >
> > - it allows to define a set of advertised speeds for
> >   auto-negociation.
> > - it allows to disable link auto-negociation (single fixed speed).
> > - default: auto-negociate all supported speeds.
> >
> >[...]
> > diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c  
> >index c5688a7..01c3a5c 100644
> > --- a/drivers/net/mlx4/mlx4.c
> > +++ b/drivers/net/mlx4/mlx4.c
> > @@ -4265,8 +4265,8 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, 
> > struct
> rte_eth_dev_info *info)
> >   if (priv_get_ifname(priv, ) == 0)
> >   info->if_index = if_nametoindex(ifname);
> >
> > - info->speed_capa = ETH_SPEED_CAP_10G |ETH_SPEED_CAP_40G |
> > - ETH_SPEED_CAP_56G;
> > + info->speed_capa = ETH_LINK_SPEED_10G |ETH_LINK_SPEED_40G |
> > + ETH_LINK_SPEED_56G;
> >
> >   priv_unlock(priv);
> >  }
> > @@ -4636,6 +4636,8 @@ mlx4_link_update_unlocked(struct rte_eth_dev 
> > *dev,
> int wait_to_complete)
> >   dev_link.link_speed = link_speed;
> >   dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
> >   ETH_LINK_HALF_DUPLEX :
> ETH_LINK_FULL_DUPLEX);
> > + dev_link.link_autoneg = ~(dev->data->dev_conf.link_speeds &
> > + 
> > + ETH_LINK_SPEED_NO_AUTONEG);
> >   if (memcmp(_link, >data->dev_link, sizeof(dev_link))) {
> >   /* Link status changed. */
> >   dev->data->dev_link = dev_link; [...]
>
> The same modification are missing in mlx5.
>
>
Damn.. are the required closed-source libraries for MLX4/5 available somewhere 
or is there a chance automatic builds can also compile drivers that require 
external dependencies (like this MLX)?

It is very prone to errors having to guess what is going to happen without 
being able to compile these drivers.

Marc

--
> N?lio Laranjeiro
> 6WIND
>

[dpdk-dev] thoughts on DPDK after a few days of reading sources

[Christian Ehrhardt]

On Thu, Feb 11, 2016 at 8:58 AM, Thomas Monjalon 
wrote:

> Hi,
>
> 2016-02-10 19:05, Seth Arnold:
> > I've taken some notes while reading the sources; I'm sharing them in the
> > hopes that it's useful: on the one hand my fresh eyes may spot things
> that
> > you've overlooked, on the other hand your familiarity with the code means
> > that you're better suited to judge what I've found.
>
> Thanks for taking time and sharing, it's very valuable.
>
> > - shellcheck reports extensive cases of forgotten quotes to prevent word
> >   splitting or globbing, potentially unused variables, error-prone printf
> >   formatting. The scripts that are going to be used at runtime should be
> >   fixed:
> >   - ./debian/dpdk-init
> >   - ./debian/dpdk.init
>
> These files are not in the tree. Should they?
>
>
You are right, they are not in tree.
These few are parts of the ubuntu packaging and will be fixed by me this
week.
Sooner or later that might (partially?) flow back to the Debian packaging
that is in tree.


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

[...]

[dpdk-dev] [PATCH 1/3] eal: fix keep alive header for C++

[Remy Horton]

On 05/02/2016 17:06, Thomas Monjalon wrote:
> When built in a C++ application, the keepalive include fails:
>
> rte_keepalive.h:142:41: error: ?ALIVE? was not declared in this scope
>keepcfg->state_flags[rte_lcore_id()] = ALIVE;
>   ^
>
> Fixes: 75583b0d1efd ("eal: add keep alive monitoring")
>
> Signed-off-by: Thomas Monjalon 

Acked-by: Remy Horton 

[dpdk-dev] [PATCH 2/3] examples/ethtool: fix build

[Remy Horton]

On 05/02/2016 14:54, Thomas Monjalon wrote:
> When building for ARM, the spinlock structure was not found.
> It appears to be a mismatch with rwlock which is not used in this file.
>
> Fixes: bda68ab9d1e7 ("examples/ethtool: add user-space ethtool sample 
> application")
>
> Signed-off-by: Thomas Monjalon 
> ---
>   examples/ethtool/ethtool-app/main.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Remy Horton 

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

[Olivier MATZ]

Hi David,

On 02/15/2016 10:58 AM, Hunt, David wrote:
> On 12/02/2016 15:50, Olivier MATZ wrote:
>> - NEXT_ABI does make the code harder to read in this case, and I'm
>>thinking about the patchset from David Hunt (external mempool handler)
>>that will be in the same situation, and maybe also another patchset
>>I'm working on.
> 
> Olivier,
> I'm working on that at the moment with the external mempool handler
> code. However, it crossed my mind that we have a choice to use symbol
> versioning OR use NEXT_ABI. Would one method be preferred over the other?

I think symbol versioning should always be preferred when possible.

In your case, as far as I remember, your are updating the rte_mempool
structure, which is accessed by static inline functions. I don't think
it is easily manageable with symbol versioning. Moreover, the ABI will
already be broken by Keith's patch, so I think it's less problematic
to have other patches breaking the ABI at the same time.

Regards,
Olivier

[dpdk-dev] vm_power_manager uses channel_commands.h which is not placed in installed copy of DPDK

[Thomas Monjalon]

2016-02-15 10:29, Panu Matilainen:
> On 02/14/2016 01:38 AM, Matthew Hall wrote:
> > Hello,
> >
> > I found a peculiarity in the vm_power_manager example on DPDK 2.2 if you 
> > use an installed copy of DPDK to compile the examples instead of the master 
> > copy (while trying to update some outdated stuff in my build system).
[...]
> > Did anybody run into this before?
> 
> Yes, the problem exists at least since DPDK 2.1 but somehow never 
> remembered to report / do something about it.
> 
> Basically either vm_power_manager example is messing with things its not 
> supposed to, or librte_power library isn't exporting everything needed 
> to fully use the it. Unfortunately both the library and the example are 
> lacking a maintainer :-/

Exact, you got the point.
I suggest to disable this feature in your config.
If it's really annoying, you are allowed to request the removal of the code.
I believe someone would maintain it if he has an interest.

[dpdk-dev] [PATCH v2 2/4] Amazon ENA communication layer

[Jan Mędala]

ping for comments/review

Thanks,
  Jan

P.S. Sorry for replaying with whole code in previous messages.

[dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load

[Thomas Monjalon]

2016-02-15 05:32, Lu, Wenzhuo:
> From: Ananyev, Konstantin
> > From reading X550 spec, I don't really understand what for we need to 
> > specify is
> > it GRE or VXLAN packet, so probably we don't need that flag for now at all?
> The reason is we need to set the tunnel type in the Advanced Transmit Data 
> Descriptor.

Why don't we use packet type?

> > If we really do, might bw worth to organise it like KT_TX_L4_CKSUM (as enum)
> > and reserve few values for future expansion (2 or 3 bits?).
> Now there're only VxLAN and NVGRE supported. So, only 1 bit is occupied for 
> that. Not sure if more types will be supported in the future. Any 
> suggestions? Thanks.

Yes there can be a lot of tunnel types.
Please check RTE_PTYPE_TUNNEL_*

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

[Kylulin, Yury]

Hi Wenzhuo,

> -Original Message-
> From: Lu, Wenzhuo
> Sent: Monday, February 15, 2016 4:14 AM
> To: Kylulin, Yury ; dev at dpdk.org
> Subject: RE: [PATCH v2] e1000: enable promiscuous and allmulticast support
> for VF
> 
> Hi Yury,
> 
> > -Original Message-
> > From: Kylulin, Yury
> > Sent: Tuesday, February 9, 2016 5:10 PM
> > To: dev at dpdk.org
> > Cc: Kylulin, Yury; Lu, Wenzhuo
> > Subject: [PATCH v2] e1000: enable promiscuous and allmulticast support
> > for VF
> >
> > 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); }
> Comparing with PF, I think PF will enable multicast promiscuous mode no
> matter dev->data->promiscuous is 0 or not.
> Should the VF have the same behavior?
In case of PF to alter these settings you need to change the value of the 
register,
but for VF we need to send message via mailbox. Assuming that in promiscuous 
mode
we already set both allmulticast and unicast promiscuous I tried to exclude and 
avoid
useless messages via mailbox between PF and VF.
> 
> > +
> > +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] vm_power_manager uses channel_commands.h which is not placed in installed copy of DPDK

[Panu Matilainen]

On 02/14/2016 01:38 AM, Matthew Hall wrote:
> Hello,
>
> I found a peculiarity in the vm_power_manager example on DPDK 2.2 if you use 
> an installed copy of DPDK to compile the examples instead of the master copy 
> (while trying to update some outdated stuff in my build system).
>
> mhall at mvs-01:~/dpdk/examples/vm_power_manager$ fgrep -ir channel_commands 
> *.{c,h}
> channel_manager.c:#include "channel_commands.h"
> channel_monitor.c:#include "channel_commands.h"
> vm_power_cli.c:#include "channel_commands.h"
> channel_manager.h:#include "channel_commands.h"
>
> It appears a bunch of these files are trying to pull in this special header 
> from here:
>
> /home/mhall/src/sdn_sensor/external/dpdk/lib/librte_power/channel_commands.h
>
> However this file is never copied into the include directions in the 
> installed copy. So this example fails to build.
>
> Did anybody run into this before?

Yes, the problem exists at least since DPDK 2.1 but somehow never 
remembered to report / do something about it.

Basically either vm_power_manager example is messing with things its not 
supposed to, or librte_power library isn't exporting everything needed 
to fully use the it. Unfortunately both the library and the example are 
lacking a maintainer :-/

- Panu -

[dpdk-dev] [PATCH v2 4/4] DPDK polling-mode driver for Amazon Elastic Network Adapters (ENA)

[Jan Mędala]

ping for comments/review

Thanks,

  Jan

2016-02-05 19:20 GMT+01:00 Jan Medala :

> This is a PMD for the Amazon ethernet ENA family.
> The driver operates variety of ENA adapters through feature negotiation
> with the adapter and upgradable commands set.
> ENA driver handles PCI Physical and Virtual ENA functions.
>
> Signed-off-by: Evgeny Schemeilin 
> Signed-off-by: Jan Medala 
> Signed-off-by: Jakub Palider 
> ---
>  config/common_linuxapp |   12 +
>  drivers/net/Makefile   |1 +
>  drivers/net/ena/Makefile   |   62 +++
>  drivers/net/ena/ena_ethdev.c   | 1129
> 
>  drivers/net/ena/ena_ethdev.h   |  151 ++
>  drivers/net/ena/ena_logs.h |   76 +++
>  drivers/net/ena/ena_platform.h |   58 +++
>  mk/rte.app.mk  |1 +
>  8 files changed, 1490 insertions(+)
>  create mode 100755 drivers/net/ena/Makefile
>  create mode 100644 drivers/net/ena/ena_ethdev.c
>  create mode 100755 drivers/net/ena/ena_ethdev.h
>  create mode 100644 drivers/net/ena/ena_logs.h
>  create mode 100644 drivers/net/ena/ena_platform.h
>
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 74bc515..261a54f 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -249,6 +249,18 @@ CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
>  CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
>
>  #
> +# Compile burst-oriented Amazon ENA PMD driver
> +#
> +CONFIG_RTE_LIBRTE_ENA_PMD=y
> +CONFIG_RTE_LIBRTE_ENA_DEBUG_INIT=y
> +CONFIG_RTE_LIBRTE_ENA_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_ENA_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_ENA_DEBUG_TX_FREE=n
> +CONFIG_RTE_LIBRTE_ENA_DEBUG_DRIVER=n
> +CONFIG_RTE_LIBRTE_ENA_COM_DEBUG=n
> +CONFIG_RTE_EAL_ENA_UIO=y
> +
> +#
>  # Compile burst-oriented Cisco ENIC PMD driver
>  #
>  CONFIG_RTE_LIBRTE_ENIC_PMD=y
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 6e4497e..8f2649f 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -36,6 +36,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += bonding
>  DIRS-$(CONFIG_RTE_LIBRTE_CXGBE_PMD) += cxgbe
>  DIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += e1000
> +DIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena
>  DIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic
>  DIRS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += fm10k
>  DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e
> diff --git a/drivers/net/ena/Makefile b/drivers/net/ena/Makefile
> new file mode 100755
> index 000..960e4cd
> --- /dev/null
> +++ b/drivers/net/ena/Makefile
> @@ -0,0 +1,62 @@
> +#
> +# BSD LICENSE
> +#
> +# Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates.
> +# 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 copyright holder nor the names of its
> +# contributors may be used to endorse or promote products derived
> +# from this software without specific prior written permission.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +#
> +# library name
> +#
> +LIB = librte_pmd_ena.a
> +CFLAGS += $(WERROR_FLAGS) -O2
> +INCLUDES :=-I$(SRCDIR) -I$(SRCDIR)/base/ena_defs -I$(SRCDIR)/base
> +
> +VPATH += $(SRCDIR)/base
> +#
> +# all source are stored in SRCS-y
> +#
> +SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_ethdev.c
> +SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_com.c
> +SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_eth_com.c
> +
> +# this lib depends upon:
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_eal lib/librte_ether
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_mempool lib/librte_mbuf
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_net lib/librte_malloc
> +
> +ifeq ($(CONFIG_RTE_EXEC_ENV),"cvos")
> +CFLAGS += -Wno-old-style-definition
> +endif
> +
> 

[dpdk-dev] [PATCH v2 1/4] Amazon ENA PCI defines and documentation

[Jan Mędala]

Stephen,
does it mean we should insert those defines to PMD driver files?

dpdk-dev,
ping for more comments/review

Thanks,
Jan

  Jan

2016-02-08 22:27 GMT+01:00 Stephen Hemminger :

> On Fri,  5 Feb 2016 19:20:26 +0100
> Jan Medala  wrote:
>
> > +
> > +#ifndef PCI_VENDOR_ID_AMAZON
> > +/** Vendor ID used by Amazon devices */
> > +#define PCI_VENDOR_ID_AMAZON 0x1D0F
> > +#endif
> > +
>
> The goal is to eliminate the clobal rte_pci_dev_ids.h file, it doesn't
> scale.
>

[dpdk-dev] [PATCH v2 3/4] Amazon ENA communication layer for DPDK platform

[Jan Mędala]

Stephen,
This will be fixed

dpdk-dev,
ping for more comments/review

Thanks,
Jan

  Jan

2016-02-08 22:30 GMT+01:00 Stephen Hemminger :

> On Fri,  5 Feb 2016 19:20:28 +0100
> Jan Medala  wrote:
>
> > +
> > +typedef _Bool bool;
>
>
> > +#define true ((bool)1)
> > +#define false((bool)0)
>
> Why not just use  ??
>

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

[Hunt, David]

On 15/02/2016 10:15, Olivier MATZ wrote:
> Hi David,
>
> On 02/15/2016 10:58 AM, Hunt, David wrote:
>> On 12/02/2016 15:50, Olivier MATZ wrote:
>>> - NEXT_ABI does make the code harder to read in this case, and I'm
>>> thinking about the patchset from David Hunt (external mempool handler)
>>> that will be in the same situation, and maybe also another patchset
>>> I'm working on.
>>
>> Olivier,
>>  I'm working on that at the moment with the external mempool handler
>> code. However, it crossed my mind that we have a choice to use symbol
>> versioning OR use NEXT_ABI. Would one method be preferred over the other?
>
> I think symbol versioning should always be preferred when possible.
>
> In your case, as far as I remember, your are updating the rte_mempool
> structure, which is accessed by static inline functions. I don't think
> it is easily manageable with symbol versioning. Moreover, the ABI will
> already be broken by Keith's patch, so I think it's less problematic
> to have other patches breaking the ABI at the same time.

OK, Thanks for that. I'll use NEXT_ABI in this case so. :)

Regards,
David.

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

[Olivier MATZ]

On 02/12/2016 07:36 PM, Keith Wiles wrote:
> 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.
> 
> Change to be effective in release 16.07.
> 
> Signed-off-by: Keith Wiles 

Acked-by: Olivier Matz 
(for 16.07)

[dpdk-dev] [PATCH] doc: deprecation notice in 16.04 for rte_mempool changes

[Olivier MATZ]

Hi Keith,

On 02/12/2016 07:38 PM, Keith Wiles wrote:
> Deprecation notice for 16.04 for changes to occur in
> release 16.07 for rte_mempool memory reduction.
> 
> Signed-off-by: Keith Wiles 

Acked-by: Olivier Matz 

[dpdk-dev] DPDK (and rte_*alloc family) friendly Valgrind

[Thomas Monjalon]

2016-02-13 12:30, Luca Boccassi:
> On Thu, 2016-02-11 at 08:34 +0100, Thomas Monjalon wrote:
> > 2016-02-10 22:54, Luca Boccassi:
> >  I created a set of patches for Valgrind that add support for the
> > > rte_*alloc family of functions. We use it for memcheck (I added support
> > > for other all the other Valgrind tools like cachegrind as well, but it's
> > > less tested), and find it extremely useful, since the vanilla version
> > > cannot intercept and report leaks cause by rte_*alloc functions from
> > > librte_malloc.
> > 
> > Thank you Luca.
> > I think it deserves to be visible in the DPDK doc.
> > What about adding some explanations in
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_guides_prog-5Fguide_profile-5Fapp.html=CwICAg=IL_XqQWOjubgfqINi2jTzg=QTEM8ICX7t_SLgWP3qPWtKiwKMps487LPWQx-B9AqIc=QXy2HY_6FCRpB2dqb0AfDLoTIJ2MpHaKS_Bd5WKYgMQ=d4OWq_1QIlrYTxkCHIsQqn7p0887PWo4RaYa7PZeeII=
> >  
> > or
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_guides_prog-5Fguide_env-5Fabstraction-5Flayer.html-23malloc=CwICAg=IL_XqQWOjubgfqINi2jTzg=QTEM8ICX7t_SLgWP3qPWtKiwKMps487LPWQx-B9AqIc=QXy2HY_6FCRpB2dqb0AfDLoTIJ2MpHaKS_Bd5WKYgMQ=J36uf3GxS8AuoM2eQje4VTbXuF4WLmxGKIXM3RslaOA=
> >  
> > ?
> 
> Hi Thomas,
> 
> Thanks, anything I could help with for that to happen?

Yes, the documentation is in the git tree.
If you have time, it would be nice to send a patch on this list to
point your patches and explain how it works (below notes can be included).
The guide for doc contribution is 
http://dpdk.org/doc/guides/contributing/documentation.html

> Also, a few words about the actual implementation.
> 
> Valgrind re-implements the whole *alloc and friends internally. There is
> a common framework shared between the various tools, and each builds on
> top of it.
> 
> What I've done is to map the various rte_*alloc/free functions on top of
> Valgrind's implementation of posix_memalign/free. This was done in order
> to respect the cache alignment parameter of rte_malloc and friends. I've
> tested to make sure that this works correctly, as we rely heavily upon
> it.
> 
> I have not, however, implemented support for NUMA sockets. There is no
> such concept inside Valgrind's framework at the moment, so it would be a
> monumental task. The NUMA socket parameter will simply be ignored. I do
> not believe it would be very useful to implement support for it, as it
> doesn't add much. For the purpose of memory leaks detection, I don't
> think it matters much on which socket a memory block is allocated.
> 
> This might have an effect on cachegrind though, so it's worth noting and
> bearing it in mind when using cachegrind rather than memcheck.
> 
> I've added a note on Github.

Thanks

[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?

[Van Haaren, Harry]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
> In file included from
> /home/marc/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:42:
> /home/marc/dpdk/x86_64-native-linuxapp-clang/include/rte_memcpy.h:870:2:
> error: implicit declaration of function '_mm_alignr_epi8' is invalid in
> C99
>   [-Werror,-Wimplicit-function-declaration]
> MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
> ^

Can reproduce this here, Ubuntu clang version 3.6.2-1 (tags/RELEASE_362/final) 
(based on LLVM 3.6.2)
This issue seems to be caused by a lack of intrinsic CFLAGS, clang and GCC 
build output with make V=1 on the same machine (unnecessary output stripped):


clang -Wp,-MD,./.eal_pci.o.d.tmp -m64 -pthread  -march=native 
-DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 
-DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2


gcc -Wp,-MD,./.eal_pci.o.d.tmp -m64 -pthread -fPIC  -march=native 
-DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSE3 
-DRTE_MACHINE_CPUFLAG_SSSE3 -DRTE_MACHINE_CPUFLAG_SSE4_1 
-DRTE_MACHINE_CPUFLAG_SSE4_2 -DRTE_MACHINE_CPUFLAG_AES 
-DRTE_MACHINE_CPUFLAG_PCLMULQDQ -DRTE_MACHINE_CPUFLAG_AVX 
-DRTE_MACHINE_CPUFLAG_RDRAND -DRTE_MACHINE_CPUFLAG_FSGSBASE 
-DRTE_MACHINE_CPUFLAG_F16C -DRTE_MACHINE_CPUFLAG_AVX2 
-DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSE3,RTE_CPUFLAG_SSSE3,RTE_CPUFLAG_SSE4_1,RTE_CPUFLAG_SSE4_2,RTE_CPUFLAG_AES,RTE_CPUFLAG_PCLMULQDQ,RTE_CPUFLAG_AVX,RTE_CPUFLAG_RDRAND,RTE_CPUFLAG_FSGSBASE,RTE_CPUFLAG_F16C,RTE_CPUFLAG_AVX2


There is no copy-paste error above: the clang intrinsic CFLAGS is much shorter 
than GCC.

Strangely, this issue also exists when building i686 gcc target *on a 32bit 
host/VM*. Git bisect shows that this issue exists on 32bit target / 32bit host 
since commit 9144d6b, which optimized eal/x86 rte_memcpy.

It looks like the build-system is not correctly identifying the intrinsics to 
build with. I've had a look through mk/toolchain/clang/*  and 
mk/rte.cpuflags.mk  but haven't seen anything I think could be the cause...

Perhaps somebody with familiarity with the build system could take a look?

-Harry

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

[Hunt, David]

On 12/02/2016 15:50, Olivier MATZ wrote:
> - NEXT_ABI does make the code harder to read in this case, and I'm
>thinking about the patchset from David Hunt (external mempool handler)
>that will be in the same situation, and maybe also another patchset
>I'm working on.

Olivier,
 I'm working on that at the moment with the external mempool handler 
code. However, it crossed my mind that we have a choice to use symbol 
versioning OR use NEXT_ABI. Would one method be preferred over the other?
Regards,
David.

[dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API

[Nélio Laranjeiro]

On Sun, Feb 14, 2016 at 11:17:38PM +0100, Marc Sune wrote:
> This patch redesigns the API to set the link speed/s configure
> for an ethernet port. Specifically:
> 
> - it allows to define a set of advertised speeds for
>   auto-negociation.
> - it allows to disable link auto-negociation (single fixed speed).
> - default: auto-negociate all supported speeds.
> 
>[...]
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index c5688a7..01c3a5c 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -4265,8 +4265,8 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
> rte_eth_dev_info *info)
>   if (priv_get_ifname(priv, ) == 0)
>   info->if_index = if_nametoindex(ifname);
>  
> - info->speed_capa = ETH_SPEED_CAP_10G |ETH_SPEED_CAP_40G |
> - ETH_SPEED_CAP_56G;
> + info->speed_capa = ETH_LINK_SPEED_10G |ETH_LINK_SPEED_40G |
> + ETH_LINK_SPEED_56G;
>  
>   priv_unlock(priv);
>  }
> @@ -4636,6 +4636,8 @@ mlx4_link_update_unlocked(struct rte_eth_dev *dev, int 
> wait_to_complete)
>   dev_link.link_speed = link_speed;
>   dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
>   ETH_LINK_HALF_DUPLEX : ETH_LINK_FULL_DUPLEX);
> + dev_link.link_autoneg = ~(dev->data->dev_conf.link_speeds &
> + ETH_LINK_SPEED_NO_AUTONEG);
>   if (memcmp(_link, >data->dev_link, sizeof(dev_link))) {
>   /* Link status changed. */
>   dev->data->dev_link = dev_link;
>[...]

The same modification are missing in mlx5.

-- 
N?lio Laranjeiro
6WIND

[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?

[Mcnamara, John]

> -Original Message-
> From: Mcnamara, John
> Sent: Monday, February 15, 2016 9:39 AM
> To: 'Marc' ; dev at dpdk.org
> Subject: RE: [dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
> > Sent: Sunday, February 14, 2016 10:21 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
> >
> > It seems compilation for clang Linux target is broken:
> >
> > In file included from
> > /home/marc/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:42:
> > /home/marc/dpdk/x86_64-native-linuxapp-clang/include/rte_memcpy.h:870:2:
> > error: implicit declaration of function '_mm_alignr_epi8' is invalid in
> > C99
> >   [-Werror,-Wimplicit-function-declaration]
> > MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
> > ^
> > ...
> >
> > marc at dpdk:~/dpdk$ clang --version
> > Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM
> > 3.5.0)
> > Target: x86_64-pc-linux-gnu
> > Thread model: posix
> 
> Hi,
> 
> It compiles ok for me with the latest HEAD and clang 3.70:
> 
> $ make install -j T=x86_64-native-linuxapp-clang CC=/usr/bin/clang
> ...
> Build complete [x86_64-native-linuxapp-clang]
> ...
> 
> 
> $ clang --version
> clang version 3.7.0 (tags/RELEASE_370/final)
> Target: x86_64-redhat-linux-gnu
> Thread model: posix
> 
> I do have to avoid using the ccached clang since it gives a (different)
> error about macro expansions. However, that isn't the issue you are
> seeing.
> 

P.S.

I see that similar, but not quite the same errors, if I use the -gcc target 
with clang:

$ make install -j T=x86_64-native-linuxapp-gcc CC=/usr/bin/clang

John

[dpdk-dev] [PATCH v8 2/4] ethdev: Fill speed capability bitmaps in the PMDs

[Nélio Laranjeiro]

On Sun, Feb 14, 2016 at 11:17:37PM +0100, Marc Sune wrote:
> Added speed capabilities to all pmds supporting physical NICs:
> 
> * e1000
> * ixgbe
> * i40
> * bnx2x
> * cxgbe
> * mlx4
> * mlx5
> * nfp
> * fm10k
>[...]
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> index 1159fa3..99dac09 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -523,6 +523,11 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct 
> rte_eth_dev_info *info)
>* size if it is not fixed.
>* The API should be updated to solve this problem. */
>   info->reta_size = priv->ind_table_max_size;
> +
> + info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G |
> + ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G |
> + ETH_SPEED_CAP_56G;
> +
>   priv_unlock(priv);
>  }

Hi Marc,

I have a question about this information, is it a list of the
capabilities of the family or the capability of the NIC?
Because with ConnectX4 family we have a range of NICs which does not
support all this kind of speeds.

The speeds above are not completed the range is 1/10/25/40/50/100G.

-- 
N?lio Laranjeiro
6WIND

[dpdk-dev] [PATCH v2 0/7] support E-tag offloading and forwarding on Intel X550 NIC

[De Lara Guarch, Pablo]

Hi,

> -Original Message-
> From: Lu, Wenzhuo
> Sent: Monday, February 15, 2016 1:21 AM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 0/7] support E-tag offloading and
> forwarding on Intel X550 NIC
> 
> Hi Pablo,
> 
> > -Original Message-
> > From: De Lara Guarch, Pablo
> > Sent: Friday, February 12, 2016 9:50 PM
> > To: Lu, Wenzhuo; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH v2 0/7] support E-tag offloading and
> forwarding
> > on Intel X550 NIC
> >
> > Hi Wenzhuo,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> > > Sent: Tuesday, February 02, 2016 6:57 AM
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] [PATCH v2 0/7] support E-tag offloading and
> > > forwarding on Intel X550 NIC
> > >
> > > This patch set adds the support of E-tag offloading and forwarding on
> > > X550.
> > > The offloading means E-tag can be inserted and stripped by HW.
> > > And E-tag packets can be recognized and forwarded to specific pools
> > > based on GRP and E-CID_base in E-tag.
> > >
> > > Wenzhuo Lu (7):
> > >   ixgbe: select pool by MAC when using double VLAN
> > >   lib/librte_ether: support l2 tunnel config
> > >   ixgbe: support l2 tunnel config
> > >   app/testpmd: add CLIs for l2 tunnel config
> > >   lib/librte_ether: support new l2 tunnel operation
> > >   ixgbe: support l2 tunnel operation
> > >   app/testpmd: add CLIs for E-tag operation
> > >
> > >  app/test-pmd/cmdline.c   | 599
> > > +++
> > >  doc/guides/rel_notes/release_2_3.rst |   6 +
> > >  drivers/net/ixgbe/ixgbe_ethdev.c | 507
> > > +
> > >  lib/librte_ether/rte_eth_ctrl.h  |   9 +
> > >  lib/librte_ether/rte_ethdev.c| 239 ++
> > >  lib/librte_ether/rte_ethdev.h| 288 +
> > >  6 files changed, 1648 insertions(+)
> > >
> > > --
> > > 1.9.3
> >
> > Could you add the new commands in testpmd documentation?
> Thanks for the reminder. Just to confirm that the testpmd documentation
> you mentioned is doc/guides/testpmd_app_ug/testpmd_funcs.rst, right?
> 
That's correct.
Thanks!
> > (and rebase your patchset, to include the new release_16_04.rst file)

[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
> Sent: Sunday, February 14, 2016 10:21 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
> 
> It seems compilation for clang Linux target is broken:
> 
> In file included from
> /home/marc/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:42:
> /home/marc/dpdk/x86_64-native-linuxapp-clang/include/rte_memcpy.h:870:2:
> error: implicit declaration of function '_mm_alignr_epi8' is invalid in
> C99
>   [-Werror,-Wimplicit-function-declaration]
> MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
> ^
> ...
> 
> marc at dpdk:~/dpdk$ clang --version
> Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM
> 3.5.0)
> Target: x86_64-pc-linux-gnu
> Thread model: posix

Hi,

It compiles ok for me with the latest HEAD and clang 3.70:

$ make install -j T=x86_64-native-linuxapp-clang CC=/usr/bin/clang
...
Build complete [x86_64-native-linuxapp-clang]
...


$ clang --version
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix

I do have to avoid using the ccached clang since it gives a (different) error 
about macro expansions. However, that isn't the issue you are seeing.

John

[dpdk-dev] [PATCH v8 2/4] ethdev: Fill speed capability bitmaps in the PMDs

[Chen, Jing D]

Hi, Marc,

Best Regards,
Mark

> -Original Message-
> From: N?lio Laranjeiro [mailto:nelio.laranjeiro at 6wind.com]
> Sent: Monday, February 15, 2016 4:43 PM
> To: Marc Sune
> Cc: dev at dpdk.org; Lu, Wenzhuo; Zhang, Helin; Harish Patil; Chen, Jing D
> Subject: Re: [dpdk-dev] [PATCH v8 2/4] ethdev: Fill speed capability bitmaps
> in the PMDs
> 
> On Sun, Feb 14, 2016 at 11:17:37PM +0100, Marc Sune wrote:
> > Added speed capabilities to all pmds supporting physical NICs:
> >
> > * e1000
> > * ixgbe
> > * i40
> > * bnx2x
> > * cxgbe
> > * mlx4
> > * mlx5
> > * nfp
> > * fm10k
> >[...]
> > diff --git a/drivers/net/mlx5/mlx5_ethdev.c
> b/drivers/net/mlx5/mlx5_ethdev.c
> > index 1159fa3..99dac09 100644
> > --- a/drivers/net/mlx5/mlx5_ethdev.c
> > +++ b/drivers/net/mlx5/mlx5_ethdev.c
> > @@ -523,6 +523,11 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev,
> struct rte_eth_dev_info *info)
> >  * size if it is not fixed.
> >  * The API should be updated to solve this problem. */
> > info->reta_size = priv->ind_table_max_size;
> > +
> > +   info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G |
> > +   ETH_SPEED_CAP_10G |
> ETH_SPEED_CAP_40G |
> > +   ETH_SPEED_CAP_56G;
> > +
> > priv_unlock(priv);
> >  }
> 
> Hi Marc,
> 
> I have a question about this information, is it a list of the
> capabilities of the family or the capability of the NIC?
> Because with ConnectX4 family we have a range of NICs which does not
> support all this kind of speeds.
> 
> The speeds above are not completed the range is 1/10/25/40/50/100G.
> 

Fm10k also includes several cards and different ones are designed to have 
different speed.
A better solution for fm10k is to acquire NIC type (like, BR card for 100G/40G, 
Atwood for 25/10G, etc)
Then, return proper speed.

> --
> N?lio Laranjeiro
> 6WIND

[dpdk-dev] [PATCH v2] ixgbe: support multicast promiscuous mode on VF

[Lu, Wenzhuo]

Hi Xiao,

> -Original Message-
> From: Wang, Xiao W
> Sent: Monday, February 15, 2016 4:10 PM
> To: Lu, Wenzhuo; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2] ixgbe: support multicast promiscuous mode
> on VF
> 
> Hi,
> 
> Best Regards,
> Wang, Xiao
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> > Sent: Sunday, February 14, 2016 2:25 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v2] ixgbe: support multicast promiscuous
> > mode on VF
> >
> > Add multicast promiscuous mode support on ixgbe VF driver.
> >
> > Please note if we want to use this promiscuous mode, we need both PF
> > and VF driver to support it. The reason is this VF feature is configged on 
> > PF.
> > If use kernel PF driver + dpdk VF driver, make sure kernel PF driver
> > support VF multicast promiscuous mode. If use dpdk PF + dpdk VF,
> > better make sure PF driver is the same version as VF.
> >
> > V2:
> >  Update release note.
> 
> Maybe it's better to put change log below the "---"
> 
> >
> > Signed-off-by: Wenzhuo Lu 
> > Acked-by: Shaopeng He 
> > ---
> >  doc/guides/rel_notes/release_16_04.rst | 11 ++
> >  drivers/net/ixgbe/base/ixgbe_mbx.h |  4 +++
> >  drivers/net/ixgbe/ixgbe_ethdev.c   | 66
> > ++
> >  drivers/net/ixgbe/ixgbe_pf.c   | 65
> > +
> >  4 files changed, 146 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/release_16_04.rst
> > b/doc/guides/rel_notes/release_16_04.rst
> > index 27fc624..e71d316 100644
> > --- a/doc/guides/rel_notes/release_16_04.rst
> > +++ b/doc/guides/rel_notes/release_16_04.rst
> > @@ -39,6 +39,17 @@ This section should contain new features added in
> > this release. Sample format:
> >
> >Enabled virtio 1.0 support for virtio pmd driver.
> >
> > +* **Added multicast promiscuous mode support on VF for ixgbe.**
> > +
> > +  Added multicast promiscuous mode support on ixgbe VF driver. So all
> > + the VFs  can receive the multicast packets.
> > +
> > +  Please note if we want to use this promiscuous mode, we need both
> > + PF and VF  driver to support it. The reason is this VF feature is 
> > configged on
> PF.
> > +  If use kernel PF driver + dpdk VF driver, make sure kernel PF
> > + driver support  VF multicast promiscuous mode. If use dpdk PF + dpdk
> > + VF, better make sure PF  driver is the same version as VF.
> > +
> >
> >  Resolved Issues
> >  ---
> > diff --git a/drivers/net/ixgbe/base/ixgbe_mbx.h
> > b/drivers/net/ixgbe/base/ixgbe_mbx.h
> > index 445df10..4a120a3 100644
> > --- a/drivers/net/ixgbe/base/ixgbe_mbx.h
> > +++ b/drivers/net/ixgbe/base/ixgbe_mbx.h
> > @@ -89,6 +89,7 @@ enum ixgbe_pfvf_api_rev {
> > ixgbe_mbox_api_10,  /* API version 1.0, linux/freebsd VF driver */
> > ixgbe_mbox_api_20,  /* API version 2.0, solaris Phase1 VF driver */
> > ixgbe_mbox_api_11,  /* API version 1.1, linux/freebsd VF driver */
> > +   ixgbe_mbox_api_12,  /* API version 1.2, linux/freebsd VF driver */
> > /* This value should always be last */
> > ixgbe_mbox_api_unknown, /* indicates that API version is not
> > known */
> >  };
> > @@ -107,6 +108,9 @@ enum ixgbe_pfvf_api_rev {
> >  /* mailbox API, version 1.1 VF requests */
> >  #define IXGBE_VF_GET_QUEUES0x09 /* get queue configuration */
> >
> > +/* mailbox API, version 1.2 VF requests */
> > +#define IXGBE_VF_UPDATE_XCAST_MODE 0x0C
> > +
> >  /* GET_QUEUES return data indices within the mailbox */
> >  #define IXGBE_VF_TX_QUEUES 1   /* number of Tx queues
> supported */
> >  #define IXGBE_VF_RX_QUEUES 2   /* number of Rx queues
> supported */
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 3e6fe86..82ba755 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -138,6 +138,12 @@
> >
> >  #define IXGBE_CYCLECOUNTER_MASK   0xULL
> >
> > +enum ixgbevf_xcast_modes {
> > +   IXGBEVF_XCAST_MODE_NONE = 0,
> > +   IXGBEVF_XCAST_MODE_MULTI,
> > +   IXGBEVF_XCAST_MODE_ALLMULTI,
> > +};
> > +
> >  static int eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev);  static
> > int eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev);  static int
> > ixgbe_dev_configure(struct rte_eth_dev *dev); @@ -237,6 +243,8 @@
> > static int ixgbevf_dev_rx_queue_intr_disable(struct rte_eth_dev *dev,
> > static void ixgbevf_set_ivar_map(struct ixgbe_hw *hw, int8_t direction,
> >  uint8_t queue, uint8_t msix_vector);  static
> void
> > ixgbevf_configure_msix(struct rte_eth_dev *dev);
> > +static void ixgbevf_dev_allmulticast_enable(struct rte_eth_dev *dev);
> > +static void ixgbevf_dev_allmulticast_disable(struct rte_eth_dev
> > +*dev);
> >
> >  /* For Eth VMDQ APIs support */
> >  static int ixgbe_uc_hash_table_set(struct rte_eth_dev *dev, struct @@
> > -511,6
> > +519,8 @@ static const struct eth_dev_ops 

[dpdk-dev] [PATCH v2] ixgbe: support multicast promiscuous mode on VF

[Wang, Xiao W]

Hi,

Best Regards,
Wang, Xiao

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Sunday, February 14, 2016 2:25 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] ixgbe: support multicast promiscuous mode on
> VF
> 
> Add multicast promiscuous mode support on ixgbe VF driver.
> 
> Please note if we want to use this promiscuous mode, we need both PF and VF
> driver to support it. The reason is this VF feature is configged on PF.
> If use kernel PF driver + dpdk VF driver, make sure kernel PF driver support 
> VF
> multicast promiscuous mode. If use dpdk PF + dpdk VF, better make sure PF
> driver is the same version as VF.
> 
> V2:
>  Update release note.

Maybe it's better to put change log below the "---"

> 
> Signed-off-by: Wenzhuo Lu 
> Acked-by: Shaopeng He 
> ---
>  doc/guides/rel_notes/release_16_04.rst | 11 ++
>  drivers/net/ixgbe/base/ixgbe_mbx.h |  4 +++
>  drivers/net/ixgbe/ixgbe_ethdev.c   | 66
> ++
>  drivers/net/ixgbe/ixgbe_pf.c   | 65
> +
>  4 files changed, 146 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/release_16_04.rst
> b/doc/guides/rel_notes/release_16_04.rst
> index 27fc624..e71d316 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -39,6 +39,17 @@ This section should contain new features added in this
> release. Sample format:
> 
>Enabled virtio 1.0 support for virtio pmd driver.
> 
> +* **Added multicast promiscuous mode support on VF for ixgbe.**
> +
> +  Added multicast promiscuous mode support on ixgbe VF driver. So all
> + the VFs  can receive the multicast packets.
> +
> +  Please note if we want to use this promiscuous mode, we need both PF
> + and VF  driver to support it. The reason is this VF feature is configged on 
> PF.
> +  If use kernel PF driver + dpdk VF driver, make sure kernel PF driver
> + support  VF multicast promiscuous mode. If use dpdk PF + dpdk VF,
> + better make sure PF  driver is the same version as VF.
> +
> 
>  Resolved Issues
>  ---
> diff --git a/drivers/net/ixgbe/base/ixgbe_mbx.h
> b/drivers/net/ixgbe/base/ixgbe_mbx.h
> index 445df10..4a120a3 100644
> --- a/drivers/net/ixgbe/base/ixgbe_mbx.h
> +++ b/drivers/net/ixgbe/base/ixgbe_mbx.h
> @@ -89,6 +89,7 @@ enum ixgbe_pfvf_api_rev {
>   ixgbe_mbox_api_10,  /* API version 1.0, linux/freebsd VF driver */
>   ixgbe_mbox_api_20,  /* API version 2.0, solaris Phase1 VF driver */
>   ixgbe_mbox_api_11,  /* API version 1.1, linux/freebsd VF driver */
> + ixgbe_mbox_api_12,  /* API version 1.2, linux/freebsd VF driver */
>   /* This value should always be last */
>   ixgbe_mbox_api_unknown, /* indicates that API version is not
> known */
>  };
> @@ -107,6 +108,9 @@ enum ixgbe_pfvf_api_rev {
>  /* mailbox API, version 1.1 VF requests */
>  #define IXGBE_VF_GET_QUEUES  0x09 /* get queue configuration */
> 
> +/* mailbox API, version 1.2 VF requests */
> +#define IXGBE_VF_UPDATE_XCAST_MODE 0x0C
> +
>  /* GET_QUEUES return data indices within the mailbox */
>  #define IXGBE_VF_TX_QUEUES   1   /* number of Tx queues supported */
>  #define IXGBE_VF_RX_QUEUES   2   /* number of Rx queues supported */
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 3e6fe86..82ba755 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -138,6 +138,12 @@
> 
>  #define IXGBE_CYCLECOUNTER_MASK   0xULL
> 
> +enum ixgbevf_xcast_modes {
> + IXGBEVF_XCAST_MODE_NONE = 0,
> + IXGBEVF_XCAST_MODE_MULTI,
> + IXGBEVF_XCAST_MODE_ALLMULTI,
> +};
> +
>  static int eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev);  static int
> eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev);  static int
> ixgbe_dev_configure(struct rte_eth_dev *dev); @@ -237,6 +243,8 @@ static
> int ixgbevf_dev_rx_queue_intr_disable(struct rte_eth_dev *dev,  static void
> ixgbevf_set_ivar_map(struct ixgbe_hw *hw, int8_t direction,
>uint8_t queue, uint8_t msix_vector);  static
> void ixgbevf_configure_msix(struct rte_eth_dev *dev);
> +static void ixgbevf_dev_allmulticast_enable(struct rte_eth_dev *dev);
> +static void ixgbevf_dev_allmulticast_disable(struct rte_eth_dev *dev);
> 
>  /* For Eth VMDQ APIs support */
>  static int ixgbe_uc_hash_table_set(struct rte_eth_dev *dev, struct @@ -511,6
> +519,8 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
>   .stats_reset  = ixgbevf_dev_stats_reset,
>   .xstats_reset = ixgbevf_dev_stats_reset,
>   .dev_close= ixgbevf_dev_close,
> + .allmulticast_enable  = ixgbevf_dev_allmulticast_enable,
> + .allmulticast_disable = ixgbevf_dev_allmulticast_disable,
>   .dev_infos_get= ixgbevf_dev_info_get,
>   .mtu_set  = ixgbevf_dev_set_mtu,
>   

[dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load

[Lu, Wenzhuo]

Hi Konstantin,

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Friday, February 5, 2016 2:55 AM
> To: Lu, Wenzhuo; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX
> checksum off-load
> 
> Hi Wenzhuo,
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> > Sent: Thursday, January 14, 2016 1:39 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX
> > checksum off-load
> >
> > The patch add VxLAN & NVGRE TX checksum off-load. When the flag of
> > outer IP header checksum offload is set, we'll set the context
> > descriptor to enable this checksum off-load.
> >
> > Signed-off-by: Wenzhuo Lu 
> > ---
> >  drivers/net/ixgbe/ixgbe_rxtx.c | 52
> > ++
> >  drivers/net/ixgbe/ixgbe_rxtx.h |  6 -
> >  lib/librte_mbuf/rte_mbuf.h |  2 ++
> >  3 files changed, 49 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c
> > b/drivers/net/ixgbe/ixgbe_rxtx.c index 512ac3a..fea2495 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > @@ -85,7 +85,8 @@
> > PKT_TX_VLAN_PKT |\
> > PKT_TX_IP_CKSUM |\
> > PKT_TX_L4_MASK | \
> > -   PKT_TX_TCP_SEG)
> > +   PKT_TX_TCP_SEG | \
> > +   PKT_TX_OUTER_IP_CKSUM)
> 
> 
> I think you also need to update dev_info.tx_offload_capa, couldn't find where
> you doing it.
My bad. I'll add it. Thanks.

> 
> >
> >  static inline struct rte_mbuf *
> >  rte_rxmbuf_alloc(struct rte_mempool *mp) @@ -364,9 +365,11 @@
> > ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
> > uint32_t ctx_idx;
> > uint32_t vlan_macip_lens;
> > union ixgbe_tx_offload tx_offload_mask;
> > +   uint32_t seqnum_seed = 0;
> >
> > ctx_idx = txq->ctx_curr;
> > -   tx_offload_mask.data = 0;
> > +   tx_offload_mask.data[0] = 0;
> > +   tx_offload_mask.data[1] = 0;
> > type_tucmd_mlhl = 0;
> >
> > /* Specify which HW CTX to upload. */ @@ -430,9 +433,20 @@
> > ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
> > }
> > }
> >
> > +   if (ol_flags & PKT_TX_OUTER_IP_CKSUM) {
> > +   tx_offload_mask.outer_l3_len |= ~0;
> > +   tx_offload_mask.outer_l2_len |= ~0;
> > +   seqnum_seed |= tx_offload.outer_l3_len
> > +  << IXGBE_ADVTXD_OUTER_IPLEN;
> > +   seqnum_seed |= tx_offload.outer_l2_len
> > +  << IXGBE_ADVTXD_TUNNEL_LEN;
> > +   }
> 
> I don't have an X550 card off-hand, but reading through datasheet - it doesn't
> seem right.
> When OUTER_IP_CKSUM is enabled MACLEN becomes outer_l2_len and
> TUNNEL_LEN should be: outer_l4_len + tunnel_hdr_len + inner_l2_len.
> So I think that in our case TUNNEL_LEN should be set to l2_len.
Yes, you're right. I made a mistake here. Will correct it. Thanks.

> 
> > +
> > txq->ctx_cache[ctx_idx].flags = ol_flags;
> > -   txq->ctx_cache[ctx_idx].tx_offload.data  =
> > -   tx_offload_mask.data & tx_offload.data;
> > +   txq->ctx_cache[ctx_idx].tx_offload.data[0]  =
> > +   tx_offload_mask.data[0] & tx_offload.data[0];
> > +   txq->ctx_cache[ctx_idx].tx_offload.data[1]  =
> > +   tx_offload_mask.data[1] & tx_offload.data[1];
> > txq->ctx_cache[ctx_idx].tx_offload_mask= tx_offload_mask;
> >
> > ctx_txd->type_tucmd_mlhl = rte_cpu_to_le_32(type_tucmd_mlhl);
> > @@ -441,7 +455,7 @@ ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
> > vlan_macip_lens |= ((uint32_t)tx_offload.vlan_tci <<
> IXGBE_ADVTXD_VLAN_SHIFT);
> > ctx_txd->vlan_macip_lens = rte_cpu_to_le_32(vlan_macip_lens);
> > ctx_txd->mss_l4len_idx   = rte_cpu_to_le_32(mss_l4len_idx);
> > -   ctx_txd->seqnum_seed = 0;
> > +   ctx_txd->seqnum_seed = seqnum_seed;
> >  }
> >
> >  /*
> > @@ -454,16 +468,24 @@ what_advctx_update(struct ixgbe_tx_queue *txq,
> > uint64_t flags,  {
> > /* If match with the current used context */
> > if (likely((txq->ctx_cache[txq->ctx_curr].flags == flags) &&
> > -   (txq->ctx_cache[txq->ctx_curr].tx_offload.data ==
> > -   (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data &
> tx_offload.data {
> > +   (txq->ctx_cache[txq->ctx_curr].tx_offload.data[0] ==
> > +   (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data[0]
> > +& tx_offload.data[0])) &&
> > +   (txq->ctx_cache[txq->ctx_curr].tx_offload.data[1] ==
> > +   (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data[1]
> > +& tx_offload.data[1] {
> > return txq->ctx_curr;
> > }
> >
> > /* What if match with the next context  */
> > txq->ctx_curr ^= 1;
> > if (likely((txq->ctx_cache[txq->ctx_curr].flags == flags) &&
> > -   (txq->ctx_cache[txq->ctx_curr].tx_offload.data ==
> > -   

[dpdk-dev] [PATCH v2 4/6] ixgbe: support VxLAN & NVGRE RX checksum off-load

[Lu, Wenzhuo]

Hi Konstantin,

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Friday, February 5, 2016 4:17 AM
> To: Lu, Wenzhuo; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 4/6] ixgbe: support VxLAN & NVGRE RX
> checksum off-load
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> > Sent: Thursday, January 14, 2016 1:39 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v2 4/6] ixgbe: support VxLAN & NVGRE RX
> > checksum off-load
> >
> > X550 will do VxLAN & NVGRE RX checksum off-load automatically.
> > This patch exposes the result of the checksum off-load.
> >
> > Signed-off-by: Wenzhuo Lu 
> > ---
> >  drivers/net/ixgbe/ixgbe_rxtx.c | 11 ++-
> >  lib/librte_mbuf/rte_mbuf.c |  1 +
> >  lib/librte_mbuf/rte_mbuf.h |  1 +
> >  3 files changed, 12 insertions(+), 1 deletion(-)
> 
> 
> Do we need a new DEV_RX_OFFLOAD_ here?
Yes, I will add a new capability. Thanks.

> 
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c
> > b/drivers/net/ixgbe/ixgbe_rxtx.c index 52a263c..512ac3a 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > @@ -1003,6 +1003,8 @@ rx_desc_status_to_pkt_flags(uint32_t rx_status)
> > static inline uint64_t  rx_desc_error_to_pkt_flags(uint32_t rx_status)
> > {
> > +   uint64_t pkt_flags;
> > +
> > /*
> >  * Bit 31: IPE, IPv4 checksum error
> >  * Bit 30: L4I, L4I integrity error
> > @@ -1011,8 +1013,15 @@ rx_desc_error_to_pkt_flags(uint32_t rx_status)
> > 0,  PKT_RX_L4_CKSUM_BAD, PKT_RX_IP_CKSUM_BAD,
> > PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD
> > };
> > -   return error_to_pkt_flags_map[(rx_status >>
> > +   pkt_flags = error_to_pkt_flags_map[(rx_status >>
> > IXGBE_RXDADV_ERR_CKSUM_BIT) &
> IXGBE_RXDADV_ERR_CKSUM_MSK];
> > +
> > +   if ((rx_status & IXGBE_RXD_STAT_OUTERIPCS) &&
> > +   (rx_status & IXGBE_RXDADV_ERR_OUTERIPER)) {
> > +   pkt_flags |= PKT_RX_OUTER_IP_CKSUM_BAD;
> > +   }
> > +
> > +   return pkt_flags;
> >  }
> >
> >  /*
> > diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> > index c18b438..5d4af39 100644
> > --- a/lib/librte_mbuf/rte_mbuf.c
> > +++ b/lib/librte_mbuf/rte_mbuf.c
> > @@ -260,6 +260,7 @@ const char *rte_get_rx_ol_flag_name(uint64_t mask)
> > /* case PKT_RX_MAC_ERR: return "PKT_RX_MAC_ERR"; */
> > case PKT_RX_IEEE1588_PTP: return "PKT_RX_IEEE1588_PTP";
> > case PKT_RX_IEEE1588_TMST: return "PKT_RX_IEEE1588_TMST";
> > +   case PKT_RX_OUTER_IP_CKSUM_BAD: return
> "PKT_RX_OUTER_IP_CKSUM_BAD";
> > default: return NULL;
> > }
> >  }
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index f234ac9..5ad5e59 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -98,6 +98,7 @@ extern "C" {
> >  #define PKT_RX_FDIR_ID   (1ULL << 13) /**< FD id reported if FDIR 
> > match.
> */
> >  #define PKT_RX_FDIR_FLX  (1ULL << 14) /**< Flexible bytes reported if 
> > FDIR
> match. */
> >  #define PKT_RX_QINQ_PKT  (1ULL << 15)  /**< RX packet with double VLAN
> stripped. */
> > +#define PKT_RX_OUTER_IP_CKSUM_BAD (1ULL << 16)  /**< Outer IP cksum
> > +of RX pkt. is not OK. */
> 
> There is
> #define PKT_RX_EIP_CKSUM_BAD (0ULL << 0)  /**< External IP header
> checksum error. */ Probably need either redefine it, or remove it.
O, agree. I should redefine it. Thanks.

> 
> Konstantin
> >  /* add new RX flags here */
> >
> >  /* add new TX flags here */
> > --
> > 1.9.3

[dpdk-dev] [PATCH v2 0/7] support E-tag offloading and forwarding on Intel X550 NIC

[Lu, Wenzhuo]

Hi Pablo,

> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Friday, February 12, 2016 9:50 PM
> To: Lu, Wenzhuo; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 0/7] support E-tag offloading and forwarding
> on Intel X550 NIC
> 
> Hi Wenzhuo,
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> > Sent: Tuesday, February 02, 2016 6:57 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v2 0/7] support E-tag offloading and
> > forwarding on Intel X550 NIC
> >
> > This patch set adds the support of E-tag offloading and forwarding on
> > X550.
> > The offloading means E-tag can be inserted and stripped by HW.
> > And E-tag packets can be recognized and forwarded to specific pools
> > based on GRP and E-CID_base in E-tag.
> >
> > Wenzhuo Lu (7):
> >   ixgbe: select pool by MAC when using double VLAN
> >   lib/librte_ether: support l2 tunnel config
> >   ixgbe: support l2 tunnel config
> >   app/testpmd: add CLIs for l2 tunnel config
> >   lib/librte_ether: support new l2 tunnel operation
> >   ixgbe: support l2 tunnel operation
> >   app/testpmd: add CLIs for E-tag operation
> >
> >  app/test-pmd/cmdline.c   | 599
> > +++
> >  doc/guides/rel_notes/release_2_3.rst |   6 +
> >  drivers/net/ixgbe/ixgbe_ethdev.c | 507
> > +
> >  lib/librte_ether/rte_eth_ctrl.h  |   9 +
> >  lib/librte_ether/rte_ethdev.c| 239 ++
> >  lib/librte_ether/rte_ethdev.h| 288 +
> >  6 files changed, 1648 insertions(+)
> >
> > --
> > 1.9.3
> 
> Could you add the new commands in testpmd documentation?
Thanks for the reminder. Just to confirm that the testpmd documentation you 
mentioned is doc/guides/testpmd_app_ug/testpmd_funcs.rst, right?

> (and rebase your patchset, to include the new release_16_04.rst file)

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

[Lu, Wenzhuo]

Hi Yury,

> -Original Message-
> From: Kylulin, Yury
> Sent: Tuesday, February 9, 2016 5:10 PM
> To: dev at dpdk.org
> Cc: Kylulin, Yury; Lu, Wenzhuo
> Subject: [PATCH v2] e1000: enable promiscuous and allmulticast support for VF
> 
> 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); }
Comparing with PF, I think PF will enable multicast promiscuous mode no matter 
dev->data->promiscuous is 0 or not.
Should the VF have the same behavior? 

> +
> +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