[dpdk-dev] [PATCH v2] vmxnet3: fix Rx deadlock

[Stefan Puiu]

Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, no packets will be received after this;
nobody retries this later, so the driver gets stuck in this state. I
call this a deadlock for lack of a better term - the virtual HW waits
for free mbufs, while the app waits for the hardware to notify it for
data. Note that after this, the app can't recover.

This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port it,
address review comments and also reverted the allocation failure
handing to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since that's
the only approach that seems to work, and seems to be what other
drivers are doing (I checked ixgbe and em). Reusing the mbuf that's
getting passed to the application doesn't seem to make sense, and it
was causing weird issues in our app. Also, reusing rxm without
checking if it's NULL could cause the code to crash.

v2:
- address review comments, reworded description a bit
---
 drivers/net/vmxnet3/vmxnet3_rxtx.c | 39 --
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c 
b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..93db10f 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@
return nb_tx;
 }
 
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+  struct rte_mbuf *mbuf)
+{
+   uint32_t val = 0;
+   struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+   struct Vmxnet3_RxDesc *rxd =
+   (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+   vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+   if (ring_id == 0)
+   val = VMXNET3_RXD_BTYPE_HEAD;
+   else
+   val = VMXNET3_RXD_BTYPE_BODY;
+
+   buf_info->m = mbuf;
+   buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+   buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+   rxd->addr = buf_info->bufPA;
+   rxd->btype = val;
+   rxd->len = buf_info->len;
+   rxd->gen = ring->gen;
+
+   vmxnet3_cmd_ring_adv_next2fill(ring);
+}
 /*
  *  Allocates mbufs and clusters. Post rx descriptors with buffer details
  *  so that device can receive packets in those buffers.
@@ -657,9 +683,18 @@
}
 
while (rcd->gen == rxq->comp_ring.gen) {
+   struct rte_mbuf *newm;
+
if (nb_rx >= nb_pkts)
break;
 
+   newm = rte_mbuf_raw_alloc(rxq->mp);
+   if (unlikely(newm == NULL)) {
+   PMD_RX_LOG(ERR, "Error allocating mbuf");
+   rxq->stats.rx_buf_alloc_failure++;
+   break;
+   }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +794,8 @@
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
  rxq->cmd_ring[ring_idx].size);
 
-   /* It's time to allocate some new buf and renew descriptors */
-   vmxnet3_post_rx_bufs(rxq, ring_idx);
+   /* It's time to renew descriptors */
+   vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] + 
(rxq->queue_id * VMXNET3_REG_ALIGN),
   
rxq->cmd_ring[ring_idx].next2fill);
-- 
1.9.1

Re: [dpdk-dev] [PATCH] vmxnet3: fix Rx deadlock

[Stefan Puiu]

Hello and thanks for reviewing the patch.

On Wed, Nov 30, 2016 at 6:59 AM, Yong Wang  wrote:
[...]
> I think a more accurate description is that the particular descriptor's 
> generation bit never got flipped properly when an mbuf failed to be refilled 
> which caused the rx stuck, rather than vmxnet3_post_rx_bufs() not being 
> called afterwards.
>

Not sure if this kind of level of detail is useful, but if you can
think of a better explanation to put in the changelist, I can add it.
I see the generation bit not flipping as a symptom, while the core
problem is the hardware can't write to the descriptor. I felt the
explanation was going into too much detail anyway, so I've reworded it
a bit for v2. Let me know what you think.

Thanks,
Stefan.

Re: [dpdk-dev] [PATCH 3/4] crypto: add sgl support for sw PMDs

[Kulasek, TomaszX]

Hi Michał,

> -Original Message-
> From: Michał Mirosław [mailto:mir...@gmail.com]
> Sent: Saturday, December 3, 2016 09:28
> To: Kulasek, TomaszX 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 3/4] crypto: add sgl support for sw PMDs
> 
> 2016-12-02 18:07 GMT+01:00 Tomasz Kulasek :
> > This patch introduces RTE_CRYPTODEV_FF_MBUF_SCATTER_GATHER feature
> > flag informing that selected crypto device supports segmented mbufs
> > natively and doesn't need to be coalesced before crypto operation.
> >
> > While using segmented buffers in crypto devices may have unpredictable
> > results, for PMDs which doesn't support it natively, additional check
> > is made for debug compilation.
> >
> [...]
> > +#ifdef RTE_LIBRTE_PMD_AESNI_GCM_DEBUG
> > +   if (!rte_pktmbuf_is_contiguous(ops[i]->sym->m_src) ||
> > +   (ops[i]->sym->m_dst != NULL &&
> > +   !rte_pktmbuf_is_contiguous(
> > +   ops[i]->sym->m_dst))) {
> > +   ops[i]->status =
> RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
> > +   GCM_LOG_ERR("PMD supports only contiguous mbufs,
> "
> > +   "op (%p) provides noncontiguous mbuf as
> "
> > +   "source/destination buffer.\n", ops[i]);
> > +   qp->qp_stats.enqueue_err_count++;
> > +   break;
> > +   }
> > +#endif
> [...]
> 
> Why are there so many copies of this code?
> 
> Best Regards,
> Michał Mirosław

This is one check per crypto PMD: aesni-gcm, aesni-mb, openssl and so on, 
enabled per PMD.

Tomasz

Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API

[Chandran, Sugesh]

Hi Adrien,

Regards
_Sugesh

> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Friday, December 9, 2016 4:39 PM
> To: Chandran, Sugesh 
> Cc: Kevin Traynor ; dev@dpdk.org; Thomas
> Monjalon ; De Lara Guarch, Pablo
> ; Olivier Matz ;
> sugesh.chand...@intel.comn
> Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API
> 
> Hi Sugesh,
> 
> On Fri, Dec 09, 2016 at 12:18:03PM +, Chandran, Sugesh wrote:
> [...]
> > > > Are you going to provide any control over the initialization of
> > > > NIC to define the capability matrices For eg; To operate in a L3
> > > > router mode,
> > > software wanted to initialize the NIC port only to consider the L2
> > > and L3 fields.
> > > > I assume the initialization is done based on the first rules that
> > > > are
> > > programmed into the NIC.?
> > >
> > > Precisely, PMDs are supposed to determine the most appropriate
> > > device mode to use in order to handle the requested rules. They may
> > > even switch to another mode if necessary assuming this does not
> > > break existing constraints.
> > >
> > > I think we've discussed an atomic (commit-based) mode of operation
> > > through separate functions as well, where the application would
> > > attempt to create a bunch of rules at once, possibly making it
> > > easier for PMDs to determine the most appropriate mode of operation
> for the device.
> > >
> > > All of these may be added later according to users feedback once the
> > > basic API has settled.
> > [Sugesh] Yes , we discussed about this before. However I feel that, it
> > make sense to provide some flexibility to the user/application to define a
> profile/mode of the device.
> > This way the complexity of determining the mode by itself will be taken
> away from PMD.
> > Looking at the P4 enablement patches in OVS, the mode definition APIs
> > can be used in conjunction
> > P4 behavioral model.
> > For eg: A P4 model for a L2 switch operate OVS as a L2 switch. Using
> > the mode definition APIs Its possible to impose the same behavioral model
> in the hardware too.
> > This way its simple, clean and very predictive though it needs to define an
> additional profile_define APIs.
> > I am sorry to provide the comment at this stage,  However looking at
> > the adoption of ebpf, P4 make me to think this way.
> > What do you think?
> 
> What you suggest (device profile configuration) would be done by a separate
> function in any case, so as long as everyone agrees on a generic method to
> do so, no problem with extending rte_flow. By default in the meantime we'll
> have to rely on PMDs to make the right decision.
[Sugesh] I am fine with PMD is making the decision on profile/mode selection in
Default case. However we must provide an option for the application to define a 
mode
and PMD must honor with it to avoid making an invalid mode change.
> 
> Do you think it has to be defined from the beginning?
[Sugesh] I feel it's going to be another big topic to decide how proposed mode 
implementation will be looks like,
What should be available modes and etc.  So I am OK to consider as its not part 
of this flow API definition for now.
However its good to mention that in the API comments section to be aware. Do 
you agree that?

> 
> --
> Adrien Mazarguil
> 6WIND

Re: [dpdk-dev] [PATCH v3 00/31] net/i40e: base code update

[Ferruh Yigit]

On 12/10/2016 11:24 AM, Jingjing Wu wrote:
> i40e base code upate. The main changes are:
>  - add clause22 and clause45 implementation for PHY registers accessing
>  - replace existing legacy memcpy() calls with i40e_memcpy() calls.
>  - use BIT() macro instead of bit fields
>  - add clear all WoL filters implementation
>  - add ERROR state for NVM update state machine
>  - add broadcast promiscuous control per VLAN
>  - remove unused X722_SUPPORT and I40E_NDIS_SUPPORT MARCOs
> 
> v3:
>  * update commit log of few patches as issue fix
> 
> v2:
>  * comments rework
>  * complie issue fix
>  * rebase to dpdk-next-net
> 
> Jingjing Wu (31):
>   net/i40e/base: add encap csum VF offload flag
>   net/i40e/base: fix flow control set for 25G
>   net/i40e/base: remove unnecessary code
>   net/i40e/base: fix bit test mask
>   net/i40e/base: group base mode VF offload flags
>   net/i40e/base: fix long link down notification time
>   net/i40e/base: add media type detection for 25G link
>   net/i40e/base: add clause22 and clause45 implementation
>   net/i40e/base: add bus number info
>   net/i40e/base: add protocols when discover capabilities
>   net/i40e/base: fix unknown PHYs incorrect identification
>   net/i40e/base: replace memcpy
>   net/i40e/base: deprecating unused macro
>   net/i40e/base: remove FPK HyperV VF device ID
>   net/i40e/base: add FEC bits to PHY capabilities
>   net/i40e/base: use BIT() macro instead of bit fields
>   net/i40e/base: adjust 25G PHY type values
>   net/i40e/base: implement clear all WoL filters
>   net/i40e/base: implement set VSI full promisc mode
>   net/i40e/base: fix wol failure on PF reset
>   net/i40e/base: save link FEC info from link up event
>   net/i40e/base: fix NVM access intefering
>   net/i40e/base: change shift values to hex
>   net/i40e/base: comment that udp port must be in Host order
>   net/i40e/base: remove duplicate definitions
>   net/i40e/base: add ERROR state for NVM update state machine
>   net/i40e/base: add broadcast promiscuous control per VLAN
>   net/i40e/base: fix division by zero
>   net/i40e/base: fix byte order
>   net/i40e/base: remove unused macro
>   net/i40e: remove unused macro from PMD
> 
<...>

Series applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH 02/32] drivers/common: introducing dpaa2 mc driver

[Hemant Agrawal]

On 12/7/2016 1:18 AM, Ferruh Yigit wrote:

On 12/4/2016 6:16 PM, Hemant Agrawal wrote:

This patch intoduces the DPAA2 MC(Management complex Driver)

This driver is common to be used by various DPAA2 net, crypto
and other drivers

Signed-off-by: Cristian Sovaiala 
[Hemant:rebase and conversion to library for DPDK]


Is this note about how work share done? Do we need this in the history?


Yes! We can avoid it.


Signed-off-by: Hemant Agrawal 
---
 config/defconfig_arm64-dpaa2-linuxapp-gcc|   7 +-
 drivers/Makefile |   1 +
 drivers/common/Makefile  |  36 +
 drivers/common/dpaa2/Makefile|  36 +
 drivers/common/dpaa2/mc/Makefile |  53 ++
 drivers/common/dpaa2/mc/dpaa2_mc_version.map |   4 +
 drivers/common/dpaa2/mc/fsl_mc_cmd.h | 231 +++
 drivers/common/dpaa2/mc/fsl_mc_sys.h |  98 
 drivers/common/dpaa2/mc/mc_sys.c | 126 +++


Are drivers/common/dpaa2/* files are shared code or implemented for
DPDK, I can see Linux version is different.

If these are re-implemented for DPDK, let's follow DPDK coding rules for
a clean start, what do you think?



It is not a re-implementation. We do minor changes to make the common 
library work in user space with DPDK.
The deviation from kernel is because it is still a work in progress 
there. Once it stable there, we will pull in the changes.



 9 files changed, 591 insertions(+), 1 deletion(-)
 create mode 100644 drivers/common/Makefile
 create mode 100644 drivers/common/dpaa2/Makefile
 create mode 100644 drivers/common/dpaa2/mc/Makefile
 create mode 100644 drivers/common/dpaa2/mc/dpaa2_mc_version.map
 create mode 100644 drivers/common/dpaa2/mc/fsl_mc_cmd.h
 create mode 100644 drivers/common/dpaa2/mc/fsl_mc_sys.h
 create mode 100644 drivers/common/dpaa2/mc/mc_sys.c

diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
index 66df54c..00f207e 100644
--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -1,6 +1,7 @@
 #   BSD LICENSE
 #
-#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
+#   Copyright (c) 2016 Freescale Semiconductor, Inc. All rights reserved.
+#   Copyright (c) 2016 NXP. All rights reserved.
 #
 #   Redistribution and use in source and binary forms, with or without
 #   modification, are permitted provided that the following conditions
@@ -40,3 +41,7 @@ CONFIG_RTE_ARCH_ARM_TUNE="cortex-a57+fp+simd"
 #
 CONFIG_RTE_MAX_LCORE=8
 CONFIG_RTE_MAX_NUMA_NODES=1
+
+# Compile software PMD backed by NXP DPAA2 files
+#
+CONFIG_RTE_LIBRTE_DPAA2_PMD=y


Currently how it works is, default value of the config in "common_base"
and it is overwritten in specific config files.
So this config option also should go to "common_base" as disabled by
default.

And the other config option too, mentioned in the documentation.



OK


diff --git a/drivers/Makefile b/drivers/Makefile
index 81c03a8..d5580f6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -31,6 +31,7 @@

 include $(RTE_SDK)/mk/rte.vars.mk

+DIRS-y += common
 DIRS-y += net
 DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto

diff --git a/drivers/common/Makefile b/drivers/common/Makefile
new file mode 100644
index 000..0c3f35f
--- /dev/null
+++ b/drivers/common/Makefile
@@ -0,0 +1,36 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 NXP. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of NXP 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
+#   O

Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API

[Adrien Mazarguil]

Hi Sugesh,

On Mon, Dec 12, 2016 at 10:20:18AM +, Chandran, Sugesh wrote:
> Hi Adrien,
> 
> Regards
> _Sugesh
> 
> > -Original Message-
> > From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> > Sent: Friday, December 9, 2016 4:39 PM
> > To: Chandran, Sugesh 
> > Cc: Kevin Traynor ; dev@dpdk.org; Thomas
> > Monjalon ; De Lara Guarch, Pablo
> > ; Olivier Matz ;
> > sugesh.chand...@intel.comn
> > Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API
> > 
> > Hi Sugesh,
> > 
> > On Fri, Dec 09, 2016 at 12:18:03PM +, Chandran, Sugesh wrote:
> > [...]
> > > > > Are you going to provide any control over the initialization of
> > > > > NIC to define the capability matrices For eg; To operate in a L3
> > > > > router mode,
> > > > software wanted to initialize the NIC port only to consider the L2
> > > > and L3 fields.
> > > > > I assume the initialization is done based on the first rules that
> > > > > are
> > > > programmed into the NIC.?
> > > >
> > > > Precisely, PMDs are supposed to determine the most appropriate
> > > > device mode to use in order to handle the requested rules. They may
> > > > even switch to another mode if necessary assuming this does not
> > > > break existing constraints.
> > > >
> > > > I think we've discussed an atomic (commit-based) mode of operation
> > > > through separate functions as well, where the application would
> > > > attempt to create a bunch of rules at once, possibly making it
> > > > easier for PMDs to determine the most appropriate mode of operation
> > for the device.
> > > >
> > > > All of these may be added later according to users feedback once the
> > > > basic API has settled.
> > > [Sugesh] Yes , we discussed about this before. However I feel that, it
> > > make sense to provide some flexibility to the user/application to define a
> > profile/mode of the device.
> > > This way the complexity of determining the mode by itself will be taken
> > away from PMD.
> > > Looking at the P4 enablement patches in OVS, the mode definition APIs
> > > can be used in conjunction
> > > P4 behavioral model.
> > > For eg: A P4 model for a L2 switch operate OVS as a L2 switch. Using
> > > the mode definition APIs Its possible to impose the same behavioral model
> > in the hardware too.
> > > This way its simple, clean and very predictive though it needs to define 
> > > an
> > additional profile_define APIs.
> > > I am sorry to provide the comment at this stage,  However looking at
> > > the adoption of ebpf, P4 make me to think this way.
> > > What do you think?
> > 
> > What you suggest (device profile configuration) would be done by a separate
> > function in any case, so as long as everyone agrees on a generic method to
> > do so, no problem with extending rte_flow. By default in the meantime we'll
> > have to rely on PMDs to make the right decision.
> [Sugesh] I am fine with PMD is making the decision on profile/mode selection 
> in
> Default case. However we must provide an option for the application to define 
> a mode
> and PMD must honor with it to avoid making an invalid mode change.
> > 
> > Do you think it has to be defined from the beginning?
> [Sugesh] I feel it's going to be another big topic to decide how proposed 
> mode implementation will be looks like,
> What should be available modes and etc.  So I am OK to consider as its not 
> part of this flow API definition for now.
> However its good to mention that in the API comments section to be aware. Do 
> you agree that?

Will do, I'll mention it in the "future evolutions" section.

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation

[Ananyev, Konstantin]

Hi Olivier and Tomasz,

> -Original Message-
> From: Kulasek, TomaszX
> Sent: Friday, December 9, 2016 5:19 PM
> To: Olivier Matz ; Ananyev, Konstantin 
> 
> Cc: Thomas Monjalon ; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation
> 
> Hi Oliver,
> 
> My 5 cents below:
> 
> > -Original Message-
> > From: Olivier Matz [mailto:olivier.m...@6wind.com]
> > Sent: Thursday, December 8, 2016 18:24
> > To: Ananyev, Konstantin 
> > Cc: Thomas Monjalon ; Kulasek, TomaszX
> > ; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation
> >
> > Hi Konstantin,
> >
> > On Fri, 2 Dec 2016 16:17:51 +, "Ananyev, Konstantin"
> >  wrote:
> > > Hi Olivier,
> > >
> > > > -Original Message-
> > > > From: Olivier Matz [mailto:olivier.m...@6wind.com]
> > > > Sent: Friday, December 2, 2016 8:24 AM
> > > > To: Ananyev, Konstantin 
> > > > Cc: Thomas Monjalon ; Kulasek, TomaszX
> > > > ; dev@dpdk.org Subject: Re: [dpdk-dev]
> > > > [PATCH v12 1/6] ethdev: add Tx preparation
> > > >
> > > > Hi Konstantin,
> > > >
> > > > On Fri, 2 Dec 2016 01:06:30 +, "Ananyev, Konstantin"
> > > >  wrote:
> > > > > >
> > > > > > 2016-11-23 18:36, Tomasz Kulasek:
> > > > > > > +/**
> > > > > > > + * Process a burst of output packets on a transmit queue of
> > > > > > > an Ethernet device.
> > > > > > > + *
> > > > > > > + * The rte_eth_tx_prepare() function is invoked to prepare
> > > > > > > output packets to be
> > > > > > > + * transmitted on the output queue *queue_id* of the Ethernet
> > > > > > > device designated
> > > > > > > + * by its *port_id*.
> > > > > > > + * The *nb_pkts* parameter is the number of packets to be
> > > > > > > prepared which are
> > > > > > > + * supplied in the *tx_pkts* array of *rte_mbuf* structures,
> > > > > > > each of them
> > > > > > > + * allocated from a pool created with
> > > > > > > rte_pktmbuf_pool_create().
> > > > > > > + * For each packet to send, the rte_eth_tx_prepare() function
> > > > > > > performs
> > > > > > > + * the following operations:
> > > > > > > + *
> > > > > > > + * - Check if packet meets devices requirements for tx
> > > > > > > offloads.
> > > > > > > + *
> > > > > > > + * - Check limitations about number of segments.
> > > > > > > + *
> > > > > > > + * - Check additional requirements when debug is enabled.
> > > > > > > + *
> > > > > > > + * - Update and/or reset required checksums when tx offload
> > > > > > > is set for packet.
> > > > > > > + *
> > > > > > > + * Since this function can modify packet data, provided mbufs
> > > > > > > must be safely
> > > > > > > + * writable (e.g. modified data cannot be in shared
> > > > > > > segment).
> > > > > >
> > > > > > I think we will have to remove this limitation in next releases.
> > > > > > As we don't know how it could affect the API, I suggest to
> > > > > > declare this API EXPERIMENTAL.
> > > > >
> > > > > While I don't really mind to mart it as experimental, I don't
> > > > > really understand the reasoning: Why " this function can modify
> > > > > packet data, provided mbufs must be safely writable" suddenly
> > > > > becomes a problem? That seems like and obvious limitation to me
> > > > > and let say tx_burst() has the same one. Second, I don't see how
> > > > > you are going to remove it without introducing a heavy performance
> > > > > impact. Konstantin
> > > >
> > > > About tx_burst(), I don't think we should force the user to provide
> > > > a writable mbuf. There are many use cases where passing a clone
> > > > already works as of today and it avoids duplicating the mbuf data.
> > > > For instance: traffic generator, multicast, bridging/tap, etc...
> > > >
> > > > Moreover, this requirement would be inconsistent with the model you
> > > > are proposing in case of pipeline:
> > > >  - tx_prepare() on core X, may update the data
> > > >  - tx_burst() on core Y, should not touch the data to avoid cache
> > > > misses
> > >
> > > Probably I wasn't very clear in my previous mail.
> > > I am not saying that we should force the user to pass a writable mbuf.
> > > What I am saying that for tx_burst() current expectation is that after
> > > mbuf is handled to tx_burst() user shouldn't try to modify its buffer
> > > contents till TX engine is done with the buffer (mbuf_free() is called
> > > by TX func for it). For tx_prep(), I think, it is the same though
> > > restrictions are a bit more strict: user should not try to read/write
> > > to the mbuf while tx_prep() is not finished with it. What puzzles me
> > > is that why that should be the reason to mark tx_prep() as
> > > experimental. Konstantin
> >
> > To be sure we're on the same page, let me reword:
> >
> > - mbufs passed to tx_prepare() by the application must have their
> >   headers (l2_len + l3_len + l4_len) writable because the phdr checksum
> >   can be replaced. It could be precised in the api comment.
> >
> > - mbufs passed to tx_burst() must not be modified by the driver/hw, nor
>

Re: [dpdk-dev] [PATCH v11] drivers/net:new TUN/TAP device PMD

[Vasily Philipov]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Keith Wiles
> Sent: Friday, December 09, 2016 21:05
> To: dev@dpdk.org
> Cc: pmati...@redhat.com; yuanhan@linux.intel.com;
> ferruh.yi...@intel.com; john.mcnam...@intel.com
> Subject: [dpdk-dev] [PATCH v11] drivers/net:new TUN/TAP device PMD
> 
> The PMD allows for DPDK and the host to communicate using a raw device
> interface on the host and in the DPDK application. The device created is a Tap
> device with a L2 packet header.
> 
> v11- Add the tap.rst to the nic/index.rst file
> v10- Change the string name used to allow for multiple devices.
> v9 - Fix up the docs to use correct syntax
> v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
> v7 - Reword the comment in common_base and fix the data->name issue
> v6 - fixed the checkpatch issues
> v5 - merge in changes from list review see related emails
>  fixed many minor edits
> v4 - merge with latest driver changes
> v3 - fix includes by removing ifdef for other type besides Linux
>  Fix the copyright notice in the Makefile
> v2 - merge all of the patches into one patch
>  Fix a typo on naming the tap device
>  Update the maintainers list
> 
> Signed-off-by: Keith Wiles 
> ---
>  MAINTAINERS |   5 +
>  config/common_base  |   9 +
>  config/common_linuxapp  |   1 +
>  doc/guides/nics/index.rst   |   1 +
>  doc/guides/nics/tap.rst | 136 ++
>  drivers/net/Makefile|   1 +
>  drivers/net/tap/Makefile|  57 +++
>  drivers/net/tap/rte_eth_tap.c   | 765
> 
>  drivers/net/tap/rte_pmd_tap_version.map |   4 +
>  mk/rte.app.mk   |   1 +
>  10 files changed, 980 insertions(+)

Tested-by: Vasily Philipov 

[dpdk-dev] [PATCH v3 0/9] net/ixgbe: move set VF functions.

[Bernard Iremonger]

This patchset implements the following deprecation notice:
[PATCH v1] doc: announce API and ABI change for librte_ether

Changes in V3:
Updated LIBABIVER in Makefile in librte_ether patch.
Updated rte_ethdev.h and ret_ether_version.map in librte_ether patch.
Squashed deprecation notice patch into librte_ether patch.
Added release_note patch.

Changes in V2:
Update testpmd set vf commands help messages.
Updated ethtool to use the ixgbe public API's.
Removed the ixgbe_set_pool_* and ixgbe_set_vf_rate_limit functions.
Removed the rte_eth_dev_set_vf_* API's
Removed the deprecation notice.

Changes in V1:
The following functions from eth_dev_ops have been moved to the ixgbe PMD
and renamed:

ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit

Renamed the functions to the following:

rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
rte_pmd_ixgbe_set_vf_rate_limit

Testpmd has been modified to use the following functions:
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rate_limit

New testpmd commands have been added to test the following functions:
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter

The testpmd user guide has been updated for the new commands.

Bernard Iremonger (9):
  net/ixgbe: move set VF functions from the ethdev
  app/testpmd: use ixgbe public functions
  app/testpmd: add command for set VF VLAN filter
  app/testpmd: add command for set VF receive
  app/testpmd: add command for set VF transmit
  examples/ethtool: use ixgbe public function
  net/ixgbe: remove static set VF functions
  librte_ether: remove the set VF API's
  doc: update release notes

 app/test-pmd/cmdline.c  | 270 +++-
 app/test-pmd/config.c   |  31 +-
 doc/guides/rel_notes/deprecation.rst|  13 -
 doc/guides/rel_notes/release_17_02.rst  |  20 ++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  21 ++
 drivers/net/ixgbe/ixgbe_ethdev.c| 459 
 drivers/net/ixgbe/rte_pmd_ixgbe.h   | 104 +++
 drivers/net/ixgbe/rte_pmd_ixgbe_version.map |  10 +
 examples/ethtool/lib/rte_ethtool.c  |   5 +-
 lib/librte_ether/Makefile   |   4 +-
 lib/librte_ether/rte_ethdev.c   | 129 
 lib/librte_ether/rte_ethdev.h   | 140 -
 lib/librte_ether/rte_ether_version.map  |   7 +-
 13 files changed, 706 insertions(+), 507 deletions(-)

-- 
2.10.1

[dpdk-dev] [PATCH v3 1/9] net/ixgbe: move set VF functions from the ethdev

[Bernard Iremonger]

Move the following functions from eth_dev_ops to the ixgbe PMD and rename:

ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit

Rename the functions to the following:

rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
rte_pmd_ixgbe_set_vf_rate_limit

Use public function internally

Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_ethdev.c| 266 +++-
 drivers/net/ixgbe/rte_pmd_ixgbe.h   | 104 +++
 drivers/net/ixgbe/rte_pmd_ixgbe_version.map |  10 ++
 3 files changed, 379 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index edc9b22..37b82a4 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2294,7 +2294,8 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
for (vf = 0; vf < dev->pci_dev->max_vfs; vf++)
for (idx = 0; idx < IXGBE_MAX_QUEUE_NUM_PER_VF; idx++)
if (vfinfo[vf].tx_rate[idx] != 0)
-   ixgbe_set_vf_rate_limit(dev, vf,
+   rte_pmd_ixgbe_set_vf_rate_limit(
+   dev->data->port_id, vf,
vfinfo[vf].tx_rate[idx],
1 << idx);
}
@@ -4883,6 +4884,269 @@ rte_pmd_ixgbe_set_vf_vlan_stripq(uint8_t port, uint16_t 
vf, uint8_t on)
return 0;
 }
 
+int
+rte_pmd_ixgbe_set_vf_rxmode(uint8_t port, uint16_t vf, uint16_t rx_mask, 
uint8_t on)
+{
+   int val = 0;
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+   struct ixgbe_hw *hw;
+   uint32_t vmolr;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = &rte_eth_devices[port];
+   rte_eth_dev_info_get(port, &dev_info);
+
+   if (strstr(dev_info.driver_name, "ixgbe_vf"))
+   return -ENOTSUP;
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   if (on > 1)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+
+   if (hw->mac.type == ixgbe_mac_82598EB) {
+   PMD_INIT_LOG(ERR, "setting VF receive mode set should be done"
+" on 82599 hardware and newer");
+   return -ENOTSUP;
+   }
+   if (ixgbe_vmdq_mode_check(hw) < 0)
+   return -ENOTSUP;
+
+   val = ixgbe_convert_vm_rx_mask_to_val(rx_mask, val);
+
+   if (on)
+   vmolr |= val;
+   else
+   vmolr &= ~val;
+
+   IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+   return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_rx(uint8_t port, uint16_t vf, uint8_t on)
+{
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+   uint32_t reg, addr;
+   uint32_t val;
+   const uint8_t bit1 = 0x1;
+   struct ixgbe_hw *hw;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = &rte_eth_devices[port];
+   rte_eth_dev_info_get(port, &dev_info);
+
+   if (strstr(dev_info.driver_name, "ixgbe_vf"))
+   return -ENOTSUP;
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   if (on > 1)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   if (ixgbe_vmdq_mode_check(hw) < 0)
+   return -ENOTSUP;
+
+   /* for vf >= 32, set bit in PFVFRE[1], otherwise PFVFRE[0] */
+   if (vf >= 32) {
+   addr = IXGBE_VFRE(1);
+   val = bit1 << (vf - 32);
+   } else {
+   addr = IXGBE_VFRE(0);
+   val = bit1 << vf;
+   }
+
+   reg = IXGBE_READ_REG(hw, addr);
+
+   if (on)
+   reg |= val;
+   else
+   reg &= ~val;
+
+   IXGBE_WRITE_REG(hw, addr, reg);
+
+   return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_tx(uint8_t port, uint16_t vf, uint8_t on)
+{
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+   uint32_t reg, addr;
+   uint32_t val;
+   const uint8_t bit1 = 0x1;
+
+   struct ixgbe_hw *hw;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = &rte_eth_devices[port];
+   rte_eth_dev_info_get(port, &dev_info);
+
+   if (strstr(dev_info.driver_name, "ixgbe_vf"))
+   return -ENOTSUP;
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   if (on > 1)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   if (ixgbe_vmdq_mode_check(hw) < 0)
+   return -ENOTSUP;
+
+   /* for vf >= 32, set bit in PFVFTE[1], otherwise PFVFTE[0] */
+   if (vf >= 32) {
+   add

[dpdk-dev] [PATCH v3 2/9] app/testpmd: use ixgbe public functions

[Bernard Iremonger]

Use the the following ixgbe public functions:

rte_pmd_ixgbe_set_vf_rate_limit
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter

Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/cmdline.c |  2 +-
 app/test-pmd/config.c  | 31 +++
 2 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d03a592..12f799b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6708,7 +6708,7 @@ cmd_set_vf_rxmode_parsed(void *parsed_result,
rx_mode |= ETH_VMDQ_ACCEPT_MULTICAST;
}
 
-   ret = 
rte_eth_dev_set_vf_rxmode(res->port_id,res->vf_id,rx_mode,(uint8_t)is_on);
+   ret = rte_pmd_ixgbe_set_vf_rxmode(res->port_id, res->vf_id, rx_mode, 
(uint8_t)is_on);
if (ret < 0)
printf("bad VF receive mode parameter, return code = %d \n",
ret);
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 8cf537d..ea129db 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -92,6 +92,9 @@
 #include 
 #include 
 #include 
+#ifdef RTE_LIBRTE_IXGBE_PMD
+#include 
+#endif
 
 #include "testpmd.h"
 
@@ -2332,16 +2335,16 @@ set_vf_traffic(portid_t port_id, uint8_t is_rx, 
uint16_t vf, uint8_t on)
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
if (is_rx)
-   diag = rte_eth_dev_set_vf_rx(port_id,vf,on);
+   diag = rte_pmd_ixgbe_set_vf_rx(port_id, vf, on);
else
-   diag = rte_eth_dev_set_vf_tx(port_id,vf,on);
+   diag = rte_pmd_ixgbe_set_vf_tx(port_id, vf, on);
if (diag == 0)
return;
if(is_rx)
-   printf("rte_eth_dev_set_vf_rx for port_id=%d failed "
+   printf("rte_pmd_ixgbe_set_vf_rx for port_id=%d failed "
"diag=%d\n", port_id, diag);
else
-   printf("rte_eth_dev_set_vf_tx for port_id=%d failed "
+   printf("rte_pmd_ixgbe_set_vf_tx for port_id=%d failed "
"diag=%d\n", port_id, diag);
 
 }
@@ -2355,10 +2358,10 @@ set_vf_rx_vlan(portid_t port_id, uint16_t vlan_id, 
uint64_t vf_mask, uint8_t on)
return;
if (vlan_id_is_invalid(vlan_id))
return;
-   diag = rte_eth_dev_set_vf_vlan_filter(port_id, vlan_id, vf_mask, on);
+   diag = rte_pmd_ixgbe_set_vf_vlan_filter(port_id, vlan_id, vf_mask, on);
if (diag == 0)
return;
-   printf("rte_eth_dev_set_vf_vlan_filter for port_id=%d failed "
+   printf("rte_pmd_ixgbe_set_vf_vlan_filter for port_id=%d failed "
   "diag=%d\n", port_id, diag);
 }
 
@@ -2388,23 +2391,11 @@ int
 set_vf_rate_limit(portid_t port_id, uint16_t vf, uint16_t rate, uint64_t q_msk)
 {
int diag;
-   struct rte_eth_link link;
-
-   if (q_msk == 0)
-   return 0;
 
-   if (port_id_is_invalid(port_id, ENABLED_WARN))
-   return 1;
-   rte_eth_link_get_nowait(port_id, &link);
-   if (rate > link.link_speed) {
-   printf("Invalid rate value:%u bigger than link speed: %u\n",
-   rate, link.link_speed);
-   return 1;
-   }
-   diag = rte_eth_set_vf_rate_limit(port_id, vf, rate, q_msk);
+   diag = rte_pmd_ixgbe_set_vf_rate_limit(port_id, vf, rate, q_msk);
if (diag == 0)
return diag;
-   printf("rte_eth_set_vf_rate_limit for port_id=%d failed diag=%d\n",
+   printf("rte_pmd_ixgbe_set_vf_rate_limit for port_id=%d failed 
diag=%d\n",
port_id, diag);
return diag;
 }
-- 
2.10.1

[dpdk-dev] [PATCH v3 3/9] app/testpmd: add command for set VF VLAN filter

[Bernard Iremonger]

Add the following command to testpmd:
set vf vlan filteron|off

Add command to the testpmd user guide.

Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/cmdline.c  | 98 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  7 +++
 2 files changed, 105 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 12f799b..947c698 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -291,6 +291,9 @@ static void cmd_help_long_parsed(void *parsed_result,
 
"set vf vlan antispoof (port_id) (vf_id) (on|off)\n"
"Set VLAN antispoof for a VF from the PF.\n\n"
+
+   "set vf vlan filter (port_id) (vlan_id) (vf_mask) 
(on|off)\n"
+   "Set VLAN filter for a VF pool from the PF.\n\n"
 #endif
 
"vlan set filter (on|off) (port_id)\n"
@@ -11139,6 +11142,100 @@ cmdline_parse_inst_t cmd_set_vf_vlan_insert = {
},
 };
 
+
+/* vf vlan filter configuration */
+
+/* Common result structure for vf vlan filter */
+struct cmd_vf_vlan_filter_result {
+   cmdline_fixed_string_t set;
+   cmdline_fixed_string_t vf;
+   cmdline_fixed_string_t vlan;
+   cmdline_fixed_string_t filter;
+   uint8_t port_id;
+   uint16_t vlan_id;
+   uint16_t vf_mask;
+   cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf vlan filter enable disable */
+cmdline_parse_token_string_t cmd_vf_vlan_filter_set =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_filter_result,
+set, "set");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_vf =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_filter_result,
+vf, "vf");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_vlan =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_filter_result,
+vlan, "vlan");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_filter =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_filter_result,
+filter, "filter");
+cmdline_parse_token_num_t cmd_vf_vlan_filter_port_id =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_vf_vlan_filter_result,
+port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_vlan_filter_vlan_id =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_vf_vlan_filter_result,
+vlan_id, UINT16);
+cmdline_parse_token_num_t cmd_vf_vlan_filter_vf_mask =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_vf_vlan_filter_result,
+vf_mask, UINT16);
+cmdline_parse_token_string_t cmd_vf_vlan_filter_on_off =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_filter_result,
+on_off, "on#off");
+
+static void
+cmd_set_vf_vlan_filter_parsed(
+   void *parsed_result,
+   __attribute__((unused)) struct cmdline *cl,
+   __attribute__((unused)) void *data)
+{
+   struct cmd_vf_vlan_filter_result *res = parsed_result;
+   int ret;
+   int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+   ret = rte_pmd_ixgbe_set_vf_vlan_filter(res->port_id, res->vlan_id, 
res->vf_mask, is_on);
+   switch (ret) {
+   case 0:
+   break;
+   case -EINVAL:
+   printf("invalid vf_mask %d or vlan_id %d\n", res->vf_mask, 
res->vlan_id);
+   break;
+   case -ENODEV:
+   printf("invalid port_id %d\n", res->port_id);
+   break;
+   case -ENOTSUP:
+   printf("not supported on vf port %d\n", res->port_id);
+   break;
+   default:
+   printf("programming error: (%s)\n", strerror(-ret));
+   }
+}
+
+cmdline_parse_inst_t cmd_set_vf_vlan_filter = {
+   .f = cmd_set_vf_vlan_filter_parsed,
+   .data = NULL,
+   .help_str = "set vf vlan filteron|off",
+   .tokens = {
+   (void *)&cmd_vf_vlan_filter_set,
+   (void *)&cmd_vf_vlan_filter_vf,
+   (void *)&cmd_vf_vlan_filter_vlan,
+   (void *)&cmd_vf_vlan_filter_filter,
+   (void *)&cmd_vf_vlan_filter_port_id,
+   (void *)&cmd_vf_vlan_filter_vlan_id,
+   (void *)&cmd_vf_vlan_filter_vf_mask,
+   (void *)&cmd_vf_vlan_filter_on_off,
+   NULL,
+   },
+};
+
 /* tx loopback configuration */
 
 /* Common result structure for tx loopback */
@@ -11620,6 +11717,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_vf_mac_anti_spoof,
(cmdline_parse_inst_t *)&cmd_set_vf_vlan_stripq,
(cmdline_parse_inst_t *)&cmd_set_vf_vlan_insert,
+   (cmdline_parse_inst_t *)&cmd_set_vf_vlan_filter,
(cmdline_parse_inst_t *)&cmd_set_tx_loopback,
(cmdline_parse_inst_t *)&cmd_set_all_queues_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
diff --git a/doc/guid

[dpdk-dev] [PATCH v3 4/9] app/testpmd: add command for set VF receive

[Bernard Iremonger]

add the following command to testpmd:

set vf rx   on|off

add command to the testpmd user guide.

Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/cmdline.c  | 85 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  7 +++
 2 files changed, 92 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 947c698..4424c0a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -274,6 +274,9 @@ static void cmd_help_long_parsed(void *parsed_result,
 
"set vf mac antispoof (port_id) (vf_id) (on|off).\n"
"Set MAC antispoof for a VF from the PF.\n\n"
+
+   "set vf rx (port_id) (vf_id) (on|off).\n"
+   "Enable or disable RX for a VF from the PF.\n\n"
 #endif
 
"vlan set strip (on|off) (port_id)\n"
@@ -11236,6 +11239,87 @@ cmdline_parse_inst_t cmd_set_vf_vlan_filter = {
},
 };
 
+/* vf rx configuration */
+
+/* Common result structure for vf rx */
+struct cmd_vf_rx_result {
+   cmdline_fixed_string_t set;
+   cmdline_fixed_string_t vf;
+   cmdline_fixed_string_t rx;
+   uint8_t port_id;
+   uint16_t vf_id;
+   cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf rx enable disable */
+cmdline_parse_token_string_t cmd_vf_rx_set =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_rx_result,
+set, "set");
+cmdline_parse_token_string_t cmd_vf_rx_vf =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_rx_result,
+vf, "vf");
+cmdline_parse_token_string_t cmd_vf_rx_rx =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_rx_result,
+rx, "rx");
+cmdline_parse_token_num_t cmd_vf_rx_port_id =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_vf_rx_result,
+port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_rx_vf_id =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_vf_rx_result,
+vf_id, UINT16);
+cmdline_parse_token_string_t cmd_vf_rx_on_off =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_rx_result,
+on_off, "on#off");
+
+static void
+cmd_set_vf_rx_parsed(
+   void *parsed_result,
+   __attribute__((unused)) struct cmdline *cl,
+   __attribute__((unused)) void *data)
+{
+   struct cmd_vf_rx_result *res = parsed_result;
+   int ret = 0;
+   int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+   ret = rte_pmd_ixgbe_set_vf_rx(res->port_id, res->vf_id, is_on);
+   switch (ret) {
+   case 0:
+   break;
+   case -EINVAL:
+   printf("invalid vf_id %d or is_on %d\n", res->vf_id, is_on);
+   break;
+   case -ENODEV:
+   printf("invalid port_id %d\n", res->port_id);
+   break;
+   case -ENOTSUP:
+   printf("not supported on vf port %d\n", res->port_id);
+   break;
+   default:
+   printf("programming error: (%s)\n", strerror(-ret));
+   }
+}
+
+cmdline_parse_inst_t cmd_set_vf_rx = {
+   .f = cmd_set_vf_rx_parsed,
+   .data = NULL,
+   .help_str = "set vf rx   on|off",
+   .tokens = {
+   (void *)&cmd_vf_rx_set,
+   (void *)&cmd_vf_rx_vf,
+   (void *)&cmd_vf_rx_rx,
+   (void *)&cmd_vf_rx_port_id,
+   (void *)&cmd_vf_rx_vf_id,
+   (void *)&cmd_vf_rx_on_off,
+   NULL,
+   },
+};
+
 /* tx loopback configuration */
 
 /* Common result structure for tx loopback */
@@ -11722,6 +11806,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_all_queues_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
+   (cmdline_parse_inst_t *)&cmd_set_vf_rx,
 #endif
NULL,
 };
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 60dcd91..6a058e9 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -507,6 +507,13 @@ Set mac antispoof for a VF from the PF::
 
testpmd> set vf mac antispoof  (port_id) (vf_id) (on|off)
 
+set rx (for VF)
+~~~
+
+Enable/disable rx for a VF from the PF::
+
+   testpmd> set vf rx (port_id) (vf_id) (on|off)
+
 vlan set strip
 ~~
 
-- 
2.10.1

[dpdk-dev] [PATCH v3 5/9] app/testpmd: add command for set VF transmit

[Bernard Iremonger]

add the following command to testpmd:

set vf tx   on|off

add command to the testpmd user guide.

Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/cmdline.c  | 85 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  7 +++
 2 files changed, 92 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4424c0a..e385732 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -277,6 +277,9 @@ static void cmd_help_long_parsed(void *parsed_result,
 
"set vf rx (port_id) (vf_id) (on|off).\n"
"Enable or disable RX for a VF from the PF.\n\n"
+
+   "set vf tx (port_id) (vf_id) (on|off).\n"
+   "Enable or disable TX for a VF from the PF.\n\n"
 #endif
 
"vlan set strip (on|off) (port_id)\n"
@@ -11320,6 +11323,87 @@ cmdline_parse_inst_t cmd_set_vf_rx = {
},
 };
 
+/* vf tx configuration */
+
+/* Common result structure for vf tx */
+struct cmd_vf_tx_result {
+   cmdline_fixed_string_t set;
+   cmdline_fixed_string_t vf;
+   cmdline_fixed_string_t tx;
+   uint8_t port_id;
+   uint16_t vf_id;
+   cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf tx enable disable */
+cmdline_parse_token_string_t cmd_vf_tx_set =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_tx_result,
+set, "set");
+cmdline_parse_token_string_t cmd_vf_tx_vf =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_tx_result,
+vf, "vf");
+cmdline_parse_token_string_t cmd_vf_tx_tx =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_tx_result,
+tx, "tx");
+cmdline_parse_token_num_t cmd_vf_tx_port_id =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_vf_tx_result,
+port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_tx_vf_id =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_vf_tx_result,
+vf_id, UINT16);
+cmdline_parse_token_string_t cmd_vf_tx_on_off =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_tx_result,
+on_off, "on#off");
+
+static void
+cmd_set_vf_tx_parsed(
+   void *parsed_result,
+   __attribute__((unused)) struct cmdline *cl,
+   __attribute__((unused)) void *data)
+{
+   struct cmd_vf_tx_result *res = parsed_result;
+   int ret = 0;
+   int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+   ret = rte_pmd_ixgbe_set_vf_tx(res->port_id, res->vf_id, is_on);
+   switch (ret) {
+   case 0:
+   break;
+   case -EINVAL:
+   printf("invalid vf_id %d or is_on %d\n", res->vf_id, is_on);
+   break;
+   case -ENODEV:
+   printf("invalid port_id %d\n", res->port_id);
+   break;
+   case -ENOTSUP:
+   printf("not supported on vf port %d\n", res->port_id);
+   break;
+   default:
+   printf("programming error: (%s)\n", strerror(-ret));
+   }
+}
+
+cmdline_parse_inst_t cmd_set_vf_tx = {
+   .f = cmd_set_vf_tx_parsed,
+   .data = NULL,
+   .help_str = "set vf tx   on|off",
+   .tokens = {
+   (void *)&cmd_vf_tx_set,
+   (void *)&cmd_vf_tx_vf,
+   (void *)&cmd_vf_tx_tx,
+   (void *)&cmd_vf_tx_port_id,
+   (void *)&cmd_vf_tx_vf_id,
+   (void *)&cmd_vf_tx_on_off,
+   NULL,
+   },
+};
+
 /* tx loopback configuration */
 
 /* Common result structure for tx loopback */
@@ -11807,6 +11891,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
(cmdline_parse_inst_t *)&cmd_set_vf_rx,
+   (cmdline_parse_inst_t *)&cmd_set_vf_tx,
 #endif
NULL,
 };
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 6a058e9..1de4c5f 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -514,6 +514,13 @@ Enable/disable rx for a VF from the PF::
 
testpmd> set vf rx (port_id) (vf_id) (on|off)
 
+set tx (for VF)
+~~~
+
+Enable/disable tx for a VF from the PF::
+
+   testpmd> set vf tx (port_id) (vf_id) (on|off)
+
 vlan set strip
 ~~
 
-- 
2.10.1

[dpdk-dev] [PATCH v3 8/9] librte_ether: remove the set VF API's

[Bernard Iremonger]

remove the following API's:

rte_eth_dev_set_vf_rxmode
rte_eth_dev_set_vf_rx
rte_eth_dev_set_vf_tx
rte_eth_dev_set_vf_vlan_filter
rte_eth_dev_set_vf_rate_limit

Increment LIBABIVER in Makefile
Remove deprecation notice for removing rte_eth_dev_set_vf_* API's.

Signed-off-by: Bernard Iremonger 
---
 doc/guides/rel_notes/deprecation.rst   |  13 ---
 lib/librte_ether/Makefile  |   4 +-
 lib/librte_ether/rte_ethdev.c  | 129 --
 lib/librte_ether/rte_ethdev.h  | 140 -
 lib/librte_ether/rte_ether_version.map |   7 +-
 5 files changed, 3 insertions(+), 290 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 2d17bc6..c897c18 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -38,19 +38,6 @@ Deprecation Notices
   ``_rte_eth_dev_callback_process``. In 17.02 the function will return an 
``int``
   instead of ``void`` and a fourth parameter ``void *ret_param`` will be added.
 
-* ethdev: for 17.02 it is planned to deprecate the following five functions
-  and move them in ixgbe:
-
-  ``rte_eth_dev_set_vf_rxmode``
-
-  ``rte_eth_dev_set_vf_rx``
-
-  ``rte_eth_dev_set_vf_tx``
-
-  ``rte_eth_dev_set_vf_vlan_filter``
-
-  ``rte_eth_set_vf_rate_limit``
-
 * ABI changes are planned for 17.02 in the ``rte_mbuf`` structure: some fields
   may be reordered to facilitate the writing of ``data_off``, ``refcnt``, and
   ``nb_segs`` in one operation, because some platforms have an overhead if the
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index efe1e5f..d23015c 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -1,6 +1,6 @@
 #   BSD LICENSE
 #
-#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+#   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 #   All rights reserved.
 #
 #   Redistribution and use in source and binary forms, with or without
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
 
 EXPORT_MAP := rte_ether_version.map
 
-LIBABIVER := 5
+LIBABIVER := 6
 
 SRCS-y += rte_ethdev.c
 
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 1e0f206..6a93014 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2137,32 +2137,6 @@ rte_eth_dev_default_mac_addr_set(uint8_t port_id, struct 
ether_addr *addr)
return 0;
 }
 
-int
-rte_eth_dev_set_vf_rxmode(uint8_t port_id,  uint16_t vf,
-   uint16_t rx_mode, uint8_t on)
-{
-   uint16_t num_vfs;
-   struct rte_eth_dev *dev;
-   struct rte_eth_dev_info dev_info;
-
-   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
-   dev = &rte_eth_devices[port_id];
-   rte_eth_dev_info_get(port_id, &dev_info);
-
-   num_vfs = dev_info.max_vfs;
-   if (vf > num_vfs) {
-   RTE_PMD_DEBUG_TRACE("set VF RX mode:invalid VF id %d\n", vf);
-   return -EINVAL;
-   }
-
-   if (rx_mode == 0) {
-   RTE_PMD_DEBUG_TRACE("set VF RX mode:mode mask ca not be 
zero\n");
-   return -EINVAL;
-   }
-   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_rx_mode, -ENOTSUP);
-   return (*dev->dev_ops->set_vf_rx_mode)(dev, vf, rx_mode, on);
-}
 
 /*
  * Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to find
@@ -2252,76 +2226,6 @@ rte_eth_dev_uc_all_hash_table_set(uint8_t port_id, 
uint8_t on)
return (*dev->dev_ops->uc_all_hash_table_set)(dev, on);
 }
 
-int
-rte_eth_dev_set_vf_rx(uint8_t port_id, uint16_t vf, uint8_t on)
-{
-   uint16_t num_vfs;
-   struct rte_eth_dev *dev;
-   struct rte_eth_dev_info dev_info;
-
-   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
-   dev = &rte_eth_devices[port_id];
-   rte_eth_dev_info_get(port_id, &dev_info);
-
-   num_vfs = dev_info.max_vfs;
-   if (vf > num_vfs) {
-   RTE_PMD_DEBUG_TRACE("port %d: invalid vf id\n", port_id);
-   return -EINVAL;
-   }
-
-   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_rx, -ENOTSUP);
-   return (*dev->dev_ops->set_vf_rx)(dev, vf, on);
-}
-
-int
-rte_eth_dev_set_vf_tx(uint8_t port_id, uint16_t vf, uint8_t on)
-{
-   uint16_t num_vfs;
-   struct rte_eth_dev *dev;
-   struct rte_eth_dev_info dev_info;
-
-   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
-   dev = &rte_eth_devices[port_id];
-   rte_eth_dev_info_get(port_id, &dev_info);
-
-   num_vfs = dev_info.max_vfs;
-   if (vf > num_vfs) {
-   RTE_PMD_DEBUG_TRACE("set pool tx:invalid pool id=%d\n", vf);
-   return -EINVAL;
-   }
-
-   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_tx, -ENOTSUP);
-   return (*dev->dev_ops->set_vf_tx)(dev, vf, on);
-}
-
-int
-rte_eth_dev_set_vf_vlan_filter(uint8_t port_id, uint16_t vlan_id,
-  uint64_t vf_mask, uint8_t vlan_o

[dpdk-dev] [PATCH v3 7/9] net/ixgbe: remove static set VF functions

[Bernard Iremonger]

remove the following static functions:

ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit

Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 193 ---
 1 file changed, 193 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 37b82a4..8db1410 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -276,12 +276,6 @@ static void ixgbevf_dev_allmulticast_disable(struct 
rte_eth_dev *dev);
 static int ixgbe_uc_hash_table_set(struct rte_eth_dev *dev, struct
ether_addr * mac_addr, uint8_t on);
 static int ixgbe_uc_all_hash_table_set(struct rte_eth_dev *dev, uint8_t on);
-static int  ixgbe_set_pool_rx_mode(struct rte_eth_dev *dev,  uint16_t pool,
-   uint16_t rx_mask, uint8_t on);
-static int ixgbe_set_pool_rx(struct rte_eth_dev *dev, uint16_t pool, uint8_t 
on);
-static int ixgbe_set_pool_tx(struct rte_eth_dev *dev, uint16_t pool, uint8_t 
on);
-static int ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev, uint16_t vlan,
-   uint64_t pool_mask, uint8_t vlan_on);
 static int ixgbe_mirror_rule_set(struct rte_eth_dev *dev,
struct rte_eth_mirror_conf *mirror_conf,
uint8_t rule_id, uint8_t on);
@@ -297,8 +291,6 @@ static void ixgbe_configure_msix(struct rte_eth_dev *dev);
 
 static int ixgbe_set_queue_rate_limit(struct rte_eth_dev *dev,
uint16_t queue_idx, uint16_t tx_rate);
-static int ixgbe_set_vf_rate_limit(struct rte_eth_dev *dev, uint16_t vf,
-   uint16_t tx_rate, uint64_t q_msk);
 
 static void ixgbevf_add_mac_addr(struct rte_eth_dev *dev,
 struct ether_addr *mac_addr,
@@ -568,12 +560,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.uc_all_hash_table_set  = ixgbe_uc_all_hash_table_set,
.mirror_rule_set  = ixgbe_mirror_rule_set,
.mirror_rule_reset= ixgbe_mirror_rule_reset,
-   .set_vf_rx_mode   = ixgbe_set_pool_rx_mode,
-   .set_vf_rx= ixgbe_set_pool_rx,
-   .set_vf_tx= ixgbe_set_pool_tx,
-   .set_vf_vlan_filter   = ixgbe_set_pool_vlan_filter,
.set_queue_rate_limit = ixgbe_set_queue_rate_limit,
-   .set_vf_rate_limit= ixgbe_set_vf_rate_limit,
.reta_update  = ixgbe_dev_rss_reta_update,
.reta_query   = ixgbe_dev_rss_reta_query,
 #ifdef RTE_NIC_BYPASS
@@ -4547,132 +4534,6 @@ ixgbe_convert_vm_rx_mask_to_val(uint16_t rx_mask, 
uint32_t orig_val)
return new_val;
 }
 
-static int
-ixgbe_set_pool_rx_mode(struct rte_eth_dev *dev, uint16_t pool,
-  uint16_t rx_mask, uint8_t on)
-{
-   int val = 0;
-
-   struct ixgbe_hw *hw =
-   IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-   uint32_t vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(pool));
-
-   if (hw->mac.type == ixgbe_mac_82598EB) {
-   PMD_INIT_LOG(ERR, "setting VF receive mode set should be done"
-" on 82599 hardware and newer");
-   return -ENOTSUP;
-   }
-   if (ixgbe_vmdq_mode_check(hw) < 0)
-   return -ENOTSUP;
-
-   val = ixgbe_convert_vm_rx_mask_to_val(rx_mask, val);
-
-   if (on)
-   vmolr |= val;
-   else
-   vmolr &= ~val;
-
-   IXGBE_WRITE_REG(hw, IXGBE_VMOLR(pool), vmolr);
-
-   return 0;
-}
-
-static int
-ixgbe_set_pool_rx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on)
-{
-   uint32_t reg, addr;
-   uint32_t val;
-   const uint8_t bit1 = 0x1;
-
-   struct ixgbe_hw *hw =
-   IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
-   if (ixgbe_vmdq_mode_check(hw) < 0)
-   return -ENOTSUP;
-
-   if (pool >= ETH_64_POOLS)
-   return -EINVAL;
-
-   /* for pool >= 32, set bit in PFVFRE[1], otherwise PFVFRE[0] */
-   if (pool >= 32) {
-   addr = IXGBE_VFRE(1);
-   val = bit1 << (pool - 32);
-   } else {
-   addr = IXGBE_VFRE(0);
-   val = bit1 << pool;
-   }
-
-   reg = IXGBE_READ_REG(hw, addr);
-
-   if (on)
-   reg |= val;
-   else
-   reg &= ~val;
-
-   IXGBE_WRITE_REG(hw, addr, reg);
-
-   return 0;
-}
-
-static int
-ixgbe_set_pool_tx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on)
-{
-   uint32_t reg, addr;
-   uint32_t val;
-   const uint8_t bit1 = 0x1;
-
-   struct ixgbe_hw *hw =
-   IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
-   if (ixgbe_vmdq_mode_check(hw) < 0)
-   return -ENOTSUP;
-
-   if (pool >= ETH_64_POOLS)
-   return -EINVAL;
-
-   /* for pool >= 32, set bit in PFVFTE[1], otherwise PFVFTE[0] */
-   if (pool >= 32) {
-   addr = IXGBE_VFTE(1);
-   val

[dpdk-dev] [PATCH v3 9/9] doc: update release notes

[Bernard Iremonger]

Add release note for removing set VF API's from the ethdev,
renaming the API's and moving them to the ixgbe PMD.

Signed-off-by: Bernard Iremonger 
---
 doc/guides/rel_notes/release_17_02.rst | 20 
 1 file changed, 20 insertions(+)

diff --git a/doc/guides/rel_notes/release_17_02.rst 
b/doc/guides/rel_notes/release_17_02.rst
index 3b65038..d30b258 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -38,6 +38,26 @@ New Features
  Also, make sure to start the actual text at the margin.
  =
 
+* **Moved five APIs for VF management from the ethdev to the ixgbe PMD.**
+
+  The following five APIs for VF management from the PF have been removed from 
the ethdev,
+  renamed and added to the ixgbe PMD::
+
+rte_eth_dev_set_vf_rate_limit
+rte_eth_dev_set_vf_rx
+rte_eth_dev_set_vf_rxmode
+rte_eth_dev_set_vf_tx
+rte_eth_dev_set_vf_vlan_filter
+
+  The API's have been renamed to the following::
+
+rte_pmd_ixgbe_set_vf_rate_limit
+rte_pmd_ixgbe_set_vf_rx
+rte_pmd_ixgbe_set_vf_rxmode
+rte_pmd_ixgbe_set_vf_tx
+rte_pmd_ixgbe_set_vf_vlan_filter
+
+  The declarations for the API’s can be found in ``rte_pmd_ixgbe.h``.
 
 Resolved Issues
 ---
-- 
2.10.1

[dpdk-dev] [PATCH v3 6/9] examples/ethtool: use ixgbe public function

[Bernard Iremonger]

Replace rte_eth_dev_set_vf_rxmode with rte_pmd_ixgbe_set_vf_rx_mode.

Signed-off-by: Bernard Iremonger 
---
 examples/ethtool/lib/rte_ethtool.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/examples/ethtool/lib/rte_ethtool.c 
b/examples/ethtool/lib/rte_ethtool.c
index a1f91d4..0e539f7 100644
--- a/examples/ethtool/lib/rte_ethtool.c
+++ b/examples/ethtool/lib/rte_ethtool.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "rte_ethtool.h"
 
 #define PKTPOOL_SIZE 512
@@ -354,7 +355,7 @@ rte_ethtool_net_set_rx_mode(uint8_t port_id)
 
/* Set VF vf_rx_mode, VF unsupport status is discard */
for (vf = 0; vf < num_vfs; vf++)
-   rte_eth_dev_set_vf_rxmode(port_id, vf,
+   rte_pmd_ixgbe_set_vf_rxmode(port_id, vf,
ETH_VMDQ_ACCEPT_UNTAG, 0);
 
/* Enable Rx vlan filter, VF unspport status is discard */
-- 
2.10.1

[dpdk-dev] [PATCH v12] net/tap: new TUN/TAP device PMD

[Keith Wiles]

The PMD allows for DPDK and the host to communicate using a raw
device interface on the host and in the DPDK application. The device
created is a Tap device with a L2 packet header.

v12- Fixup minor changes for driver_name and version number
v11- Add the tap.rst to the nic/index.rst file
v10- Change the string name used to allow for multiple devices.
v9 - Fix up the docs to use correct syntax
v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
v7 - Reword the comment in common_base and fix the data->name issue
v6 - fixed the checkpatch issues
v5 - merge in changes from list review see related emails
 fixed many minor edits
v4 - merge with latest driver changes
v3 - fix includes by removing ifdef for other type besides Linux
 Fix the copyright notice in the Makefile
v2 - merge all of the patches into one patch
 Fix a typo on naming the tap device
 Update the maintainers list

Signed-off-by: Keith Wiles 
---
 MAINTAINERS |   5 +
 config/common_base  |   9 +
 config/common_linuxapp  |   1 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/tap.rst | 136 ++
 drivers/net/Makefile|   1 +
 drivers/net/tap/Makefile|  57 +++
 drivers/net/tap/rte_eth_tap.c   | 765 
 drivers/net/tap/rte_pmd_tap_version.map |   4 +
 mk/rte.app.mk   |   1 +
 10 files changed, 980 insertions(+)
 create mode 100644 doc/guides/nics/tap.rst
 create mode 100644 drivers/net/tap/Makefile
 create mode 100644 drivers/net/tap/rte_eth_tap.c
 create mode 100644 drivers/net/tap/rte_pmd_tap_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 26d9590..842fb6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -398,6 +398,11 @@ F: doc/guides/nics/pcap_ring.rst
 F: app/test/test_pmd_ring.c
 F: app/test/test_pmd_ring_perf.c
 
+Tap PMD
+M: Keith Wiles 
+F: drivers/net/tap
+F: doc/guides/nics/tap.rst
+
 Null Networking PMD
 M: Tetsuya Mukawa 
 F: drivers/net/null/
diff --git a/config/common_base b/config/common_base
index 652a839..eb51cdb 100644
--- a/config/common_base
+++ b/config/common_base
@@ -590,3 +590,12 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
 CONFIG_RTE_TEST_PMD=y
 CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
 CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
+
+#
+# Compile the TAP PMD
+#
+# The TAP PMD is currently only built for Linux and the
+# option is enabled by default in common_linuxapp file,
+# set to 'n' in the common_base file.
+#
+CONFIG_RTE_LIBRTE_PMD_TAP=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2483dfa..782b503 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -44,3 +44,4 @@ CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_POWER=y
 CONFIG_RTE_VIRTIO_USER=y
+CONFIG_RTE_LIBRTE_PMD_TAP=y
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 92d56a5..af92529 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -51,6 +51,7 @@ Network Interface Controller Drivers
 nfp
 qede
 szedata2
+tap
 thunderx
 virtio
 vhost
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
new file mode 100644
index 000..622b9e7
--- /dev/null
+++ b/doc/guides/nics/tap.rst
@@ -0,0 +1,136 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY

Re: [dpdk-dev] [PATCH 00/13] Introducing EAL Bus-Device-Driver Model

[Jianbo Liu]

Hi Shreyansh,

On 7 December 2016 at 21:10, Shreyansh Jain  wrote:
> On Wednesday 07 December 2016 05:47 PM, David Marchand wrote:
>>
>> Hello Shreyansh,
>>
>> On Wed, Dec 7, 2016 at 10:55 AM, Shreyansh Jain 
>> wrote:
>>>
>>> On Wednesday 07 December 2016 02:22 AM, David Marchand wrote:
>
> 0002~0003: Introducing the basic Bus model and associated test case
> 0005:  Support insertion of device rather than addition to tail



 Patch 2 and 5 could be squashed.
>>>
>>>
>>>
>>> I deliberately kept them separate. I intent to extend the Patch 5 for
>>> hotplugging. But, if I don't end up adding support for that in this
>>> series,
>>> I will merge these two.
>>
>>
>> Fine.
>>
>>
 The constructor priority stuff seems unneeded as long as we use
 explicit reference to a global (or local, did not check) bus symbol
 rather than a runtime lookup.
>>>
>>>
>>>
>>> I didn't understand your point here.
>>> IMO, constructor priority (or some other way to handle this) is
>>> important. I
>>> faced this issue while verifying it at my end when the drivers were
>>> getting
>>> registered before the bus.
>>>
>>> Can you elaborate more on '..use explicit reference to a global...'?
>>
>>
>> The drivers register themselves to a bus using this bus specific api.
>>
>> For pci, this is rte_eal_pci_register().
>> The pci_bus object must be moved to eal_common_pci.c (we can stil
>> internally expose for bsd / linux specific implementations).
>> Then, rte_eal_pci_register() can add the pci driver to the pci_bus
>> drivers list even if this pci_bus object is not registered yet to the
>> buses list.
>
>
> So, in eal_common_bus.c
>
> --->8---
>
> struct rte_bus *global_ptr_to_pci_bus = NULL;
>
> struct rte_bus pci_bus = { ... };
>
> rte_eal_pci_register() {
> if (global_ptr_to_pci_bus == NULL)
> rte_eal_bus_register(&pci_bus)
> else
>// continue as if PCI bus is registered
> }
>
> --->8---
>
> so, no RTE_REGISTER_BUS()?
>
> If yes, then RTE_REGISTER_BUS() should also check for an existing
> registration for duplication.
>
> I was banking on a model where bus handlers (or bus drivers) are independent
> entities, just like PMDs. So, we have a bus XYZ without any drivers
> necessarily based on it.
>
> By making registration dependent on driver registration, it becomes implicit
> that buses don't exist without drivers.
> I am not in favor of this - or maybe I lack enough reason for this (about
> how it will make framework/PMD life better).
>
>>
>> And no constructor order issue ?
>>
>>


> 0004:  Add scan and match callbacks for the Bus and updated test
> case



 Why do you push back the bus object in the 'scan' method ?
 This method is bus specific which means that the code "knows" the
 object registered with the callback.
>>>
>>>
>>>
>>> This 'knows' is the grey area for me.
>>> The bus (for example, PCI) after scanning needs to call
>>> rte_eal_bus_add_device() to link the device in bus's device_list.
>>>
>>> Two options:
>>> 1. Have a global reference to "pci" bus (rte_bus) somewhere in eal_pci.c
>>> 2. Call rte_eal_get_bus() every time someone needs the reference.
>>> 3. C++ style, 'this->'.
>>>
>>> I have taken the 3rd path. It simplifies my code to not assume a handle
>>> as
>>> well as not allow for reference fetch calls every now and then.
>>>
>>> As a disadvantage: it means passing this as argument - and some cases
>>> maintaining it as __rte_unused.
>>>
>>> Taking (1) or (2) is not advantageous than this approach.
>>
>>
>> 1) is the simplest one.
>>
>> When you write a pci_scan method and embed it in you pci_bus object,
>> but this pci_scan method still wonders which bus object it is supposed
>> to work on, this is a bit like Schizophrenia ;-).
>
>
> :)
> This now is linked to the above issue of constructor priority and having a
> global bus reference. I don't personally prefer it.
> I will still give this a serious thought, though.
>

I'm also in favor of (3).

>>
>>
 Is is that you want to have a single scan method used by multiple buses
 ?
>>>
>>>
>>>
>>> Yes, but only as a use case. For example, platform devices are of various
>>> types - what if we have a south-bound bus over a platform bus. In which
>>> case, a hierarchical bus layout is possible.
>>> But, this is far-fetched idea for now.
>>

How to express the hierarchical bus layout as the bus in your design
is more like independent objects to hold drivers and their devices?

>>
>> Well, if you have no usecase at the moment, let's keep it simple, please.
>>
>
> Ok.
>
>>

> 0006:  Integrate bus scan/match with EAL, without any effective
> driver



 Hard to find a right balance in patch splittng, but patch 4 and 6 are
 linked, I would squash them into one.
>>>
>>>
>>>
>>> Yes, it is hard and sometimes there is simply no strong rationale for
>>> splitting or merging. This is one of those cases.
>>> My idea was that one p

[dpdk-dev] [PATCH v12] net/tap: new TUN/TAP device PMD

[Keith Wiles]

The PMD allows for DPDK and the host to communicate using a raw
device interface on the host and in the DPDK application. The device
created is a Tap device with a L2 packet header.

v12- Fixup minor changes for driver_name and version number
v11- Add the tap.rst to the nic/index.rst file
v10- Change the string name used to allow for multiple devices.
v9 - Fix up the docs to use correct syntax
v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
v7 - Reword the comment in common_base and fix the data->name issue
v6 - fixed the checkpatch issues
v5 - merge in changes from list review see related emails
 fixed many minor edits
v4 - merge with latest driver changes
v3 - fix includes by removing ifdef for other type besides Linux
 Fix the copyright notice in the Makefile
v2 - merge all of the patches into one patch
 Fix a typo on naming the tap device
 Update the maintainers list

Signed-off-by: Keith Wiles 
---
 MAINTAINERS |   5 +
 config/common_base  |   9 +
 config/common_linuxapp  |   1 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/tap.rst | 136 ++
 drivers/net/Makefile|   1 +
 drivers/net/tap/Makefile|  57 +++
 drivers/net/tap/rte_eth_tap.c   | 765 
 drivers/net/tap/rte_pmd_tap_version.map |   4 +
 mk/rte.app.mk   |   1 +
 10 files changed, 980 insertions(+)
 create mode 100644 doc/guides/nics/tap.rst
 create mode 100644 drivers/net/tap/Makefile
 create mode 100644 drivers/net/tap/rte_eth_tap.c
 create mode 100644 drivers/net/tap/rte_pmd_tap_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 26d9590..842fb6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -398,6 +398,11 @@ F: doc/guides/nics/pcap_ring.rst
 F: app/test/test_pmd_ring.c
 F: app/test/test_pmd_ring_perf.c
 
+Tap PMD
+M: Keith Wiles 
+F: drivers/net/tap
+F: doc/guides/nics/tap.rst
+
 Null Networking PMD
 M: Tetsuya Mukawa 
 F: drivers/net/null/
diff --git a/config/common_base b/config/common_base
index 652a839..eb51cdb 100644
--- a/config/common_base
+++ b/config/common_base
@@ -590,3 +590,12 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
 CONFIG_RTE_TEST_PMD=y
 CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
 CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
+
+#
+# Compile the TAP PMD
+#
+# The TAP PMD is currently only built for Linux and the
+# option is enabled by default in common_linuxapp file,
+# set to 'n' in the common_base file.
+#
+CONFIG_RTE_LIBRTE_PMD_TAP=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2483dfa..782b503 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -44,3 +44,4 @@ CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_POWER=y
 CONFIG_RTE_VIRTIO_USER=y
+CONFIG_RTE_LIBRTE_PMD_TAP=y
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 92d56a5..af92529 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -51,6 +51,7 @@ Network Interface Controller Drivers
 nfp
 qede
 szedata2
+tap
 thunderx
 virtio
 vhost
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
new file mode 100644
index 000..622b9e7
--- /dev/null
+++ b/doc/guides/nics/tap.rst
@@ -0,0 +1,136 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY

Re: [dpdk-dev] [dpdk-dev, 1/8] drivers/common/dpaa2: Run time assembler for Descriptor formation

[Neil Horman]

On Mon, Dec 05, 2016 at 06:25:33PM +0530, Akhil Goyal wrote:
> FLib is a library which helps in making the descriptors which
> is understood by NXP's SEC hardware.
> This patch provides header files for command words which can be used
> for descritptor formation.
> 
> Signed-off-by: Horia Geanta Neag 
> Acked-by: Akhil Goyal 
> ---
>  drivers/common/dpaa2/flib/README   |  43 +
>  drivers/common/dpaa2/flib/compat.h | 186 +
>  drivers/common/dpaa2/flib/rta.h| 918 
> +
>  .../common/dpaa2/flib/rta/fifo_load_store_cmd.h| 308 +++
>  drivers/common/dpaa2/flib/rta/header_cmd.h | 213 +
>  drivers/common/dpaa2/flib/rta/jump_cmd.h   | 172 
>  drivers/common/dpaa2/flib/rta/key_cmd.h| 187 +
>  drivers/common/dpaa2/flib/rta/load_cmd.h   | 301 +++
>  drivers/common/dpaa2/flib/rta/math_cmd.h   | 366 
>  drivers/common/dpaa2/flib/rta/move_cmd.h   | 405 +
>  drivers/common/dpaa2/flib/rta/nfifo_cmd.h  | 161 
>  drivers/common/dpaa2/flib/rta/operation_cmd.h  | 549 
>  drivers/common/dpaa2/flib/rta/protocol_cmd.h   | 680 +++
>  drivers/common/dpaa2/flib/rta/sec_run_time_asm.h   | 767 +
>  drivers/common/dpaa2/flib/rta/seq_in_out_ptr_cmd.h | 172 
>  drivers/common/dpaa2/flib/rta/signature_cmd.h  |  40 +
>  drivers/common/dpaa2/flib/rta/store_cmd.h  | 149 
>  17 files changed, 5617 insertions(+)
>  create mode 100644 drivers/common/dpaa2/flib/README
>  create mode 100644 drivers/common/dpaa2/flib/compat.h
>  create mode 100644 drivers/common/dpaa2/flib/rta.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/fifo_load_store_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/header_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/jump_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/key_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/load_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/math_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/move_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/nfifo_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/operation_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/protocol_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/sec_run_time_asm.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/seq_in_out_ptr_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/signature_cmd.h
>  create mode 100644 drivers/common/dpaa2/flib/rta/store_cmd.h
> 
> diff --git a/drivers/common/dpaa2/flib/README 
> b/drivers/common/dpaa2/flib/README
> new file mode 100644
> index 000..a8b3358
> --- /dev/null
> +++ b/drivers/common/dpaa2/flib/README
> @@ -0,0 +1,43 @@
> +Copyright 2008-2013 Freescale Semiconductor, Inc.
> +
> +Runtime Assembler provides an easy and flexible runtime method for writing
> +SEC descriptors.
> +
> +1. What's supported
> +===
> +1.1 Initialization/verification code for descriptor buffer.
> +1.2 Configuration/verification code for SEC commands:
> +   FIFOLOAD and SEQFIFOLOAD;
> +   FIFOSTORE and SEQFIFOSTORE;
> +   SHARED HEADER and JOB HEADER;
> +   JUMP;
> +   KEY;
> +   LOAD and SEQLOAD;
> +   MATH;
> +   MOVE and MOVELEN;
> +   NFIFO - pseudo command (shortcut for writing FIFO entries using LOAD 
> command);
> +   PKA OPERATION and ALGORITHM OPERATION;
> +   PROTOCOL;
> +   SEQ IN PTR and SEQ OUT PTR;
> +   SIGNATURE;
> +   STORE and SEQSTORE.
> +1.3 Support for referential code:
> + patching routines for LOAD, MOVE, JUMP and HEADER commands.
> + raw patching (i.e. patch any 4-byte word from descriptor)
> +1.4 Support for extended (32/36/40-bit) pointer size.
> +1.5 SEC Eras 1-6
> + Below is a non-exhaustive list of platforms:
> + Era 1 - P4080R1
> + Era 2 - P4080R2
> + Era 3 - P1010, P1023, P3041, P5020
> + Era 4 - BSC9131, BSC9132, P4080R3
> + Era 5 - P5040, B4860, T4240R1
> + Era 6 - C290, T4240R2, T1040, T2080
> +
> +2. What's not supported
> +===
> +2.1 SEC Eras 7 and 8.
> +
> +3. Integration
> +==
> +To integrate this tool into your project, rta.h file must be included.
> diff --git a/drivers/common/dpaa2/flib/compat.h 
> b/drivers/common/dpaa2/flib/compat.h
> new file mode 100644
> index 000..bd946e1
> --- /dev/null
> +++ b/drivers/common/dpaa2/flib/compat.h
> @@ -0,0 +1,186 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause or GPL-2.0+
> + */
> +
> +#ifndef __RTA_COMPAT_H__
> +#define __RTA_COMPAT_H__
> +
> +#include 
> +#include 
> +
> +#ifdef __GLIBC__
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifndef __BYTE_ORDER__
> +#error "Undefined endianness"
> +#endif
> +
> +/* FSL's Embedded Warrior C Library; assum

Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation

[Ananyev, Konstantin]

Hi Jan,

>Hello,

>Sorry for late response.

>From ENA perspective, we need to dig deeper about the requirements and use 
>cases, but I'm pretty confident (95%) that ena will need to implement 
>tx_prep() API. There is at least one >scenario, when HW relay on partial 
>checksum.

Could you let us know as soon as you'll figure it out.
Hopefully will still be able to hit into 17.02 integration deadline.
Thanks
Konstantin

Re: [dpdk-dev] [PATCH v3 9/9] doc: update release notes

[Ferruh Yigit]

Hi Bernard,

On 12/12/2016 1:50 PM, Bernard Iremonger wrote:
> Add release note for removing set VF API's from the ethdev,
> renaming the API's and moving them to the ixgbe PMD.

Sorry, my bad, I wasn't clear enough.

I was thinking about updating "Shared Library Versions" section of the
release notes, and increasing the librte_ethdev.so version (from 5 to 6)
I believe new feature section does not require an update.

If you don't mind I can update library version with previous patch, and
you don't need to send a new version of the patch. Please let me know.

> 
> Signed-off-by: Bernard Iremonger 
> ---
>  doc/guides/rel_notes/release_17_02.rst | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/release_17_02.rst 
> b/doc/guides/rel_notes/release_17_02.rst
> index 3b65038..d30b258 100644
> --- a/doc/guides/rel_notes/release_17_02.rst
> +++ b/doc/guides/rel_notes/release_17_02.rst
> @@ -38,6 +38,26 @@ New Features
>   Also, make sure to start the actual text at the margin.
>   =
>  
> +* **Moved five APIs for VF management from the ethdev to the ixgbe PMD.**
> +
> +  The following five APIs for VF management from the PF have been removed 
> from the ethdev,
> +  renamed and added to the ixgbe PMD::
> +
> +rte_eth_dev_set_vf_rate_limit
> +rte_eth_dev_set_vf_rx
> +rte_eth_dev_set_vf_rxmode
> +rte_eth_dev_set_vf_tx
> +rte_eth_dev_set_vf_vlan_filter
> +
> +  The API's have been renamed to the following::
> +
> +rte_pmd_ixgbe_set_vf_rate_limit
> +rte_pmd_ixgbe_set_vf_rx
> +rte_pmd_ixgbe_set_vf_rxmode
> +rte_pmd_ixgbe_set_vf_tx
> +rte_pmd_ixgbe_set_vf_vlan_filter
> +
> +  The declarations for the API’s can be found in ``rte_pmd_ixgbe.h``.
>  
>  Resolved Issues
>  ---
> 

Re: [dpdk-dev] [PATCH v3 9/9] doc: update release notes

[Iremonger, Bernard]

Hi Ferruh,


> -Original Message-
> From: Yigit, Ferruh
> Sent: Monday, December 12, 2016 3:52 PM
> To: Iremonger, Bernard ;
> thomas.monja...@6wind.com; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 9/9] doc: update release notes
> 
> Hi Bernard,
> 
> On 12/12/2016 1:50 PM, Bernard Iremonger wrote:
> > Add release note for removing set VF API's from the ethdev, renaming
> > the API's and moving them to the ixgbe PMD.
> 
> Sorry, my bad, I wasn't clear enough.
> 
> I was thinking about updating "Shared Library Versions" section of the
> release notes, and increasing the librte_ethdev.so version (from 5 to 6) I
> believe new feature section does not require an update.
> 
> If you don't mind I can update library version with previous patch, and you
> don't need to send a new version of the patch. Please let me know.

Yes, that's fine with me.

 
> >
> > Signed-off-by: Bernard Iremonger 
> > ---
> >  doc/guides/rel_notes/release_17_02.rst | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/release_17_02.rst
> > b/doc/guides/rel_notes/release_17_02.rst
> > index 3b65038..d30b258 100644
> > --- a/doc/guides/rel_notes/release_17_02.rst
> > +++ b/doc/guides/rel_notes/release_17_02.rst
> > @@ -38,6 +38,26 @@ New Features
> >   Also, make sure to start the actual text at the margin.
> >
> =
> >
> > +* **Moved five APIs for VF management from the ethdev to the ixgbe
> > +PMD.**
> > +
> > +  The following five APIs for VF management from the PF have been
> > + removed from the ethdev,  renamed and added to the ixgbe PMD::
> > +
> > +rte_eth_dev_set_vf_rate_limit
> > +rte_eth_dev_set_vf_rx
> > +rte_eth_dev_set_vf_rxmode
> > +rte_eth_dev_set_vf_tx
> > +rte_eth_dev_set_vf_vlan_filter
> > +
> > +  The API's have been renamed to the following::
> > +
> > +rte_pmd_ixgbe_set_vf_rate_limit
> > +rte_pmd_ixgbe_set_vf_rx
> > +rte_pmd_ixgbe_set_vf_rxmode
> > +rte_pmd_ixgbe_set_vf_tx
> > +rte_pmd_ixgbe_set_vf_vlan_filter
> > +
> > +  The declarations for the API’s can be found in ``rte_pmd_ixgbe.h``.
> >
> >  Resolved Issues
> >  ---
> >
Regards,

Bernard.

Re: [dpdk-dev] [PATCH v3 9/9] doc: update release notes

[Ferruh Yigit]

On 12/12/2016 3:55 PM, Iremonger, Bernard wrote:
> Hi Ferruh,
> 
> 
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Monday, December 12, 2016 3:52 PM
>> To: Iremonger, Bernard ;
>> thomas.monja...@6wind.com; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v3 9/9] doc: update release notes
>>
>> Hi Bernard,
>>
>> On 12/12/2016 1:50 PM, Bernard Iremonger wrote:
>>> Add release note for removing set VF API's from the ethdev, renaming
>>> the API's and moving them to the ixgbe PMD.
>>
>> Sorry, my bad, I wasn't clear enough.
>>
>> I was thinking about updating "Shared Library Versions" section of the
>> release notes, and increasing the librte_ethdev.so version (from 5 to 6) I
>> believe new feature section does not require an update.
>>
>> If you don't mind I can update library version with previous patch, and you
>> don't need to send a new version of the patch. Please let me know.
> 
> Yes, that's fine with me.

It seems already increased for this release, by another patch, so no
change required there.

I will move your release notes changes to "API Changes" section.

> 
>  
>>>
>>> Signed-off-by: Bernard Iremonger 
>>> ---
>>>  doc/guides/rel_notes/release_17_02.rst | 20 
>>>  1 file changed, 20 insertions(+)
>>>
>>> diff --git a/doc/guides/rel_notes/release_17_02.rst
>>> b/doc/guides/rel_notes/release_17_02.rst
>>> index 3b65038..d30b258 100644
>>> --- a/doc/guides/rel_notes/release_17_02.rst
>>> +++ b/doc/guides/rel_notes/release_17_02.rst
>>> @@ -38,6 +38,26 @@ New Features
>>>   Also, make sure to start the actual text at the margin.
>>>
>> =
>>>
>>> +* **Moved five APIs for VF management from the ethdev to the ixgbe
>>> +PMD.**
>>> +
>>> +  The following five APIs for VF management from the PF have been
>>> + removed from the ethdev,  renamed and added to the ixgbe PMD::
>>> +
>>> +rte_eth_dev_set_vf_rate_limit
>>> +rte_eth_dev_set_vf_rx
>>> +rte_eth_dev_set_vf_rxmode
>>> +rte_eth_dev_set_vf_tx
>>> +rte_eth_dev_set_vf_vlan_filter
>>> +
>>> +  The API's have been renamed to the following::
>>> +
>>> +rte_pmd_ixgbe_set_vf_rate_limit
>>> +rte_pmd_ixgbe_set_vf_rx
>>> +rte_pmd_ixgbe_set_vf_rxmode
>>> +rte_pmd_ixgbe_set_vf_tx
>>> +rte_pmd_ixgbe_set_vf_vlan_filter
>>> +
>>> +  The declarations for the API’s can be found in ``rte_pmd_ixgbe.h``.
>>>
>>>  Resolved Issues
>>>  ---
>>>
> Regards,
> 
> Bernard.
> 

Re: [dpdk-dev] [PATCH v3 6/9] examples/ethtool: use ixgbe public function

[Ferruh Yigit]

On 12/12/2016 1:50 PM, Bernard Iremonger wrote:
> Replace rte_eth_dev_set_vf_rxmode with rte_pmd_ixgbe_set_vf_rx_mode.
> 
> Signed-off-by: Bernard Iremonger 
> ---
>  examples/ethtool/lib/rte_ethtool.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/examples/ethtool/lib/rte_ethtool.c 
> b/examples/ethtool/lib/rte_ethtool.c
> index a1f91d4..0e539f7 100644
> --- a/examples/ethtool/lib/rte_ethtool.c
> +++ b/examples/ethtool/lib/rte_ethtool.c
> @@ -1,7 +1,7 @@
>  /*-
>   *   BSD LICENSE
>   *
> - *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> + *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
>   *   All rights reserved.
>   *
>   *   Redistribution and use in source and binary forms, with or without
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "rte_ethtool.h"
>  
>  #define PKTPOOL_SIZE 512
> @@ -354,7 +355,7 @@ rte_ethtool_net_set_rx_mode(uint8_t port_id)
>  
>   /* Set VF vf_rx_mode, VF unsupport status is discard */
>   for (vf = 0; vf < num_vfs; vf++)
> - rte_eth_dev_set_vf_rxmode(port_id, vf,
> + rte_pmd_ixgbe_set_vf_rxmode(port_id, vf,

Will these cause a build error if IXGBE_PMD is not enabled?

>   ETH_VMDQ_ACCEPT_UNTAG, 0);
>  
>   /* Enable Rx vlan filter, VF unspport status is discard */
> 

[dpdk-dev] [PATCH v3] vhost: allow for many vhost user ports

[Jan Wickbom]

Currently select() is used to monitor file descriptors for vhostuser
ports. This limits the number of ports possible to create since the
fd number is used as index in the fd_set and we have seen fds > 1023.
This patch changes select() to poll(). This way we can keep an
packed (pollfd) array for the fds, e.g. as many fds as the size of
the array.

Also see:
http://dpdk.org/ml/archives/dev/2016-April/037024.html

Signed-off-by: Jan Wickbom 
Reported-by: Patrik Andersson 
---

v3:
* removed unnecessary include
* removed fdset_fill, made it functionally part of poll loop

v2:
* removed unnecessary casts
* static array replacing allocated memory

 lib/librte_vhost/fd_man.c | 194 +-
 lib/librte_vhost/fd_man.h |   2 +-
 2 files changed, 105 insertions(+), 91 deletions(-)

diff --git a/lib/librte_vhost/fd_man.c b/lib/librte_vhost/fd_man.c
index 2d3eeb7..c360d07 100644
--- a/lib/librte_vhost/fd_man.c
+++ b/lib/librte_vhost/fd_man.c
@@ -35,16 +35,40 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
 
 #include "fd_man.h"
 
+#define FDPOLLERR (POLLERR | POLLHUP | POLLNVAL)
+
+
+static struct pollfd rwfds[MAX_FDS];
+
+/**
+ * Adjusts the highest index populated in the array of fds
+ * @return
+ *   The new size of fdset.
+ */
+static void
+fdset_shrink(struct fdset *pfdset)
+{
+   int idx;
+
+   for (idx = pfdset->num - 1;
+idx >= 0 && pfdset->fd[idx].fd == -1;
+idx--)
+   ;
+
+   pfdset->num = idx + 1;
+}
+
 /**
  * Returns the index in the fdset for a given fd.
  * If fd is -1, it means to search for a free entry.
@@ -56,72 +80,32 @@
 {
int i;
 
-   if (pfdset == NULL)
-   return -1;
-
-   for (i = 0; i < MAX_FDS && pfdset->fd[i].fd != fd; i++)
+   for (i = 0; i < pfdset->num && pfdset->fd[i].fd != fd; i++)
;
 
-   return i ==  MAX_FDS ? -1 : i;
+   return i == pfdset->num ? -1 : i;
 }
 
 static int
 fdset_find_free_slot(struct fdset *pfdset)
 {
-   return fdset_find_fd(pfdset, -1);
+   if (pfdset->num < MAX_FDS)
+   return pfdset->num;
+   else
+   return fdset_find_fd(pfdset, -1);
 }
 
-static int
-fdset_add_fd(struct fdset  *pfdset, int idx, int fd,
+static void
+fdset_add_fd(struct fdset *pfdset, int idx, int fd,
fd_cb rcb, fd_cb wcb, void *dat)
 {
struct fdentry *pfdentry;
 
-   if (pfdset == NULL || idx >= MAX_FDS || fd >= FD_SETSIZE)
-   return -1;
-
pfdentry = &pfdset->fd[idx];
pfdentry->fd = fd;
pfdentry->rcb = rcb;
pfdentry->wcb = wcb;
pfdentry->dat = dat;
-
-   return 0;
-}
-
-/**
- * Fill the read/write fd_set with the fds in the fdset.
- * @return
- *  the maximum fds filled in the read/write fd_set.
- */
-static int
-fdset_fill(fd_set *rfset, fd_set *wfset, struct fdset *pfdset)
-{
-   struct fdentry *pfdentry;
-   int i, maxfds = -1;
-   int num = MAX_FDS;
-
-   if (pfdset == NULL)
-   return -1;
-
-   for (i = 0; i < num; i++) {
-   pfdentry = &pfdset->fd[i];
-   if (pfdentry->fd != -1) {
-   int added = 0;
-   if (pfdentry->rcb && rfset) {
-   FD_SET(pfdentry->fd, rfset);
-   added = 1;
-   }
-   if (pfdentry->wcb && wfset) {
-   FD_SET(pfdentry->fd, wfset);
-   added = 1;
-   }
-   if (added)
-   maxfds = pfdentry->fd < maxfds ?
-   maxfds : pfdentry->fd;
-   }
-   }
-   return maxfds;
 }
 
 void
@@ -132,6 +116,8 @@
if (pfdset == NULL)
return;
 
+   pthread_mutex_init(&pfdset->fd_mutex, NULL);
+
for (i = 0; i < MAX_FDS; i++) {
pfdset->fd[i].fd = -1;
pfdset->fd[i].dat = NULL;
@@ -152,14 +138,15 @@
 
pthread_mutex_lock(&pfdset->fd_mutex);
 
-   /* Find a free slot in the list. */
i = fdset_find_free_slot(pfdset);
-   if (i == -1 || fdset_add_fd(pfdset, i, fd, rcb, wcb, dat) < 0) {
+   if (i == -1) {
pthread_mutex_unlock(&pfdset->fd_mutex);
return -2;
}
 
-   pfdset->num++;
+   fdset_add_fd(pfdset, i, fd, rcb, wcb, dat);
+   if (i == pfdset->num)
+   pfdset->num++;
 
pthread_mutex_unlock(&pfdset->fd_mutex);
 
@@ -189,7 +176,7 @@
pfdset->fd[i].fd = -1;
pfdset->fd[i].rcb = pfdset->fd[i].wcb = NULL;
pfdset->fd[i].dat = NULL;
-   pfdset->num--;
+   fdset_shrink(pfdset);
i = -1;
}
p

Re: [dpdk-dev] [PATCH] vhost: allow for many vhost user ports

[Jan Wickbom]

> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan@linux.intel.com]
> Sent: den 8 december 2016 06:51
> To: Jan Wickbom 
> Cc: dev@dpdk.org; Patrik Andersson R 
> Subject: Re: [PATCH] vhost: allow for many vhost user ports
> 
> On Wed, Dec 07, 2016 at 01:23:48PM +, Jan Wickbom wrote:
> > > On Thu, Dec 01, 2016 at 04:26:50PM +0100, Jan Wickbom wrote:
> > > >  static int
> > > > -fdset_fill(fd_set *rfset, fd_set *wfset, struct fdset *pfdset)
> > > > +fdset_fill(struct pollfd *rwfds, struct fdset *pfdset)
> ...
> > > > +   rwfds[i].fd = pfdentry->fd;
> > > > +   rwfds[i].events = pfdentry->rcb ? POLLIN : 0;
> > > > +   rwfds[i].events |= pfdentry->wcb ? POLLOUT :
> > > 0;
> > >
> > > Another thing is we don't have to re-init this rwfds array again
> > > and again. Instead, we could
> > >
> > > - set it up correctly when fdset_add is invoked: set the fd and
> > >   events.
> > >
> > > - reset revents when it's been handled at fdset_event_dispatch().
> > >
> > > - swap with the last one and shrink the array on fd delete
> > >
> > > Could you make a follow up patch for that?
> >
> > I don't see how that could easily be done. The loop index, i, is a direct
> reference between
> > an entry in the rwfds array and an entry in the pfdset array. It should stay
> like that while we are
> > hanging in the poll(). If  an entry in the pfdset array is removed while we
> are hanging in the poll()
> > and we then immediately replaces it with the last entry in the array we will
> end up in trouble if the
> > revent gets set for the "replaced" index. The direct reference is gone.
> > Or am I missing something?
> 
> Yes, we should not shrink the rwfds during the poll, but we could later, at
> the end of the while() loop.

Did something in v3, please have a look.

> 
> Talking about that, you should not invoke fdset_shrink() inside fdset_del(),
> since it could be in the poll stage.

Thanks! Forgot this! Will send a v4

> 
>   --yliu

Re: [dpdk-dev] [PATCH 1/7] net/qede: reduce noise in debug logs

[Harish Patil]

Hi Ferruh,

>On 12/3/2016 2:43 AM, Harish Patil wrote:
>> From: Rasesh Mody 
>> 
>> Replace CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER with
>> CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL which is a 32-bit bitmapped value
>> where each bit represent a particular submodule to debug. Also move
>> notice messages under CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO.
>> 
>> Signed-off-by: Harish Patil 
>> Signed-off-by: Rasesh Mody 
>> ---
>>  config/common_base |  2 +-
>>  doc/guides/nics/qede.rst   |  4 ++--
>>  drivers/net/qede/qede_ethdev.c |  4 ++--
>>  drivers/net/qede/qede_logs.h   | 21 +
>>  4 files changed, 10 insertions(+), 21 deletions(-)
>> 
>> diff --git a/config/common_base b/config/common_base
>> index 4bff83a..2ffd557 100644
>> --- a/config/common_base
>> +++ b/config/common_base
>> @@ -320,7 +320,7 @@ CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>>  CONFIG_RTE_LIBRTE_QEDE_PMD=y
>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
>> -CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=n
>> +CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL=0
>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
>>  #Provides abs path/name of the firmware file.
>> diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
>> index d22ecdd..ddf4248 100644
>> --- a/doc/guides/nics/qede.rst
>> +++ b/doc/guides/nics/qede.rst
>> @@ -103,9 +103,9 @@ enabling debugging options may affect system
>>performance.
>>  
>>Toggle display of generic debugging messages.
>>  
>> -- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER`` (default **n**)
>> +- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL`` (default **0**)
>
>Does it make sense to document how DEBUG_VAL used?
>
>Also commit log says bitmapped value to enable/disable a particular
>submodule, you may want to document here which value enable/disable
>which submodule.
>
>>  
>> -  Toggle display of ecore related messages.
>> +  Control driver debug verbosity using 32-bit bitmap flags.
>>  
>>  - ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX`` (default **n**)
>>  

Not really, I think that would be too much. But if you think it really
helps then perhaps yes we can document.
Otherwise it is just for internal debugging.


>
><...>
>
>> diff --git a/drivers/net/qede/qede_logs.h b/drivers/net/qede/qede_logs.h
>> index 45c4af0..08fdf04 100644
>> --- a/drivers/net/qede/qede_logs.h
>> +++ b/drivers/net/qede/qede_logs.h
>> @@ -16,15 +16,18 @@
>>  (p_dev)->name ? (p_dev)->name : "", \
>>  ##__VA_ARGS__)
>>  
>> +#ifdef RTE_LIBRTE_QEDE_DEBUG_INFO
>
>Is "_INFO" carries any meaning in this config option, why not just
>RTE_LIBRTE_QEDE_DEBUG?

INFO is used to mean just informational type of messages.
If you think it doesn’t make sense then I can rename it.

>
>>  #define DP_NOTICE(p_dev, is_assert, fmt, ...) \
>>  rte_log(RTE_LOG_NOTICE, RTE_LOGTYPE_PMD,\
>>  "[QEDE PMD: (%s)]%s:" fmt, \
>>  (p_dev)->name ? (p_dev)->name : "", \
>>   __func__, \
>>  ##__VA_ARGS__)
>> +#else
>> +#define DP_NOTICE(p_dev, fmt, ...) do { } while (0)
>> +#endif
>>  
>>  #ifdef RTE_LIBRTE_QEDE_DEBUG_INFO
>> -
>>  #define DP_INFO(p_dev, fmt, ...) \
>>  rte_log(RTE_LOG_INFO, RTE_LOGTYPE_PMD, \
>>  "[%s:%d(%s)]" fmt, \
>> @@ -33,10 +36,8 @@
>>  ##__VA_ARGS__)
>>  #else
>>  #define DP_INFO(p_dev, fmt, ...) do { } while (0)
>> -
>>  #endif
>>  
>> -#ifdef RTE_LIBRTE_QEDE_DEBUG_DRIVER
>
>Are you sure you want to enable DP_VERBOSE, I guess most verbose log
>macro, by default? Perhaps may want to control it via
>RTE_LIBRTE_QEDE_DEBUG_INFO?

DP_VERBOSE is enabled but it has a check:
 if ((p_dev)->dp_module & module)
which controls what to print.
Here dp_module is controlled by CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL flag.
Hope it is clear.
>
>>  #define DP_VERBOSE(p_dev, module, fmt, ...) \
>>  do { \
>>  if ((p_dev)->dp_module & module) \
>> @@ -46,9 +47,7 @@
>>(p_dev)->name ? (p_dev)->name : "", \
>>##__VA_ARGS__); \
>>  } while (0)
>> -#else
>> -#define DP_VERBOSE(p_dev, fmt, ...) do { } while (0)
>> -#endif
>> +
>>  
><...>
>
>

Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation

[Ananyev, Konstantin]

> > > This means vmxnet3 PMD also should be updated, right?
> >
> > Yes, that's right.
> >
> > >Should that update
> > > be part of tx_prep patchset? Or separate patch?
> >
> > Another question I suppose is who will do the actual patch for vmxnet3.
> > Yong, are you ok to do the patch for vmxnet3, or prefer us to do that?
> > Please note, that in both cases will need your help in testing/reviewing it.
> > Konstantin
> 
> It will be great if you can put together a patch as part of the entire 
> patchset on tx_prep() for vmxnet3 and I will definitely help review
> it.

Ok. 

> 
> Regarding testing, I can definitely help but I don't have a testing harness 
> to cover the entire matrix (different ESX version, different
> vmxnet3 device version, VM-VM, VM-physical over different uplinks, etc.) so 
> it will be limited.  Related to this, I have the impression
> that Intel has some existing coverage for vmxnet3 as well as other NICs.  Do 
> we know if that will cover this use case as well?

I'll ask our validation team, but I don't know off-hand what coverage for 
vmxnet3 we have.
Konstantin


> 
> > >
> > > >>>
> > > >>
> > > > This is for any TX offload for which the upper layer SW would have
> > > >>
> > > > to modify the contents of the packet.
> > > >>
> > > > Though as I can see for qede neither PKT_TX_IP_CKSUM or
> > > >>
> > >  PKT_TX_TCP_CKSUM
> > > >>
> > > > exhibits any extra requirements for the user.
> > > >>
> > > > Is that correct?
> > > >>
> > > >>
> > > >

Re: [dpdk-dev] [PATCH 2/7] net/qede: refactor filtering code

[Harish Patil]

>On 12/3/2016 2:43 AM, Harish Patil wrote:
>> The filter_config in qed_eth_ops_pass is a wrapper call driving all the
>> filtering configuration. This requires defining multiple structures and
>> passing different function arguments for each filter type which is
>> unnecessary. So as part of this refactoring we remove filter_config from
>> qed_eth_ops_pass and invoke base apis directly. Another change is to
>> use a singly list for unicast/multicast macs and thereby prevent
>>duplicate
>
>singly linked list?

Yes. Two lists to track unicast and multicast mac entries:
+   SLIST_HEAD(mc_list_head, qede_mcast_entry) mc_list_head;

+   SLIST_HEAD(uc_list_head, qede_ucast_entry) uc_list_head;



>
>> entries.
>> 
>> This change is primarily intended to support future tunneling support
>> which makes use of existing L2 filtering/classifications.
>> 
>> Fixes: 2ea6f76a ("qede: add core driver")
>
>What is fixed in this patch, isn't it a refactor?

The fix part is to make use of the newly added lists and prevent duplicate
mac filters.
Before that there were no checks. Other than that its refactoring to
mainly invoke direct base APIs.

>
>btw, all Fixes formats are wrong in the patchset, can you please use the
>git alias provided:
>http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-body
>
>> 
>> Signed-off-by: Harish Patil 
>> ---
><...>
>

Re: [dpdk-dev] [PATCH 6/7] net/qede: fix maximum VF count to 0

[Harish Patil]

>On 12/3/2016 2:43 AM, Harish Patil wrote:
>> Set max_vfs to 0 since it is relevant only to SR-IOV PF
>> which is not supported yet.
>> 
>> Fixes: 2ea6f76a ("qede: add core driver")
>> 
>> Signed-off-by: Harish Patil 
>
>Can you please update patch title to indicate what has been fixed
>instead of what has been done in the patch.

Can you please clarify? The change in the patch is to set max_vfs=0.
So that’s why the title - "fix maximum VF count to 0"

>
>
>btw, while checking feature list, I have seen qede_vf supports SR-IOV,
>is that correct?

Yes. The supported combination for SR-IOV is VF driver (qede PMD) with PF
driver (qede linux driver).
We don’t have support for SR-IOV PF driver yet. When SR-IOV PF driver is
supported then max_vfs shall return the actual max VFs, but for now it
should return max_vfs=0. Hope it is clear.

>
>> ---
>>  drivers/net/qede/qede_ethdev.c | 5 +
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>> 
>> diff --git a/drivers/net/qede/qede_ethdev.c
>>b/drivers/net/qede/qede_ethdev.c
>> index ee8fb43..10abb8b 100644
>> --- a/drivers/net/qede/qede_ethdev.c
>> +++ b/drivers/net/qede/qede_ethdev.c
>> @@ -976,10 +976,7 @@ static int qede_dev_configure(struct rte_eth_dev
>>*eth_dev)
>>  dev_info->max_rx_queues = (uint16_t)QEDE_MAX_RSS_CNT(qdev);
>>  dev_info->max_tx_queues = dev_info->max_rx_queues;
>>  dev_info->max_mac_addrs = qdev->dev_info.num_mac_addrs;
>> -if (IS_VF(edev))
>> -dev_info->max_vfs = 0;
>> -else
>> -dev_info->max_vfs = (uint16_t)NUM_OF_VFS(&qdev->edev);
>> +dev_info->max_vfs = 0;
>>  dev_info->reta_size = ECORE_RSS_IND_TABLE_SIZE;
>>  dev_info->hash_key_size = ECORE_RSS_KEY_SIZE * sizeof(uint32_t);
>>  dev_info->flow_type_rss_offloads = (uint64_t)QEDE_RSS_OFFLOAD_ALL;
>> 
>
>

Re: [dpdk-dev] [PATCH 1/7] net/qede: reduce noise in debug logs

[Ferruh Yigit]

On 12/12/2016 5:15 PM, Harish Patil wrote:
> Hi Ferruh,
> 
>> On 12/3/2016 2:43 AM, Harish Patil wrote:
>>> From: Rasesh Mody 
>>>
>>> Replace CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER with
>>> CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL which is a 32-bit bitmapped value
>>> where each bit represent a particular submodule to debug. Also move
>>> notice messages under CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO.
>>>
>>> Signed-off-by: Harish Patil 
>>> Signed-off-by: Rasesh Mody 
>>> ---
>>>  config/common_base |  2 +-
>>>  doc/guides/nics/qede.rst   |  4 ++--
>>>  drivers/net/qede/qede_ethdev.c |  4 ++--
>>>  drivers/net/qede/qede_logs.h   | 21 +
>>>  4 files changed, 10 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/config/common_base b/config/common_base
>>> index 4bff83a..2ffd557 100644
>>> --- a/config/common_base
>>> +++ b/config/common_base
>>> @@ -320,7 +320,7 @@ CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>>>  CONFIG_RTE_LIBRTE_QEDE_PMD=y
>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
>>> -CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=n
>>> +CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL=0
>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
>>>  CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
>>>  #Provides abs path/name of the firmware file.
>>> diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
>>> index d22ecdd..ddf4248 100644
>>> --- a/doc/guides/nics/qede.rst
>>> +++ b/doc/guides/nics/qede.rst
>>> @@ -103,9 +103,9 @@ enabling debugging options may affect system
>>> performance.
>>>  
>>>Toggle display of generic debugging messages.
>>>  
>>> -- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER`` (default **n**)
>>> +- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL`` (default **0**)
>>
>> Does it make sense to document how DEBUG_VAL used?
>>
>> Also commit log says bitmapped value to enable/disable a particular
>> submodule, you may want to document here which value enable/disable
>> which submodule.
>>
>>>  
>>> -  Toggle display of ecore related messages.
>>> +  Control driver debug verbosity using 32-bit bitmap flags.
>>>  
>>>  - ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX`` (default **n**)
>>>  
> 
> Not really, I think that would be too much. But if you think it really
> helps then perhaps yes we can document.
> Otherwise it is just for internal debugging.

As a user of your driver, how can I know how to enable / disable a
module log?
I know VAL enables / disables them, but I don't know what modules exists
and what values are required.

If this is just for internal debugging and user not need to configure
this one, does it needs to be a config option in configuration file?

> 
> 
>>
>> <...>
>>
>>> diff --git a/drivers/net/qede/qede_logs.h b/drivers/net/qede/qede_logs.h
>>> index 45c4af0..08fdf04 100644
>>> --- a/drivers/net/qede/qede_logs.h
>>> +++ b/drivers/net/qede/qede_logs.h
>>> @@ -16,15 +16,18 @@
>>> (p_dev)->name ? (p_dev)->name : "", \
>>> ##__VA_ARGS__)
>>>  
>>> +#ifdef RTE_LIBRTE_QEDE_DEBUG_INFO
>>
>> Is "_INFO" carries any meaning in this config option, why not just
>> RTE_LIBRTE_QEDE_DEBUG?
> 
> INFO is used to mean just informational type of messages.
> If you think it doesn’t make sense then I can rename it.

I don't have a strong opinion, I think that _INFO is not adding value
unless you have different config options per each level like _VERBOSE,
_INFO, _NOTICE. But if you believe your users will benefit from it, it
is your call.

> 
>>
>>>  #define DP_NOTICE(p_dev, is_assert, fmt, ...) \
>>> rte_log(RTE_LOG_NOTICE, RTE_LOGTYPE_PMD,\
>>> "[QEDE PMD: (%s)]%s:" fmt, \
>>> (p_dev)->name ? (p_dev)->name : "", \
>>>  __func__, \
>>> ##__VA_ARGS__)
>>> +#else
>>> +#define DP_NOTICE(p_dev, fmt, ...) do { } while (0)
>>> +#endif
>>>  
>>>  #ifdef RTE_LIBRTE_QEDE_DEBUG_INFO
>>> -
>>>  #define DP_INFO(p_dev, fmt, ...) \
>>> rte_log(RTE_LOG_INFO, RTE_LOGTYPE_PMD, \
>>> "[%s:%d(%s)]" fmt, \
>>> @@ -33,10 +36,8 @@
>>> ##__VA_ARGS__)
>>>  #else
>>>  #define DP_INFO(p_dev, fmt, ...) do { } while (0)
>>> -
>>>  #endif
>>>  
>>> -#ifdef RTE_LIBRTE_QEDE_DEBUG_DRIVER
>>
>> Are you sure you want to enable DP_VERBOSE, I guess most verbose log
>> macro, by default? Perhaps may want to control it via
>> RTE_LIBRTE_QEDE_DEBUG_INFO?
> 
> DP_VERBOSE is enabled but it has a check:
>  if ((p_dev)->dp_module & module)
> which controls what to print.
> Here dp_module is controlled by CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL flag.
> Hope it is clear.

Clear thanks,

I guess right now:
DEBUG_VAL: enables verbose debug for selected module(s)
DEBUG_INFO: Enables NOTICE and INFO level for ? (all modules?)
ERR level is always enabled

Again it is your call, but I think CONFIG_RTE_LIBRTE_QEDE_DEBUG can be
used to enable/disable all debugs, and when enabled QEDE_DEBUG_VAL can
select which modules to enable verbose debug ...

>>
>>>  #define DP_VERBOSE(p_dev, module, fmt, ...) \
>>>  do { \
>>> if ((p_dev)->dp_module & module) \
>>> @@

Re: [dpdk-dev] [PATCH 2/7] net/qede: refactor filtering code

[Ferruh Yigit]

On 12/12/2016 5:36 PM, Harish Patil wrote:
> 
>> On 12/3/2016 2:43 AM, Harish Patil wrote:
>>> The filter_config in qed_eth_ops_pass is a wrapper call driving all the
>>> filtering configuration. This requires defining multiple structures and
>>> passing different function arguments for each filter type which is
>>> unnecessary. So as part of this refactoring we remove filter_config from
>>> qed_eth_ops_pass and invoke base apis directly. Another change is to
>>> use a singly list for unicast/multicast macs and thereby prevent
>>> duplicate
>>
>> singly linked list?
> 
> Yes. Two lists to track unicast and multicast mac entries:
> +   SLIST_HEAD(mc_list_head, qede_mcast_entry) mc_list_head;
> 
> +   SLIST_HEAD(uc_list_head, qede_ucast_entry) uc_list_head;
> 
> 
> 
>>
>>> entries.
>>>
>>> This change is primarily intended to support future tunneling support
>>> which makes use of existing L2 filtering/classifications.
>>>
>>> Fixes: 2ea6f76a ("qede: add core driver")
>>
>> What is fixed in this patch, isn't it a refactor?
> 
> The fix part is to make use of the newly added lists and prevent duplicate
> mac filters.
> Before that there were no checks. Other than that its refactoring to
> mainly invoke direct base APIs.

So this is not fixing any defect in driver, so I believe Fixes tag can
be removed. This tag is mainly useful to pick commits for stable trees.

> 
>>
>> btw, all Fixes formats are wrong in the patchset, can you please use the
>> git alias provided:
>> http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-body
>>
>>>
>>> Signed-off-by: Harish Patil 
>>> ---
>> <...>
>>
> 
> 

[dpdk-dev] [PATCH] vhost: Introduce vhost-user's REPLY_ACK feature

[Maxime Coquelin]

REPLY_ACK features provide a generic way for QEMU to ensure both
completion and success of a request.

As described in vhost-user spec in QEMU repository, QEMU sets
VHOST_USER_NEED_REPLY flag (bit 3) when expecting a reply_ack from
the backend. Backend must reply with 0 for success or non-zero
otherwise when flag is set.

Currently, only VHOST_USER_SET_MEM_TABLE request implements reply_ack,
in order to synchronize mapping updates.

This patch enables REPLY_ACK feature generally, but only checks error
code for VHOST_USER_SET_MEM_TABLE.

Signed-off-by: Maxime Coquelin 
---
Hi,

The intend of this patch is not to fix a known issue, but it is
nice to have this feature, and it will be used by upcoming MTU
feature if it remains in its current form.

Thanks,
Maxime

 lib/librte_vhost/vhost_user.c | 11 ++-
 lib/librte_vhost/vhost_user.h |  5 -
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 6b83c15..9ce80cb 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -903,6 +903,7 @@ send_vhost_message(int sockfd, struct VhostUserMsg *msg)
return 0;
 
msg->flags &= ~VHOST_USER_VERSION_MASK;
+   msg->flags &= ~VHOST_USER_NEED_REPLY;
msg->flags |= VHOST_USER_VERSION;
msg->flags |= VHOST_USER_REPLY_MASK;
 
@@ -938,6 +939,7 @@ vhost_user_msg_handler(int vid, int fd)
return -1;
}
 
+   ret = 0;
RTE_LOG(INFO, VHOST_CONFIG, "read message %s\n",
vhost_message_str[msg.request]);
switch (msg.request) {
@@ -967,7 +969,7 @@ vhost_user_msg_handler(int vid, int fd)
break;
 
case VHOST_USER_SET_MEM_TABLE:
-   vhost_user_set_mem_table(dev, &msg);
+   ret = vhost_user_set_mem_table(dev, &msg);
break;
 
case VHOST_USER_SET_LOG_BASE:
@@ -1025,9 +1027,16 @@ vhost_user_msg_handler(int vid, int fd)
break;
 
default:
+   ret = -1;
break;
 
}
 
+   if (msg.flags & VHOST_USER_NEED_REPLY) {
+   msg.payload.u64 = !!ret;
+   msg.size = sizeof(msg.payload.u64);
+   send_vhost_message(fd, &msg);
+   }
+
return 0;
 }
diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
index ba78d32..179e441 100644
--- a/lib/librte_vhost/vhost_user.h
+++ b/lib/librte_vhost/vhost_user.h
@@ -46,10 +46,12 @@
 #define VHOST_USER_PROTOCOL_F_MQ   0
 #define VHOST_USER_PROTOCOL_F_LOG_SHMFD1
 #define VHOST_USER_PROTOCOL_F_RARP 2
+#define VHOST_USER_PROTOCOL_F_REPLY_ACK3
 
 #define VHOST_USER_PROTOCOL_FEATURES   ((1ULL << VHOST_USER_PROTOCOL_F_MQ) | \
 (1ULL << 
VHOST_USER_PROTOCOL_F_LOG_SHMFD) |\
-(1ULL << VHOST_USER_PROTOCOL_F_RARP))
+(1ULL << VHOST_USER_PROTOCOL_F_RARP) | 
\
+(1ULL << 
VHOST_USER_PROTOCOL_F_REPLY_ACK))
 
 typedef enum VhostUserRequest {
VHOST_USER_NONE = 0,
@@ -98,6 +100,7 @@ typedef struct VhostUserMsg {
 
 #define VHOST_USER_VERSION_MASK 0x3
 #define VHOST_USER_REPLY_MASK   (0x1 << 2)
+#define VHOST_USER_NEED_REPLY  (0x1 << 3)
uint32_t flags;
uint32_t size; /* the following payload size */
union {
-- 
2.9.3

Re: [dpdk-dev] [RFC PATCH] eventdev: add buffered enqueue and flush APIs

[Eads, Gage]

>  -Original Message-
>  From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
>  Sent: Wednesday, December 7, 2016 10:42 PM
>  To: Eads, Gage 
>  Cc: dev@dpdk.org; Richardson, Bruce ; Van
>  Haaren, Harry ; hemant.agra...@nxp.com
>  Subject: Re: [RFC PATCH] eventdev: add buffered enqueue and flush APIs
>  
>  On Mon, Dec 05, 2016 at 11:30:46PM +, Eads, Gage wrote:
>  >
>  > > On Dec 3, 2016, at 5:18 AM, Jerin Jacob
>   wrote:
>  > >
>  > >> On Fri, Dec 02, 2016 at 01:45:56PM -0600, Gage Eads wrote:
>  > >> This commit adds buffered enqueue functionality to the eventdev API.
>  > >> It is conceptually similar to the ethdev API's tx buffering,
>  > >> however with a smaller API surface and no dropping of events.
>  > >
>  > > Hello Gage,
>  > > Different implementation may have different strategies to hold the 
> buffers.
>  >
>  > A benefit of inlining the buffering logic in the header is that we avoid 
> the
>  overhead of entering the PMD for what is a fairly simple operation (common
>  case: add event to an array, increment counter). If we make this
>  implementation-defined (i.e. use PMD callbacks), we lose that benefit.
>  In general, I agree from the system perspective. But, few general issues with
>  eventdev integration part,
>  
>  1) What if the burst has ATOMIC flows and if we are NOT en-queuing to the
>  implementation then other event ports won't get the packets from the same
>  ATOMIC tag ? BAD. Right?

I'm not sure what scenario you're describing here. The buffered (as implemented 
in my patch) and non-buffered enqueue operations are functionally the same (as 
long as the buffer is flushed), the difference lies in when the events are 
moved from the application level to the PMD.

>  2) At least, In our HW implementation, The event buffer strategy is more 
> like, if
>  you enqueue to HW then ONLY you get the events from dequeue provided if op
>  == RTE_EVENT_OP_FORWARD.So it will create deadlock.i.e application cannot
>  hold the events with RTE_EVENT_OP_FORWARD

If I'm reading this correctly, you're concerned that buffered events can result 
in deadlock if they're not flushed. Whether the buffering is done in the app 
itself, inline in the API, or in the PMDs, not flushing the buffer is an 
application bug. E.g. the app could be fixed by flushing its enqueue buffer 
after processing every burst dequeued event set, or only if dequeue returns 0 
events.

>  3) So considering the above case there is nothing like flush for us
>  4) In real high throughput benchmark case, we will get the packets at the 
> rate
>  of max burst and then we always needs to memcpy before we flush.
>  Otherwise there will be ordering issue as burst can get us the packet from
>  different flows(unlike polling mode)

I take it you're referring to the memcpy in the patch, and not an additional 
memcpy? At any rate, I'm hoping that SIMD instructions can optimize the 16B 
event copy.

>  
>  >
>  > > and some does not need to hold the buffers if it is DDR backed.
>  >
>  > Though DDR-backed hardware doesn't need to buffer in software, doing so
>  would reduce the software overhead of enqueueing. Compared to N individual
>  calls to enqueue, buffering N events then calling enqueue burst once can
>  benefit from amortized (or parallelized) PMD-specific bookkeeping and error-
>  checking across the set of events, and will definitely benefit from the 
> amortized
>  function call overhead and better I-cache behavior. (Essentially this is VPP 
> from
>  the fd.io project.) This should result in higher overall event throughout
>  (agnostic of the underlying device).
>  
>  See above. I am not against burst processing in "application".
>  The flush does not make sense for us in HW perspective and it is costly for 
> us if
>  we trying generalize it.
>  

Besides the data copy that buffering requires, are there additional costs from 
your perspective?

>  >
>  > I'm skeptical that other buffering strategies would emerge, but I can only
>  speculate on Cavium/NXP/etc. NPU software.
>  i>
>  > > IHMO, This may not be the candidate for common code. I guess you can
>  > > move this to driver side and abstract under SW driver's enqueue_burst.
>  > >
>  >
>  > I don't think that will work without adding a flush API, otherwise we could
>  have indefinitely buffered events. I see three ways forward:
>  
>  I agree. More portable way is to move the "flush" to the implementation and
>  "flush"
>  whenever it makes sense to PMD.
>  
>  >
>  > - The proposed approach
>  > - Add the proposed functions but make them implementation-specific.
>  > - Require the application to write its own buffering logic (i.e. no
>  > API change)
>  
>  I think, If the additional function call overhead cost is too much for SW
>  implementation then we can think of implementation-specific API or custom
>  application flow based on SW driver.
>  
>  But I am not fan of that(but tempted do now a days), If we take that route, 
> we
>  have trucklo

Re: [dpdk-dev] [PATCH 6/7] net/qede: fix maximum VF count to 0

[Ferruh Yigit]

On 12/12/2016 5:47 PM, Harish Patil wrote:
> 
>> On 12/3/2016 2:43 AM, Harish Patil wrote:
>>> Set max_vfs to 0 since it is relevant only to SR-IOV PF
>>> which is not supported yet.
>>>
>>> Fixes: 2ea6f76a ("qede: add core driver")
>>>
>>> Signed-off-by: Harish Patil 
>>
>> Can you please update patch title to indicate what has been fixed
>> instead of what has been done in the patch.
> 
> Can you please clarify? The change in the patch is to set max_vfs=0.
> So that’s why the title - "fix maximum VF count to 0"

Let me try, if I can :)

I can see what patch does, and I got the reasoning behind.

Previously driver was reporting as it was supporting SR-IOV with DPDK
PF, right? But it was wrong and you are fixing it.

How you fix is by setting max_vfs=0, but that is the technical detail of
the fix.

What you are trying to fix is not setting a variable to a specific
value, what you are trying to fix is SR-IOV support.

I hope I can make it more clear.

> 
>>
>>
>> btw, while checking feature list, I have seen qede_vf supports SR-IOV,
>> is that correct?
> 
> Yes. The supported combination for SR-IOV is VF driver (qede PMD) with PF
> driver (qede linux driver).

So you are using SR-IOV feature set in VF driver, as meaning VF driver
support exists. I don't know what SR-IOV feature mean for VF drivers.
Some other VF drivers not has this feature flag set.

CC'ed Thomas for help, if this is the intention of the feature flag, it
is OK.

> We don’t have support for SR-IOV PF driver yet. When SR-IOV PF driver is
> supported then max_vfs shall return the actual max VFs, but for now it
> should return max_vfs=0. Hope it is clear.
> 
>>
>>> ---
>>>  drivers/net/qede/qede_ethdev.c | 5 +
>>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/qede/qede_ethdev.c
>>> b/drivers/net/qede/qede_ethdev.c
>>> index ee8fb43..10abb8b 100644
>>> --- a/drivers/net/qede/qede_ethdev.c
>>> +++ b/drivers/net/qede/qede_ethdev.c
>>> @@ -976,10 +976,7 @@ static int qede_dev_configure(struct rte_eth_dev
>>> *eth_dev)
>>> dev_info->max_rx_queues = (uint16_t)QEDE_MAX_RSS_CNT(qdev);
>>> dev_info->max_tx_queues = dev_info->max_rx_queues;
>>> dev_info->max_mac_addrs = qdev->dev_info.num_mac_addrs;
>>> -   if (IS_VF(edev))
>>> -   dev_info->max_vfs = 0;
>>> -   else
>>> -   dev_info->max_vfs = (uint16_t)NUM_OF_VFS(&qdev->edev);
>>> +   dev_info->max_vfs = 0;
>>> dev_info->reta_size = ECORE_RSS_IND_TABLE_SIZE;
>>> dev_info->hash_key_size = ECORE_RSS_KEY_SIZE * sizeof(uint32_t);
>>> dev_info->flow_type_rss_offloads = (uint64_t)QEDE_RSS_OFFLOAD_ALL;
>>>
>>
>>
> 
> 

Re: [dpdk-dev] [PATCH] vmxnet3: fix Rx deadlock

[Yong Wang]

> -Original Message-
> From: Stefan Puiu [mailto:stefan.p...@gmail.com]
> Sent: Monday, December 12, 2016 12:27 AM
> To: Yong Wang 
> Cc: dev@dpdk.org; mac_le...@yahoo.com.hk
> Subject: Re: [PATCH] vmxnet3: fix Rx deadlock
> 
> Hello and thanks for reviewing the patch.
> 
> On Wed, Nov 30, 2016 at 6:59 AM, Yong Wang 
> wrote:
> [...]
> > I think a more accurate description is that the particular descriptor's
> generation bit never got flipped properly when an mbuf failed to be refilled
> which caused the rx stuck, rather than vmxnet3_post_rx_bufs() not being
> called afterwards.
> >
> 
> Not sure if this kind of level of detail is useful, but if you can
> think of a better explanation to put in the changelist, I can add it.
> I see the generation bit not flipping as a symptom, while the core
> problem is the hardware can't write to the descriptor. I felt the
> explanation was going into too much detail anyway, so I've reworded it
> a bit for v2. Let me know what you think.

This is one of the cases that I prefer accuracy and I think the level of 
details is needed for whoever will work on this part of the code (datapath tx 
and rx routines).

The v2 description looks good to me expect the following description:

"nobody retries this later, so the driver gets stuck in this state."

The driver definitely retries vmxnet3_post_rx_bufs() after it was in the 
problematic state but due to the descriptor's gen bit not flipped, the driver 
won't refill an mbuf.  How about "the driver won't refill the mbuf after this 
so it gets stuck in this state."?

> Thanks,
> Stefan.

Re: [dpdk-dev] [PATCH v12] net/tap: new TUN/TAP device PMD

[Marc]

Keith,

A bit late, but two very high level questions. Do you have performance
numbers compared to KNI? Did you consider using AF_PACKET PACKET_MMAP which
could potentially reduce the number of syscalls to 1 for RX and TX of a
burst?

Marc

On 12 December 2016 at 15:38, Keith Wiles  wrote:

> The PMD allows for DPDK and the host to communicate using a raw
> device interface on the host and in the DPDK application. The device
> created is a Tap device with a L2 packet header.
>
> v12- Fixup minor changes for driver_name and version number
> v11- Add the tap.rst to the nic/index.rst file
> v10- Change the string name used to allow for multiple devices.
> v9 - Fix up the docs to use correct syntax
> v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
> v7 - Reword the comment in common_base and fix the data->name issue
> v6 - fixed the checkpatch issues
> v5 - merge in changes from list review see related emails
>  fixed many minor edits
> v4 - merge with latest driver changes
> v3 - fix includes by removing ifdef for other type besides Linux
>  Fix the copyright notice in the Makefile
> v2 - merge all of the patches into one patch
>  Fix a typo on naming the tap device
>  Update the maintainers list
>
> Signed-off-by: Keith Wiles 
> ---
>  MAINTAINERS |   5 +
>  config/common_base  |   9 +
>  config/common_linuxapp  |   1 +
>  doc/guides/nics/index.rst   |   1 +
>  doc/guides/nics/tap.rst | 136 ++
>  drivers/net/Makefile|   1 +
>  drivers/net/tap/Makefile|  57 +++
>  drivers/net/tap/rte_eth_tap.c   | 765
> 
>  drivers/net/tap/rte_pmd_tap_version.map |   4 +
>  mk/rte.app.mk   |   1 +
>  10 files changed, 980 insertions(+)
>  create mode 100644 doc/guides/nics/tap.rst
>  create mode 100644 drivers/net/tap/Makefile
>  create mode 100644 drivers/net/tap/rte_eth_tap.c
>  create mode 100644 drivers/net/tap/rte_pmd_tap_version.map
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 26d9590..842fb6d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -398,6 +398,11 @@ F: doc/guides/nics/pcap_ring.rst
>  F: app/test/test_pmd_ring.c
>  F: app/test/test_pmd_ring_perf.c
>
> +Tap PMD
> +M: Keith Wiles 
> +F: drivers/net/tap
> +F: doc/guides/nics/tap.rst
> +
>  Null Networking PMD
>  M: Tetsuya Mukawa 
>  F: drivers/net/null/
> diff --git a/config/common_base b/config/common_base
> index 652a839..eb51cdb 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -590,3 +590,12 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
>  CONFIG_RTE_TEST_PMD=y
>  CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>  CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
> +
> +#
> +# Compile the TAP PMD
> +#
> +# The TAP PMD is currently only built for Linux and the
> +# option is enabled by default in common_linuxapp file,
> +# set to 'n' in the common_base file.
> +#
> +CONFIG_RTE_LIBRTE_PMD_TAP=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 2483dfa..782b503 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -44,3 +44,4 @@ CONFIG_RTE_LIBRTE_PMD_VHOST=y
>  CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
>  CONFIG_RTE_LIBRTE_POWER=y
>  CONFIG_RTE_VIRTIO_USER=y
> +CONFIG_RTE_LIBRTE_PMD_TAP=y
> diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
> index 92d56a5..af92529 100644
> --- a/doc/guides/nics/index.rst
> +++ b/doc/guides/nics/index.rst
> @@ -51,6 +51,7 @@ Network Interface Controller Drivers
>  nfp
>  qede
>  szedata2
> +tap
>  thunderx
>  virtio
>  vhost
> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
> new file mode 100644
> index 000..622b9e7
> --- /dev/null
> +++ b/doc/guides/nics/tap.rst
> @@ -0,0 +1,136 @@
> +..  BSD LICENSE
> +Copyright(c) 2016 Intel Corporation. All rights reserved.
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +
> +* Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +* Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +* Neither the name of Intel Corporation nor the names of its
> +contributors may be used to endorse or promote products derived
> +from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +A PARTICULAR PURPOSE ARE DISCLAIMED. IN 

[dpdk-dev] [PATCH] SDK: Add scripts to initialize DPDK runtime

[Luca Boccassi]

From: Christian Ehrhardt 

A tools/init directory is added with dpdk-init, a script that can be
used to initialize a DPDK runtime environment. 2 config files with
default options, dpdk.conf and interfaces, are provided as well
together with a SysV init script and a systemd service unit.

Signed-off-by: Luca Boccassi 
Signed-off-by: Christian Ehrhardt 
---
 mk/rte.sdkinstall.mk   |  21 
 tools/init/dpdk-init.in| 256 +
 tools/init/dpdk.conf   |  60 +++
 tools/init/dpdk.init.in|  57 ++
 tools/init/dpdk.service.in |  12 +++
 tools/init/interfaces  |  16 +++
 6 files changed, 422 insertions(+)
 create mode 100755 tools/init/dpdk-init.in
 create mode 100644 tools/init/dpdk.conf
 create mode 100755 tools/init/dpdk.init.in
 create mode 100644 tools/init/dpdk.service.in
 create mode 100644 tools/init/interfaces

diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 7b0d8b5..a3a5a9a 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -69,6 +69,14 @@ datadir ?=   $(datarootdir)/dpdk
 mandir  ?=   $(datarootdir)/man
 sdkdir  ?=$(datadir)
 targetdir   ?=$(datadir)/$(RTE_TARGET)
+# If pkgconfig or systemd.pc are not available fall back to most likely default
+ifeq ($(shell pkg-config systemd; echo $$?), 0)
+systemduserunitdir ?= $(shell pkg-config --variable=systemdsystemunitdir 
systemd)
+else
+systemduserunitdir ?= /lib/systemd/system
+endif
+initdir ?= /etc/init.d
+configdir   ?= /etc/dpdk
 
 # The install directories may be staged in DESTDIR
 
@@ -162,6 +170,19 @@ install-sdk:
$(Q)cp -a   $O/app/dpdk-pmdinfogen   
$(DESTDIR)$(targetdir)/app
$(Q)$(call rte_symlink, $(DESTDIR)$(includedir), 
$(DESTDIR)$(targetdir)/include)
$(Q)$(call rte_symlink, $(DESTDIR)$(libdir), 
$(DESTDIR)$(targetdir)/lib)
+   $(Q)$(call rte_mkdir,$(DESTDIR)$(initdir))
+   $(Q)sed -e "s|@@configdir@@|$(configdir)|g" -e 
"s|@@sbindir@@|$(sbindir)|g" \
+   $(RTE_SDK)/tools/init/dpdk.init.in > $(DESTDIR)$(initdir)/dpdk
+   $(Q)chmod +x 
$(DESTDIR)$(initdir)/dpdk
+   $(Q)$(call rte_mkdir,
$(DESTDIR)$(systemduserunitdir))
+   $(Q)sed "s|@@sbindir@@|$(sbindir)|g" 
$(RTE_SDK)/tools/init/dpdk.service.in > \
+   $(DESTDIR)$(systemduserunitdir)/dpdk.service
+   $(Q)$(call rte_mkdir,$(DESTDIR)$(configdir))
+   $(Q)cp -a   $(RTE_SDK)/tools/init/dpdk.conf  
$(DESTDIR)$(configdir)
+   $(Q)cp -a   $(RTE_SDK)/tools/init/interfaces 
$(DESTDIR)$(configdir)
+   $(Q)sed -e "s|@@configdir@@|$(configdir)|g" -e 
"s|@@sbindir@@|$(sbindir)|g" \
+   $(RTE_SDK)/tools/init/dpdk-init.in > 
$(DESTDIR)$(sbindir)/dpdk-init
+   $(Q)chmod +x 
$(DESTDIR)$(sbindir)/dpdk-init
 
 install-doc:
 ifneq ($(wildcard $O/doc/html),)
diff --git a/tools/init/dpdk-init.in b/tools/init/dpdk-init.in
new file mode 100755
index 000..89e0399
--- /dev/null
+++ b/tools/init/dpdk-init.in
@@ -0,0 +1,256 @@
+#!/bin/sh
+#
+# dpdk-init: startup script to initialize a dpdk runtime environment
+#
+# Copyright 2015-2016 Canonical Ltd.
+# Autor: Stefan Bader 
+# Autor: Christian Ehrhardt 
+#
+#This program is free software: you can redistribute it and/or modify
+#it under the terms of the GNU General Public License version 3,
+#as published by the Free Software Foundation.
+#
+#This program is distributed in the hope that it will be useful,
+#but WITHOUT ANY WARRANTY; without even the implied warranty of
+#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#GNU General Public License for more details.
+#
+#You should have received a copy of the GNU General Public License
+#along with this program.  If not, see .
+#
+set -e
+
+DPDK_BIND="@@sbindir@@/dpdk-devbind"
+DPDK_INTERF="@@configdir@@/interfaces"
+DPDK_CONF="@@configdir@@/dpdk.conf"
+
+
+# pagesize supports [G|g]/[M|m]/[K|k]
+get_kbytes() {
+local unit
+local num
+unit=$(echo "${1}" | sed 's/[0-9]*//g')
+num=$(echo "${1}" | sed 's/[^0-9]*//g')
+case ${unit} in
+*g | *G)
+echo $((num*1024*1024))
+;;
+*m | *M)
+echo $((num*1024))
+;;
+*k | *K)
+echo $((num))
+;;
+*)
+echo $((num/1024))
+;;
+esac
+}
+
+get_default_hpgsz() {
+default_hpgsz=$(grep "Hugepagesize:" /proc/meminfo \
+| sed 's/^Hugepagesize:\s*//g' | sed 's/\s*kB$//g')
+echo "${default_hpgsz}"
+}
+
+get_hugetlbfs_mountpoint() {
+local requested_hpgsz
+local mp_hpgsz
+requested_hpgsz=$(get_kbytes "${1}")
+
+grep hugetlbfs /proc/mounts | while read \
+mntfrom mntpoint mntfstype mntopt mntdump mntfsck; do
+
+# check if th

Re: [dpdk-dev] [PATCH] net/qede: fix resource leak

[Harish Patil]

>On 11/30/2016 12:32 PM, Yong Wang wrote:
>> Current code does not close 'fd' on function exit, leaking resources.
>> 
>> Signed-off-by: Yong Wang 
>> ---
>
>Add new mail address of the maintainer.
>
>CC: Harish Patil 
>
><...>
>

Acked-by: Harish Patil 

Re: [dpdk-dev] [PATCH 7/7] net/qede: restrict maximum queues for PF/VF

[Harish Patil]

>On 12/3/2016 2:43 AM, Harish Patil wrote:
>> Fix to adverstise max_rx_queues by taking into account the number
>
>s/adverstise/advertise

Will correct that, thanks.

>
>> of PF connections instead of returning max_queues supported by the
>> HW.
>
>Can you please describe what is the effect, what happens if this is not
>fixed, and driver keeps reporting max_queues supported by the HW?

We have tested up to 32 Rx/Tx queues across different qede devices, so I
would like to advertise only those many.
Hope that is okay.

>
>> 
>> Fixes: 2ea6f76a ("qede: add core driver")
>> 
>> Signed-off-by: Harish Patil 
>> ---
><...>
>

Re: [dpdk-dev] [PATCH 7/7] net/qede: restrict maximum queues for PF/VF

[Ferruh Yigit]

On 12/12/2016 7:29 PM, Harish Patil wrote:
> 
>> On 12/3/2016 2:43 AM, Harish Patil wrote:
>>> Fix to adverstise max_rx_queues by taking into account the number
>>
>> s/adverstise/advertise
> 
> Will correct that, thanks.
> 
>>
>>> of PF connections instead of returning max_queues supported by the
>>> HW.
>>
>> Can you please describe what is the effect, what happens if this is not
>> fixed, and driver keeps reporting max_queues supported by the HW?
> 
> We have tested up to 32 Rx/Tx queues across different qede devices, so I
> would like to advertise only those many.
> Hope that is okay.

That is OK, can you please add this information to the commit log,
otherwise it is not possible to know the reasoning of the change just
with code.

Thanks.

> 
>>
>>>
>>> Fixes: 2ea6f76a ("qede: add core driver")
>>>
>>> Signed-off-by: Harish Patil 
>>> ---
>> <...>
>>
> 
> 

Re: [dpdk-dev] [PATCH v12] net/tap: new TUN/TAP device PMD

[Wiles, Keith]

> On Dec 12, 2016, at 1:13 PM, Marc  wrote:
> 
> Keith,
> 
> A bit late, but two very high level questions. Do you have performance 
> numbers compared to KNI? Did you consider using AF_PACKET PACKET_MMAP which 
> could potentially reduce the number of syscalls to 1 for RX and TX of a burst?

Hi Marc,

I was not trying to create a high performance interface, just a Tap interface 
to use standard applications and calls to send/receive traffic to the DPDK 
application. I did not expect other then some management like interface in the 
application would use the Tap PMD.

> 
> Marc
> 
> On 12 December 2016 at 15:38, Keith Wiles  wrote:
> The PMD allows for DPDK and the host to communicate using a raw
> device interface on the host and in the DPDK application. The device
> created is a Tap device with a L2 packet header.
> 
> v12- Fixup minor changes for driver_name and version number
> v11- Add the tap.rst to the nic/index.rst file
> v10- Change the string name used to allow for multiple devices.
> v9 - Fix up the docs to use correct syntax
> v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
> v7 - Reword the comment in common_base and fix the data->name issue
> v6 - fixed the checkpatch issues
> v5 - merge in changes from list review see related emails
>  fixed many minor edits
> v4 - merge with latest driver changes
> v3 - fix includes by removing ifdef for other type besides Linux
>  Fix the copyright notice in the Makefile
> v2 - merge all of the patches into one patch
>  Fix a typo on naming the tap device
>  Update the maintainers list
> 
> Signed-off-by: Keith Wiles 
> ---
>  MAINTAINERS |   5 +
>  config/common_base  |   9 +
>  config/common_linuxapp  |   1 +
>  doc/guides/nics/index.rst   |   1 +
>  doc/guides/nics/tap.rst | 136 ++
>  drivers/net/Makefile|   1 +
>  drivers/net/tap/Makefile|  57 +++
>  drivers/net/tap/rte_eth_tap.c   | 765 
> 
>  drivers/net/tap/rte_pmd_tap_version.map |   4 +
>  mk/rte.app.mk   |   1 +
>  10 files changed, 980 insertions(+)
>  create mode 100644 doc/guides/nics/tap.rst
>  create mode 100644 drivers/net/tap/Makefile
>  create mode 100644 drivers/net/tap/rte_eth_tap.c
>  create mode 100644 drivers/net/tap/rte_pmd_tap_version.map
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 26d9590..842fb6d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -398,6 +398,11 @@ F: doc/guides/nics/pcap_ring.rst
>  F: app/test/test_pmd_ring.c
>  F: app/test/test_pmd_ring_perf.c
> 
> +Tap PMD
> +M: Keith Wiles 
> +F: drivers/net/tap
> +F: doc/guides/nics/tap.rst
> +
>  Null Networking PMD
>  M: Tetsuya Mukawa 
>  F: drivers/net/null/
> diff --git a/config/common_base b/config/common_base
> index 652a839..eb51cdb 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -590,3 +590,12 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
>  CONFIG_RTE_TEST_PMD=y
>  CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>  CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
> +
> +#
> +# Compile the TAP PMD
> +#
> +# The TAP PMD is currently only built for Linux and the
> +# option is enabled by default in common_linuxapp file,
> +# set to 'n' in the common_base file.
> +#
> +CONFIG_RTE_LIBRTE_PMD_TAP=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 2483dfa..782b503 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -44,3 +44,4 @@ CONFIG_RTE_LIBRTE_PMD_VHOST=y
>  CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
>  CONFIG_RTE_LIBRTE_POWER=y
>  CONFIG_RTE_VIRTIO_USER=y
> +CONFIG_RTE_LIBRTE_PMD_TAP=y
> diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
> index 92d56a5..af92529 100644
> --- a/doc/guides/nics/index.rst
> +++ b/doc/guides/nics/index.rst
> @@ -51,6 +51,7 @@ Network Interface Controller Drivers
>  nfp
>  qede
>  szedata2
> +tap
>  thunderx
>  virtio
>  vhost
> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
> new file mode 100644
> index 000..622b9e7
> --- /dev/null
> +++ b/doc/guides/nics/tap.rst
> @@ -0,0 +1,136 @@
> +..  BSD LICENSE
> +Copyright(c) 2016 Intel Corporation. All rights reserved.
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +
> +* Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +* Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +* Neither the name of Intel Corporation nor the names of its
> +contributors may be used to endorse or promote products

Re: [dpdk-dev] [PATCH] SDK: Add scripts to initialize DPDK runtime

[Bruce Richardson]

On Mon, Dec 12, 2016 at 07:24:02PM +, Luca Boccassi wrote:
> From: Christian Ehrhardt 
> 
> A tools/init directory is added with dpdk-init, a script that can be
> used to initialize a DPDK runtime environment. 2 config files with
> default options, dpdk.conf and interfaces, are provided as well
> together with a SysV init script and a systemd service unit.
> 
> Signed-off-by: Luca Boccassi 
> Signed-off-by: Christian Ehrhardt 
> ---

> new file mode 100755
> index 000..89e0399
> --- /dev/null
> +++ b/tools/init/dpdk-init.in
> @@ -0,0 +1,256 @@
> +#!/bin/sh
> +#
> +# dpdk-init: startup script to initialize a dpdk runtime environment
> +#
> +# Copyright 2015-2016 Canonical Ltd.
> +# Autor: Stefan Bader 
> +# Autor: Christian Ehrhardt 
> +#
> +#This program is free software: you can redistribute it and/or modify
> +#it under the terms of the GNU General Public License version 3,
> +#as published by the Free Software Foundation.
> +#
> +#This program is distributed in the hope that it will be useful,
> +#but WITHOUT ANY WARRANTY; without even the implied warranty of
> +#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +#GNU General Public License for more details.
> +#
> +#You should have received a copy of the GNU General Public License
> +#along with this program.  If not, see .
> +#

Any particular reason this is licensed under GPL v3. AFAIK, all the
userspace code in DPDK is licensed under a BSD license (with the
exception of some dual licensed stuff which is shared between kernel and
userspace). I just worry that adding additional licenses into the mix
may confuse things.

Regards,
/Bruce

Re: [dpdk-dev] [PATCH v4] net/kni: add KNI PMD

[Yong Wang]

> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Wednesday, November 30, 2016 10:12 AM
> To: dev@dpdk.org
> Cc: Ferruh Yigit ; Yong Wang
> 
> Subject: [PATCH v4] net/kni: add KNI PMD
> 
> Add KNI PMD which wraps librte_kni for ease of use.
> 
> KNI PMD can be used as any regular PMD to send / receive packets to the
> Linux networking stack.
> 
> Signed-off-by: Ferruh Yigit 
> ---
> 
> v4:
> * allow only single queue
> * use driver.name as name
> 
> v3:
> * rebase on top of latest master
> 
> v2:
> * updated driver name eth_kni -> net_kni
> ---
>  config/common_base  |   1 +
>  config/common_linuxapp  |   1 +
>  drivers/net/Makefile|   1 +
>  drivers/net/kni/Makefile|  63 +
>  drivers/net/kni/rte_eth_kni.c   | 462
> 
>  drivers/net/kni/rte_pmd_kni_version.map |   4 +
>  mk/rte.app.mk   |  10 +-
>  7 files changed, 537 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/net/kni/Makefile
>  create mode 100644 drivers/net/kni/rte_eth_kni.c
>  create mode 100644 drivers/net/kni/rte_pmd_kni_version.map
> 
> diff --git a/config/common_base b/config/common_base
> index 4bff83a..3385879 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -543,6 +543,7 @@ CONFIG_RTE_PIPELINE_STATS_COLLECT=n
>  # Compile librte_kni
>  #
>  CONFIG_RTE_LIBRTE_KNI=n
> +CONFIG_RTE_LIBRTE_PMD_KNI=n
>  CONFIG_RTE_KNI_KMOD=n
>  CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
>  CONFIG_RTE_KNI_VHOST=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 2483dfa..2ecd510 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -39,6 +39,7 @@ CONFIG_RTE_EAL_IGB_UIO=y
>  CONFIG_RTE_EAL_VFIO=y
>  CONFIG_RTE_KNI_KMOD=y
>  CONFIG_RTE_LIBRTE_KNI=y
> +CONFIG_RTE_LIBRTE_PMD_KNI=y
>  CONFIG_RTE_LIBRTE_VHOST=y
>  CONFIG_RTE_LIBRTE_PMD_VHOST=y
>  CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index bc93230..c4771cd 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -41,6 +41,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic
>  DIRS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += fm10k
>  DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e
>  DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe
> +DIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += kni
>  DIRS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4
>  DIRS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5
>  DIRS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += mpipe
> diff --git a/drivers/net/kni/Makefile b/drivers/net/kni/Makefile
> new file mode 100644
> index 000..0b7cf91
> --- /dev/null
> +++ b/drivers/net/kni/Makefile
> @@ -0,0 +1,63 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2016 Intel Corporation. All rights reserved.
> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +#   notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +#   notice, this list of conditions and the following disclaimer in
> +#   the documentation and/or other materials provided with the
> +#   distribution.
> +# * Neither the name of Intel Corporation nor the names of its
> +#   contributors may be used to endorse or promote products derived
> +#   from this software without specific prior written permission.
> +#
> +#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> +#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> +#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> +#   A PARTICULAR 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_kni.a
> +
> +CFLAGS += -O3
> +CFLAGS += $(WERROR_FLAGS)
> +LDLIBS += -lpthread
> +
> +EXPORT_MAP := rte_pmd_kni_version.map
> +
> +LIBABIVER := 1
> +
> +#
> +# all source are stored in SRCS-y
> +#
> +SRCS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += rte_eth_kni.c
> +
> +#
> +# Export include files
> +#
> +SYMLINK-y-include +=
> +
> +# this lib depends upon:
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_eal
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_ether

Re: [dpdk-dev] [PATCH] SDK: Add scripts to initialize DPDK runtime

[Luca Boccassi]

On Mon, 2016-12-12 at 21:12 +, Bruce Richardson wrote:
> On Mon, Dec 12, 2016 at 07:24:02PM +, Luca Boccassi wrote:
> > From: Christian Ehrhardt 
> > 
> > A tools/init directory is added with dpdk-init, a script that can be
> > used to initialize a DPDK runtime environment. 2 config files with
> > default options, dpdk.conf and interfaces, are provided as well
> > together with a SysV init script and a systemd service unit.
> > 
> > Signed-off-by: Luca Boccassi 
> > Signed-off-by: Christian Ehrhardt 
> > ---
> 
> > new file mode 100755
> > index 000..89e0399
> > --- /dev/null
> > +++ b/tools/init/dpdk-init.in
> > @@ -0,0 +1,256 @@
> > +#!/bin/sh
> > +#
> > +# dpdk-init: startup script to initialize a dpdk runtime environment
> > +#
> > +# Copyright 2015-2016 Canonical Ltd.
> > +# Autor: Stefan Bader 
> > +# Autor: Christian Ehrhardt 
> > +#
> > +#This program is free software: you can redistribute it and/or modify
> > +#it under the terms of the GNU General Public License version 3,
> > +#as published by the Free Software Foundation.
> > +#
> > +#This program is distributed in the hope that it will be useful,
> > +#but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +#GNU General Public License for more details.
> > +#
> > +#You should have received a copy of the GNU General Public License
> > +#along with this program.  If not, see 
> >  >  >.
> > +#
> 
> Any particular reason this is licensed under GPL v3. AFAIK, all the
> userspace code in DPDK is licensed under a BSD license (with the
> exception of some dual licensed stuff which is shared between kernel and
> userspace). I just worry that adding additional licenses into the mix
> may confuse things.
> 
> Regards,
> /Bruce

If the 2 authors (CC'ed Stefan, the second one) agree and give
permission it could be relicensed to BSD.

Stefan, Christian, is that OK for you?

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH] SDK: Add scripts to initialize DPDK runtime

[Jay Rolette]

On Mon, Dec 12, 2016 at 3:12 PM, Bruce Richardson <
bruce.richard...@intel.com> wrote:

> On Mon, Dec 12, 2016 at 07:24:02PM +, Luca Boccassi wrote:
> > From: Christian Ehrhardt 
> >
> > A tools/init directory is added with dpdk-init, a script that can be
> > used to initialize a DPDK runtime environment. 2 config files with
> > default options, dpdk.conf and interfaces, are provided as well
> > together with a SysV init script and a systemd service unit.
> >
> > Signed-off-by: Luca Boccassi 
> > Signed-off-by: Christian Ehrhardt 
> > ---
> 
> > new file mode 100755
> > index 000..89e0399
> > --- /dev/null
> > +++ b/tools/init/dpdk-init.in
> > @@ -0,0 +1,256 @@
> > +#!/bin/sh
> > +#
> > +# dpdk-init: startup script to initialize a dpdk runtime environment
> > +#
> > +# Copyright 2015-2016 Canonical Ltd.
> > +# Autor: Stefan Bader 
> > +# Autor: Christian Ehrhardt 
> > +#
> > +#This program is free software: you can redistribute it and/or
> modify
> > +#it under the terms of the GNU General Public License version 3,
> > +#as published by the Free Software Foundation.
> > +#
> > +#This program is distributed in the hope that it will be useful,
> > +#but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +#GNU General Public License for more details.
> > +#
> > +#You should have received a copy of the GNU General Public License
> > +#along with this program.  If not, see <
> http://www.gnu.org/licenses/>.
> > +#
>
> Any particular reason this is licensed under GPL v3. AFAIK, all the
> userspace code in DPDK is licensed under a BSD license (with the
> exception of some dual licensed stuff which is shared between kernel and
> userspace). I just worry that adding additional licenses into the mix
> may confuse things.
>
> Regards,
> /Bruce
>

Most generally, shouldn't any patch that isn't compatible with the standard
DPDK license be rejected? With the specific exception for the KNI kernel
bits that require different licenses...

Jay

[dpdk-dev] [PATCH 01/13] EAL: count nr_overcommit_hugepages as available

[Michał Mirosław]

Signed-off-by: Michał Mirosław 

---
 lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 ++---
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c 
b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
index 18858e2..f391e07 100644
--- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
+++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
@@ -61,30 +61,38 @@
 
 static const char sys_dir_path[] = "/sys/kernel/mm/hugepages";
 
+static int get_hp_sysfs_value(const char *subdir, const char *file, long 
unsigned *val)
+{
+   char path[PATH_MAX];
+
+   snprintf(path, sizeof(path), "%s/%s/%s",
+   sys_dir_path, subdir, file);
+   return eal_parse_sysfs_value(path, val);
+}
+
 /* this function is only called from eal_hugepage_info_init which itself
  * is only called from a primary process */
 static uint32_t
 get_num_hugepages(const char *subdir)
 {
-   char path[PATH_MAX];
-   long unsigned resv_pages, num_pages = 0;
+   long unsigned resv_pages, num_pages, over_pages, surplus_pages;
const char *nr_hp_file = "free_hugepages";
const char *nr_rsvd_file = "resv_hugepages";
+   const char *nr_over_file = "nr_overcommit_hugepages";
+   const char *nr_splus_file = "surplus_hugepages";
 
/* first, check how many reserved pages kernel reports */
-   snprintf(path, sizeof(path), "%s/%s/%s",
-   sys_dir_path, subdir, nr_rsvd_file);
-   if (eal_parse_sysfs_value(path, &resv_pages) < 0)
+   if (get_hp_sysfs_value(subdir, nr_rsvd_file, &resv_pages) < 0)
return 0;
 
-   snprintf(path, sizeof(path), "%s/%s/%s",
-   sys_dir_path, subdir, nr_hp_file);
-   if (eal_parse_sysfs_value(path, &num_pages) < 0)
+   if (get_hp_sysfs_value(subdir, nr_hp_file, &num_pages) < 0)
return 0;
 
-   if (num_pages == 0)
-   RTE_LOG(WARNING, EAL, "No free hugepages reported in %s\n",
-   subdir);
+   if (get_hp_sysfs_value(subdir, nr_over_file, &over_pages) < 0)
+   over_pages = 0;
+
+   if (get_hp_sysfs_value(subdir, nr_splus_file, &surplus_pages) < 0)
+   surplus_pages = 0;
 
/* adjust num_pages */
if (num_pages >= resv_pages)
@@ -92,6 +100,19 @@ get_num_hugepages(const char *subdir)
else if (resv_pages)
num_pages = 0;
 
+   if (over_pages >= surplus_pages)
+   over_pages -= surplus_pages;
+   else
+   over_pages = 0;
+
+   if (num_pages == 0 && over_pages == 0)
+   RTE_LOG(WARNING, EAL, "No available hugepages reported in %s\n",
+   subdir);
+
+   num_pages += over_pages;
+   if (num_pages < over_pages) /* overflow */
+   num_pages = UINT32_MAX;
+
/* we want to return a uint32_t and more than this looks suspicious
 * anyway ... */
if (num_pages > UINT32_MAX)
-- 
2.10.2

[dpdk-dev] [PATCH 00/13] Fixes and tweaks

[Michał Mirosław]

This is a loose set of small fixes accumulated here at Atende Software
to be upstreamed. Please consider and apply each one separately.

Best Regards,
Michal Mirosław

---
Michał Mirosław (11):
  EAL: count nr_overcommit_hugepages as available
  mbuf: rte_pktmbuf_free_bulk()
  rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()
  acl: allow zero verdict
  acl: fix acl_flow_data comments
  PMD/af_packet: guard against buffer overruns in RX path
  PMD/af_packet: guard against buffer overruns in TX path
  KNI: provided netif name's source is user-space
  KNI: guard against unterminated dev_info.name leading to BUG in
alloc_netdev()
  i40e: return -errno when intr setup fails
  i40e: improve message grepability

Paweł Małachowski (1):
  null: fake PMD capabilities

Piotr Bartosiewicz (1):
  pcap: fix timestamps in output pcap file

 drivers/net/af_packet/rte_eth_af_packet.c   |  29 ++--
 drivers/net/i40e/i40e_ethdev.c  | 203 +---
 drivers/net/null/rte_eth_null.c |  13 +-
 drivers/net/pcap/rte_eth_pcap.c |   2 +-
 lib/librte_acl/acl_run.h|   4 +-
 lib/librte_acl/rte_acl.c|   3 +-
 lib/librte_acl/rte_acl.h|   2 -
 lib/librte_eal/linuxapp/eal/eal_hugepage_info.c |  43 +++--
 lib/librte_eal/linuxapp/eal/eal_interrupts.c|   2 +-
 lib/librte_eal/linuxapp/kni/kni_misc.c  |  10 +-
 lib/librte_mbuf/rte_mbuf.h  |  15 ++
 lib/librte_net/rte_ether.h  |   2 +-
 lib/librte_table/rte_table_acl.c|   2 +-
 13 files changed, 169 insertions(+), 161 deletions(-)

-- 
2.10.2

[dpdk-dev] [PATCH 02/13] mbuf: rte_pktmbuf_free_bulk()

[Michał Mirosław]

Signed-off-by: Michał Mirosław 

---
 lib/librte_mbuf/rte_mbuf.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index ead7c6e..a95d99f 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1248,6 +1248,21 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
 }
 
 /**
+ * Free multiple packet mbufs back into their original mempool(s).
+ *
+ * @param mp
+ *   Pointer to array of packet mbufs to be freed.
+ * @param n
+ *   Count of packet mbufs to free.
+ */
+static inline void rte_pktmbuf_free_bulk(struct rte_mbuf **mp, uint32_t n)
+{
+   uint32_t i;
+   for (i = 0; i < n; ++i)
+   rte_pktmbuf_free(mp[i]);
+}
+
+/**
  * Creates a "clone" of the given packet mbuf.
  *
  * Walks through all segments of the given packet mbuf, and for each of them:
-- 
2.10.2

[dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()

[Michał Mirosław]

Signed-off-by: Michał Mirosław 

---
 lib/librte_net/rte_ether.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index ff3d065..26a8843 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
return -1;
 
struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
-   m->ol_flags |= PKT_RX_VLAN_PKT;
+   m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
 
/* Copy ether header over rather than moving whole packet */
-- 
2.10.2

[dpdk-dev] [PATCH 04/13] acl: allow zero verdict

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 lib/librte_acl/rte_acl.c | 3 +--
 lib/librte_acl/rte_acl.h | 2 --
 lib/librte_table/rte_table_acl.c | 2 +-
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
index 8b7e92c..d1f40be 100644
--- a/lib/librte_acl/rte_acl.c
+++ b/lib/librte_acl/rte_acl.c
@@ -313,8 +313,7 @@ acl_check_rule(const struct rte_acl_rule_data *rd)
if ((RTE_LEN2MASK(RTE_ACL_MAX_CATEGORIES, typeof(rd->category_mask)) &
rd->category_mask) == 0 ||
rd->priority > RTE_ACL_MAX_PRIORITY ||
-   rd->priority < RTE_ACL_MIN_PRIORITY ||
-   rd->userdata == RTE_ACL_INVALID_USERDATA)
+   rd->priority < RTE_ACL_MIN_PRIORITY)
return -EINVAL;
return 0;
 }
diff --git a/lib/librte_acl/rte_acl.h b/lib/librte_acl/rte_acl.h
index caa91f7..b53179a 100644
--- a/lib/librte_acl/rte_acl.h
+++ b/lib/librte_acl/rte_acl.h
@@ -120,8 +120,6 @@ enum {
RTE_ACL_MIN_PRIORITY = 0,
 };
 
-#defineRTE_ACL_INVALID_USERDATA0
-
 #defineRTE_ACL_MASKLEN_TO_BITMASK(v, s)\
 ((v) == 0 ? (v) : (typeof(v))((uint64_t)-1 << ((s) * CHAR_BIT - (v
 
diff --git a/lib/librte_table/rte_table_acl.c b/lib/librte_table/rte_table_acl.c
index 8f1f8ce..94b69a9 100644
--- a/lib/librte_table/rte_table_acl.c
+++ b/lib/librte_table/rte_table_acl.c
@@ -792,7 +792,7 @@ rte_table_acl_lookup(
 
pkts_mask &= ~pkt_mask;
 
-   if (action_table_pos != RTE_ACL_INVALID_USERDATA) {
+   if (action_table_pos != 0) {
pkts_out_mask |= pkt_mask;
entries[pkt_pos] = (void *)
&acl->memory[action_table_pos *
-- 
2.10.2

[dpdk-dev] [PATCH 05/13] acl: fix acl_flow_data comments

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 lib/librte_acl/acl_run.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_acl/acl_run.h b/lib/librte_acl/acl_run.h
index 024f393..a862ff6 100644
--- a/lib/librte_acl/acl_run.h
+++ b/lib/librte_acl/acl_run.h
@@ -69,10 +69,10 @@ struct acl_flow_data {
uint32_ttrie;
/* current trie index (0 to N-1) */
uint32_tcmplt_size;
+   /* maximum number of packets to process */
uint32_ttotal_packets;
-   uint32_tcategories;
/* number of result categories per packet. */
-   /* maximum number of packets to process */
+   uint32_tcategories;
const uint64_t *trans;
const uint8_t **data;
uint32_t   *results;
-- 
2.10.2

[dpdk-dev] [PATCH 07/13] pcap: fix timestamps in output pcap file

[Michał Mirosław]

From: Piotr Bartosiewicz 

Signed-off-by: Michał Mirosław 
---
 drivers/net/pcap/rte_eth_pcap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 0162f44..57b0b31 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -247,7 +247,7 @@ calculate_timestamp(struct timeval *ts) {
 
cycles = rte_get_timer_cycles() - start_cycles;
cur_time.tv_sec = cycles / hz;
-   cur_time.tv_usec = (cycles % hz) * 10e6 / hz;
+   cur_time.tv_usec = (cycles % hz) * 1e6 / hz;
timeradd(&start_time, &cur_time, ts);
 }
 
-- 
2.10.2

[dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

[Michał Mirosław]

From: Paweł Małachowski 

Thanks to that change we can use Null PMD for testing purposes.

Signed-off-by: Michał Mirosław 
---
 drivers/net/null/rte_eth_null.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..f32ba2a 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
tx_queue_id,
return 0;
 }
 
+static void
+eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
+
 
 static void
 eth_dev_info(struct rte_eth_dev *dev,
@@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
dev_info->pci_dev = NULL;
dev_info->reta_size = internals->reta_size;
dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
+   /* We hereby declare we can RX-offload VLAN-s out of thin air and 
update checksums and VLANs before sinking packets in /dev/null */
+   dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+   dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | 
DEV_TX_OFFLOAD_IPV4_CKSUM;
 }
 
 static void
@@ -477,7 +483,12 @@ static const struct eth_dev_ops ops = {
.reta_update = eth_rss_reta_update,
.reta_query = eth_rss_reta_query,
.rss_hash_update = eth_rss_hash_update,
-   .rss_hash_conf_get = eth_rss_hash_conf_get
+   .rss_hash_conf_get = eth_rss_hash_conf_get,
+   /* Fake our capabilities */
+   .promiscuous_enable   = eth_dev_void_ok,
+   .promiscuous_disable  = eth_dev_void_ok,
+   .allmulticast_enable  = eth_dev_void_ok,
+   .allmulticast_disable = eth_dev_void_ok
 };
 
 int
-- 
2.10.2

[dpdk-dev] [PATCH 08/13] PMD/af_packet: guard against buffer overruns in RX path

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 drivers/net/af_packet/rte_eth_af_packet.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index ff45068..b1005c6 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -370,18 +370,18 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
 {
struct pmd_internals *internals = dev->data->dev_private;
struct pkt_rx_queue *pkt_q = &internals->rx_queue[rx_queue_id];
-   uint16_t buf_size;
+   unsigned buf_size, data_size;
 
pkt_q->mb_pool = mb_pool;
 
/* Now get the space available for data in the mbuf */
-   buf_size = (uint16_t)(rte_pktmbuf_data_room_size(pkt_q->mb_pool) -
-   RTE_PKTMBUF_HEADROOM);
+   buf_size = rte_pktmbuf_data_room_size(pkt_q->mb_pool) - 
RTE_PKTMBUF_HEADROOM;
+   data_size = internals->req.tp_frame_size - TPACKET2_HDRLEN + 
sizeof(struct sockaddr_ll);
 
-   if (ETH_FRAME_LEN > buf_size) {
+   if (data_size > buf_size) {
RTE_LOG(ERR, PMD,
"%s: %d bytes will not fit in mbuf (%d bytes)\n",
-   dev->data->name, ETH_FRAME_LEN, buf_size);
+   dev->data->name, data_size, buf_size);
return -ENOMEM;
}
 
-- 
2.10.2

[dpdk-dev] [PATCH 09/13] PMD/af_packet: guard against buffer overruns in TX path

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 drivers/net/af_packet/rte_eth_af_packet.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index b1005c6..2c81d25 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -83,6 +83,7 @@ struct pkt_rx_queue {
 
 struct pkt_tx_queue {
int sockfd;
+   unsigned frame_data_size;
 
struct iovec *rd;
uint8_t *map;
@@ -206,13 +207,20 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
framenum = pkt_q->framenum;
ppd = (struct tpacket2_hdr *) pkt_q->rd[framenum].iov_base;
for (i = 0; i < nb_pkts; i++) {
+   mbuf = *bufs++;
+
+   /* drop oversized packets */
+   if (rte_pktmbuf_data_len(mbuf) > pkt_q->frame_data_size) {
+   rte_pktmbuf_free(mbuf);
+   continue;
+   }
+
/* point at the next incoming frame */
if ((ppd->tp_status != TP_STATUS_AVAILABLE) &&
(poll(&pfd, 1, -1) < 0))
-   continue;
+   break;
 
/* copy the tx frame data */
-   mbuf = bufs[num_tx];
pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN -
sizeof(struct sockaddr_ll);
memcpy(pbuf, rte_pktmbuf_mtod(mbuf, void*), 
rte_pktmbuf_data_len(mbuf));
@@ -231,13 +239,13 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
 
/* kick-off transmits */
if (sendto(pkt_q->sockfd, NULL, 0, MSG_DONTWAIT, NULL, 0) == -1)
-   return 0; /* error sending -- no packets transmitted */
+   num_tx = 0; /* error sending -- no packets transmitted */
 
pkt_q->framenum = framenum;
pkt_q->tx_pkts += num_tx;
-   pkt_q->err_pkts += nb_pkts - num_tx;
+   pkt_q->err_pkts += i - num_tx;
pkt_q->tx_bytes += num_tx_bytes;
-   return num_tx;
+   return i;
 }
 
 static int
@@ -633,6 +641,7 @@ rte_pmd_init_internals(const char *name,
 
tx_queue = &((*internals)->tx_queue[q]);
tx_queue->framecount = req->tp_frame_nr;
+   tx_queue->frame_data_size = req->tp_frame_size - 
TPACKET2_HDRLEN + sizeof(struct sockaddr_ll);
 
tx_queue->map = rx_queue->map + req->tp_block_size * 
req->tp_block_nr;
 
-- 
2.10.2

[dpdk-dev] [PATCH 11/13] KNI: guard against unterminated dev_info.name leading to BUG in alloc_netdev()

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 lib/librte_eal/linuxapp/kni/kni_misc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index f0247aa..14a2e3b 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -344,6 +344,12 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
return -EIO;
}
 
+   /* Check if name is zero-ended */
+   if (strnlen(dev_info.name, sizeof(dev_info.name)) == 
sizeof(dev_info.name)) {
+   pr_err("kni.name not zero-terminated");
+   return -EINVAL;
+   }
+
/**
 * Check if the cpu core id is valid for binding.
 */
-- 
2.10.2

[dpdk-dev] [PATCH 10/13] KNI: provided netif name's source is user-space

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 lib/librte_eal/linuxapp/kni/kni_misc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 497db9b..f0247aa 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -363,8 +363,8 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
up_read(&knet->kni_list_lock);
 
net_dev = alloc_netdev(sizeof(struct kni_dev), dev_info.name,
-#ifdef NET_NAME_UNKNOWN
-   NET_NAME_UNKNOWN,
+#ifdef NET_NAME_USER
+   NET_NAME_USER,
 #endif
kni_net_init);
if (net_dev == NULL) {
-- 
2.10.2

[dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 drivers/net/i40e/i40e_ethdev.c   | 5 +++--
 lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 67778ba..39fbcfe 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1692,8 +1692,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
 !RTE_ETH_DEV_SRIOV(dev).active) &&
dev->data->dev_conf.intr_conf.rxq != 0) {
intr_vector = dev->data->nb_rx_queues;
-   if (rte_intr_efd_enable(intr_handle, intr_vector))
-   return -1;
+   ret = rte_intr_efd_enable(intr_handle, intr_vector);
+   if (ret)
+   return ret;
}
 
if (rte_intr_dp_is_en(intr_handle) && !intr_handle->intr_vec) {
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c 
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index 47a3b20..f7a8ce3 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -1157,7 +1157,7 @@ rte_intr_efd_enable(struct rte_intr_handle *intr_handle, 
uint32_t nb_efd)
RTE_LOG(ERR, EAL,
"can't setup eventfd, error %i (%s)\n",
errno, strerror(errno));
-   return -1;
+   return -errno;
}
intr_handle->efds[i] = fd;
}
-- 
2.10.2

[dpdk-dev] [PATCH 13/13] i40e: improve message grepability

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 drivers/net/i40e/i40e_ethdev.c | 198 +++--
 1 file changed, 73 insertions(+), 125 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 39fbcfe..4d73aca 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -763,8 +763,7 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
pf->main_vsi_seid, 0,
TRUE, NULL, NULL);
if (ret)
-   PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control "
- " frames from VSIs.");
+   PMD_INIT_LOG(ERR, "Failed to add filter to drop flow control 
frames from VSIs.");
 }
 
 static int
@@ -963,8 +962,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
hw->back = I40E_PF_TO_ADAPTER(pf);
hw->hw_addr = (uint8_t *)(pci_dev->mem_resource[0].addr);
if (!hw->hw_addr) {
-   PMD_INIT_LOG(ERR, "Hardware is not available, "
-"as address is NULL");
+   PMD_INIT_LOG(ERR, "Hardware is not available, as address is 
NULL");
return -ENODEV;
}
 
@@ -1100,8 +1098,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
/* Set the global registers with default ether type value */
ret = i40e_vlan_tpid_set(dev, ETH_VLAN_TYPE_OUTER, ETHER_TYPE_VLAN);
if (ret != I40E_SUCCESS) {
-   PMD_INIT_LOG(ERR, "Failed to set the default outer "
-"VLAN ether type");
+   PMD_INIT_LOG(ERR, "Failed to set the default outer VLAN ether 
type");
goto err_setup_pf_switch;
}
 
@@ -1137,8 +1134,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
/* Should be after VSI initialized */
dev->data->mac_addrs = rte_zmalloc("i40e", len, 0);
if (!dev->data->mac_addrs) {
-   PMD_INIT_LOG(ERR, "Failed to allocated memory "
-   "for storing mac address");
+   PMD_INIT_LOG(ERR, "Failed to allocated memory for storing mac 
address");
goto err_mac_alloc;
}
ether_addr_copy((struct ether_addr *)hw->mac.perm_addr,
@@ -1703,8 +1699,9 @@ i40e_dev_start(struct rte_eth_dev *dev)
dev->data->nb_rx_queues * sizeof(int),
0);
if (!intr_handle->intr_vec) {
-   PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-" intr_vec\n", dev->data->nb_rx_queues);
+   PMD_INIT_LOG(ERR,
+   "Failed to allocate %d rx_queues intr_vec\n",
+   dev->data->nb_rx_queues);
return -ENOMEM;
}
}
@@ -1777,8 +1774,8 @@ i40e_dev_start(struct rte_eth_dev *dev)
i40e_pf_enable_irq0(hw);
 
if (dev->data->dev_conf.intr_conf.lsc != 0)
-   PMD_INIT_LOG(INFO, "lsc won't enable because of"
-" no intr multiplex\n");
+   PMD_INIT_LOG(INFO,
+   "lsc won't enable because of no intr 
multiplex\n");
} else if (dev->data->dev_conf.intr_conf.lsc != 0) {
ret = i40e_aq_set_phy_int_mask(hw,
   ~(I40E_AQ_EVENT_LINK_UPDOWN |
@@ -2718,13 +2715,11 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
ret = i40e_aq_debug_read_register(hw, I40E_GL_SWT_L2TAGCTRL(reg_id),
  ®_r, NULL);
if (ret != I40E_SUCCESS) {
-   PMD_DRV_LOG(ERR, "Fail to debug read from "
-   "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
+   PMD_DRV_LOG(ERR, "Fail to debug read from 
I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
ret = -EIO;
return ret;
}
-   PMD_DRV_LOG(DEBUG, "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: "
-   "0x%08"PRIx64"", reg_id, reg_r);
+   PMD_DRV_LOG(DEBUG, "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: 
0x%08"PRIx64"", reg_id, reg_r);
 
reg_w = reg_r & (~(I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_MASK));
reg_w |= ((uint64_t)tpid << I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_SHIFT);
@@ -2738,12 +2733,10 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
   reg_w, NULL);
if (ret != I40E_SUCCESS) {
ret = -EIO;
-   PMD_DRV_LOG(ERR, "Fail to debug write to "
-   "I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
+   PMD_DRV_LOG(ERR, "Fail to debug write to 
I40E_GL_SWT_L2TAGCTRL[%d]", reg_id);
return ret;
}
-   PMD_DRV_LOG(DEBUG, "Debug write 0x%08"PRIx64" to "
-   "I40E_GL_SWT_L2TAGCTRL[%d]", reg_w, reg_id);
+

[dpdk-dev] [PATCH v2 01/13] EAL: count nr_overcommit_hugepages as available

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 ++---
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c 
b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
index 18858e2..b68f060 100644
--- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
+++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
@@ -61,30 +61,38 @@
 
 static const char sys_dir_path[] = "/sys/kernel/mm/hugepages";
 
+static int get_hp_sysfs_value(const char *subdir, const char *file, unsigned 
long *val)
+{
+   char path[PATH_MAX];
+
+   snprintf(path, sizeof(path), "%s/%s/%s",
+   sys_dir_path, subdir, file);
+   return eal_parse_sysfs_value(path, val);
+}
+
 /* this function is only called from eal_hugepage_info_init which itself
  * is only called from a primary process */
 static uint32_t
 get_num_hugepages(const char *subdir)
 {
-   char path[PATH_MAX];
-   long unsigned resv_pages, num_pages = 0;
+   unsigned long resv_pages, num_pages, over_pages, surplus_pages;
const char *nr_hp_file = "free_hugepages";
const char *nr_rsvd_file = "resv_hugepages";
+   const char *nr_over_file = "nr_overcommit_hugepages";
+   const char *nr_splus_file = "surplus_hugepages";
 
/* first, check how many reserved pages kernel reports */
-   snprintf(path, sizeof(path), "%s/%s/%s",
-   sys_dir_path, subdir, nr_rsvd_file);
-   if (eal_parse_sysfs_value(path, &resv_pages) < 0)
+   if (get_hp_sysfs_value(subdir, nr_rsvd_file, &resv_pages) < 0)
return 0;
 
-   snprintf(path, sizeof(path), "%s/%s/%s",
-   sys_dir_path, subdir, nr_hp_file);
-   if (eal_parse_sysfs_value(path, &num_pages) < 0)
+   if (get_hp_sysfs_value(subdir, nr_hp_file, &num_pages) < 0)
return 0;
 
-   if (num_pages == 0)
-   RTE_LOG(WARNING, EAL, "No free hugepages reported in %s\n",
-   subdir);
+   if (get_hp_sysfs_value(subdir, nr_over_file, &over_pages) < 0)
+   over_pages = 0;
+
+   if (get_hp_sysfs_value(subdir, nr_splus_file, &surplus_pages) < 0)
+   surplus_pages = 0;
 
/* adjust num_pages */
if (num_pages >= resv_pages)
@@ -92,6 +100,19 @@ get_num_hugepages(const char *subdir)
else if (resv_pages)
num_pages = 0;
 
+   if (over_pages >= surplus_pages)
+   over_pages -= surplus_pages;
+   else
+   over_pages = 0;
+
+   if (num_pages == 0 && over_pages == 0)
+   RTE_LOG(WARNING, EAL, "No available hugepages reported in %s\n",
+   subdir);
+
+   num_pages += over_pages;
+   if (num_pages < over_pages) /* overflow */
+   num_pages = UINT32_MAX;
+
/* we want to return a uint32_t and more than this looks suspicious
 * anyway ... */
if (num_pages > UINT32_MAX)
-- 
2.10.2

[dpdk-dev] [PATCH v2 06/13] null: fake PMD capabilities

[Michał Mirosław]

From: Paweł Małachowski 

Thanks to that change we can use Null PMD for testing purposes.

Signed-off-by: Michał Mirosław 
---
 drivers/net/null/rte_eth_null.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..09d53b0 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
tx_queue_id,
return 0;
 }
 
+static void
+eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
+
 
 static void
 eth_dev_info(struct rte_eth_dev *dev,
@@ -304,6 +307,11 @@ eth_dev_info(struct rte_eth_dev *dev,
dev_info->pci_dev = NULL;
dev_info->reta_size = internals->reta_size;
dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
+   /* We hereby declare we can RX offload VLAN-s out of thin air and update
+* checksums and VLANs before sinking packets in /dev/null */
+   dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+   dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
+   DEV_TX_OFFLOAD_IPV4_CKSUM;
 }
 
 static void
@@ -477,7 +485,12 @@ static const struct eth_dev_ops ops = {
.reta_update = eth_rss_reta_update,
.reta_query = eth_rss_reta_query,
.rss_hash_update = eth_rss_hash_update,
-   .rss_hash_conf_get = eth_rss_hash_conf_get
+   .rss_hash_conf_get = eth_rss_hash_conf_get,
+   /* Fake our capabilities */
+   .promiscuous_enable   = eth_dev_void_ok,
+   .promiscuous_disable  = eth_dev_void_ok,
+   .allmulticast_enable  = eth_dev_void_ok,
+   .allmulticast_disable = eth_dev_void_ok
 };
 
 int
-- 
2.10.2

[dpdk-dev] [PATCH v2 08/13] PMD/af_packet: guard against buffer overruns in RX path

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 drivers/net/af_packet/rte_eth_af_packet.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index ff45068..5599e02 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -370,18 +370,19 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
 {
struct pmd_internals *internals = dev->data->dev_private;
struct pkt_rx_queue *pkt_q = &internals->rx_queue[rx_queue_id];
-   uint16_t buf_size;
+   unsigned int buf_size, data_size;
 
pkt_q->mb_pool = mb_pool;
 
/* Now get the space available for data in the mbuf */
-   buf_size = (uint16_t)(rte_pktmbuf_data_room_size(pkt_q->mb_pool) -
-   RTE_PKTMBUF_HEADROOM);
+   buf_size = rte_pktmbuf_data_room_size(pkt_q->mb_pool) - 
RTE_PKTMBUF_HEADROOM;
+   data_size = internals->req.tp_frame_size;
+   data_size -= TPACKET2_HDRLEN - sizeof(struct sockaddr_ll);
 
-   if (ETH_FRAME_LEN > buf_size) {
+   if (data_size > buf_size) {
RTE_LOG(ERR, PMD,
"%s: %d bytes will not fit in mbuf (%d bytes)\n",
-   dev->data->name, ETH_FRAME_LEN, buf_size);
+   dev->data->name, data_size, buf_size);
return -ENOMEM;
}
 
-- 
2.10.2

[dpdk-dev] [PATCH v2 09/13] PMD/af_packet: guard against buffer overruns in TX path

[Michał Mirosław]

Signed-off-by: Michał Mirosław 
---
 drivers/net/af_packet/rte_eth_af_packet.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index 5599e02..fc2dc4a 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -83,6 +83,7 @@ struct pkt_rx_queue {
 
 struct pkt_tx_queue {
int sockfd;
+   unsigned int frame_data_size;
 
struct iovec *rd;
uint8_t *map;
@@ -206,13 +207,20 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
framenum = pkt_q->framenum;
ppd = (struct tpacket2_hdr *) pkt_q->rd[framenum].iov_base;
for (i = 0; i < nb_pkts; i++) {
+   mbuf = *bufs++;
+
+   /* drop oversized packets */
+   if (rte_pktmbuf_data_len(mbuf) > pkt_q->frame_data_size) {
+   rte_pktmbuf_free(mbuf);
+   continue;
+   }
+
/* point at the next incoming frame */
if ((ppd->tp_status != TP_STATUS_AVAILABLE) &&
(poll(&pfd, 1, -1) < 0))
-   continue;
+   break;
 
/* copy the tx frame data */
-   mbuf = bufs[num_tx];
pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN -
sizeof(struct sockaddr_ll);
memcpy(pbuf, rte_pktmbuf_mtod(mbuf, void*), 
rte_pktmbuf_data_len(mbuf));
@@ -231,13 +239,13 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
 
/* kick-off transmits */
if (sendto(pkt_q->sockfd, NULL, 0, MSG_DONTWAIT, NULL, 0) == -1)
-   return 0; /* error sending -- no packets transmitted */
+   num_tx = 0; /* error sending -- no packets transmitted */
 
pkt_q->framenum = framenum;
pkt_q->tx_pkts += num_tx;
-   pkt_q->err_pkts += nb_pkts - num_tx;
+   pkt_q->err_pkts += i - num_tx;
pkt_q->tx_bytes += num_tx_bytes;
-   return num_tx;
+   return i;
 }
 
 static int
@@ -634,6 +642,8 @@ rte_pmd_init_internals(const char *name,
 
tx_queue = &((*internals)->tx_queue[q]);
tx_queue->framecount = req->tp_frame_nr;
+   tx_queue->frame_data_size = req->tp_frame_size;
+   tx_queue->frame_data_size -= TPACKET2_HDRLEN - sizeof(struct 
sockaddr_ll);
 
tx_queue->map = rx_queue->map + req->tp_block_size * 
req->tp_block_nr;
 
-- 
2.10.2

[dpdk-dev] [-- 06/13] null: fake PMD capabilities

[Michał Mirosław]

From: Paweł Małachowski 

Signed-off-by: Michał Mirosław 
---
 drivers/net/null/rte_eth_null.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..c802bc0 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
tx_queue_id,
return 0;
 }
 
+static void
+eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
+
 
 static void
 eth_dev_info(struct rte_eth_dev *dev,
@@ -304,6 +307,12 @@ eth_dev_info(struct rte_eth_dev *dev,
dev_info->pci_dev = NULL;
dev_info->reta_size = internals->reta_size;
dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
+   /* We hereby declare we can RX offload VLAN-s out of thin air and update
+* checksums and VLANs before sinking packets in /dev/null
+*/
+   dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+   dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
+   DEV_TX_OFFLOAD_IPV4_CKSUM;
 }
 
 static void
@@ -477,7 +486,12 @@ static const struct eth_dev_ops ops = {
.reta_update = eth_rss_reta_update,
.reta_query = eth_rss_reta_query,
.rss_hash_update = eth_rss_hash_update,
-   .rss_hash_conf_get = eth_rss_hash_conf_get
+   .rss_hash_conf_get = eth_rss_hash_conf_get,
+   /* Fake our capabilities */
+   .promiscuous_enable   = eth_dev_void_ok,
+   .promiscuous_disable  = eth_dev_void_ok,
+   .allmulticast_enable  = eth_dev_void_ok,
+   .allmulticast_disable = eth_dev_void_ok
 };
 
 int
-- 
2.10.2

Re: [dpdk-dev] [PATCH v2 22/32] app/testpmd: use multicast promiscuous mode on i40e

[Lu, Wenzhuo]

Hi Ferruh,


> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, December 7, 2016 11:02 PM
> To: Lu, Wenzhuo; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 22/32] app/testpmd: use multicast
> promiscuous mode on i40e
> 
> On 12/7/2016 3:32 AM, Wenzhuo Lu wrote:
> > Add testpmd CLI to set VF multicast promiscuous mode on i40e.
> >
> > Signed-off-by: Wenzhuo Lu 
> > ---
> >  app/test-pmd/cmdline.c  | 86 
> > +
> >  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  8 +++
> >  2 files changed, 94 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > d39712e..7e7a016 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -407,6 +407,9 @@ static void cmd_help_long_parsed(void
> > *parsed_result,  #ifdef RTE_LIBRTE_I40E_PMD
> > "set vf unicast-promisc (port_id) (vf_id) (on|off)\n"
> > "Set unicast promiscuous mode for a VF from the
> PF.\n\n"
> > +
> > +   "set vf multicast-promisc (port_id) (vf_id) (on|off)\n"
> > +   "Set multicast promiscuous mode for a VF from the
> PF.\n\n"
> 
> Why not "allmulti" instead of multicast-promisc?
> 
> Also same comments as previous patch for help_str and documentation.
Sorry for the late. You're right, I should not change the word. Will send a V3.

> 
> <...>

Re: [dpdk-dev] [PATCH v2 21/32] app/testpmd: use unicast promiscuous mode on i40e

[Lu, Wenzhuo]

Hi Ferruh,


> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, December 7, 2016 11:00 PM
> To: Lu, Wenzhuo; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 21/32] app/testpmd: use unicast promiscuous
> mode on i40e
> 
> On 12/7/2016 3:32 AM, Wenzhuo Lu wrote:
> > Add testpmd CLI to set VF unicast promiscuous mode on i40e.
> >
> > Signed-off-by: Wenzhuo Lu 
> > ---
> >  app/test-pmd/cmdline.c  | 92 
> > +
> >  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  8 +++
> >  2 files changed, 100 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > 12126ce..d39712e 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -404,6 +404,11 @@ static void cmd_help_long_parsed(void
> *parsed_result,
> > "set allmulti (port_id|all) (on|off)\n"
> > "Set the allmulti mode on port_id, or all.\n\n"
> >
> > +#ifdef RTE_LIBRTE_I40E_PMD
> > +   "set vf unicast-promisc (port_id) (vf_id) (on|off)\n"
> 
> Previous usages are all "promisc" instead of "unicals-promisc". Is this to 
> promisc
> mode for multicast packets? If so testpmd calls them "allmulti" I guess, so 
> they
> won't cause trouble.
> 
> Can we keep using command: "promisc"?
Yes, I'll change it.

> 
> <...>
> 
> > +
> > +cmdline_parse_inst_t cmd_set_vf_unicast_promisc = {
> > +   .f = cmd_set_vf_unicast_promisc_parsed,
> > +   .data = NULL,
> > +   .help_str = "set vf unicast promiscuous port_id vf_id on|off",
> 
> Can you please differentiate the keyword and variable by wrapping variables
> with <>? Like:
> "set vf unicast-promiscuous   on|off"
The existing style is not adding the '<>'. But this help string is not good, it 
looks like CLI but not help. I'll change it.

> 
> <...>
> 
> >
> > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > index f1c269a..e17e3d5 100644
> > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > @@ -820,6 +820,14 @@ Set the allmulti mode for a port or for all ports::
> >
> >  Same as the ifconfig (8) option. Controls how multicast packets are 
> > handled.
> >
> > +set unicast promisc (for VF)
> > +
> 
> Should we mention this is PMD specific feature and only enabled with some
> PMDs?
Yes. Will add more explanation.

> 
> > +
> > +Set the unicast promiscuous mode for a VF from PF.
> > +In promiscuous mode packets are not dropped if they aren't for the 
> > specified
> MAC address::
> > +
> > +   testpmd> set vf unicast-promisc (port_id) (vf_id) (on|off)
> > +
> >  set flow_ctrl rx
> >  
> >
> >

Re: [dpdk-dev] [PATCH 00/13] Introducing EAL Bus-Device-Driver Model

[Shreyansh Jain]

Hello Jianbo,

On Monday 12 December 2016 08:05 PM, Jianbo Liu wrote:

Hi Shreyansh,

On 7 December 2016 at 21:10, Shreyansh Jain  wrote:

On Wednesday 07 December 2016 05:47 PM, David Marchand wrote:


Hello Shreyansh,

On Wed, Dec 7, 2016 at 10:55 AM, Shreyansh Jain 
wrote:


On Wednesday 07 December 2016 02:22 AM, David Marchand wrote:


0002~0003: Introducing the basic Bus model and associated test case
0005:  Support insertion of device rather than addition to tail




Patch 2 and 5 could be squashed.




I deliberately kept them separate. I intent to extend the Patch 5 for
hotplugging. But, if I don't end up adding support for that in this
series,
I will merge these two.



Fine.



The constructor priority stuff seems unneeded as long as we use
explicit reference to a global (or local, did not check) bus symbol
rather than a runtime lookup.




I didn't understand your point here.
IMO, constructor priority (or some other way to handle this) is
important. I
faced this issue while verifying it at my end when the drivers were
getting
registered before the bus.

Can you elaborate more on '..use explicit reference to a global...'?



The drivers register themselves to a bus using this bus specific api.

For pci, this is rte_eal_pci_register().
The pci_bus object must be moved to eal_common_pci.c (we can stil
internally expose for bsd / linux specific implementations).
Then, rte_eal_pci_register() can add the pci driver to the pci_bus
drivers list even if this pci_bus object is not registered yet to the
buses list.



So, in eal_common_bus.c

--->8---

struct rte_bus *global_ptr_to_pci_bus = NULL;

struct rte_bus pci_bus = { ... };

rte_eal_pci_register() {
if (global_ptr_to_pci_bus == NULL)
rte_eal_bus_register(&pci_bus)
else
   // continue as if PCI bus is registered
}

--->8---

so, no RTE_REGISTER_BUS()?

If yes, then RTE_REGISTER_BUS() should also check for an existing
registration for duplication.

I was banking on a model where bus handlers (or bus drivers) are independent
entities, just like PMDs. So, we have a bus XYZ without any drivers
necessarily based on it.

By making registration dependent on driver registration, it becomes implicit
that buses don't exist without drivers.
I am not in favor of this - or maybe I lack enough reason for this (about
how it will make framework/PMD life better).



And no constructor order issue ?






0004:  Add scan and match callbacks for the Bus and updated test
case




Why do you push back the bus object in the 'scan' method ?
This method is bus specific which means that the code "knows" the
object registered with the callback.




This 'knows' is the grey area for me.
The bus (for example, PCI) after scanning needs to call
rte_eal_bus_add_device() to link the device in bus's device_list.

Two options:
1. Have a global reference to "pci" bus (rte_bus) somewhere in eal_pci.c
2. Call rte_eal_get_bus() every time someone needs the reference.
3. C++ style, 'this->'.

I have taken the 3rd path. It simplifies my code to not assume a handle
as
well as not allow for reference fetch calls every now and then.

As a disadvantage: it means passing this as argument - and some cases
maintaining it as __rte_unused.

Taking (1) or (2) is not advantageous than this approach.



1) is the simplest one.

When you write a pci_scan method and embed it in you pci_bus object,
but this pci_scan method still wonders which bus object it is supposed
to work on, this is a bit like Schizophrenia ;-).



:)
This now is linked to the above issue of constructor priority and having a
global bus reference. I don't personally prefer it.
I will still give this a serious thought, though.



I'm also in favor of (3).


Thank you. I was almost done with v2 and in that I had changed to what 
David had suggested. My preference too is (3). Now, I will prefer 
sticking with it - until someone comes with technical issue (like 
compiler compatibility etc) which I am unaware of.


@David: Can you re-think if you still prefer (1)? If so, I will change 
it in v3 (I will send v2 in a day or two max).








Is is that you want to have a single scan method used by multiple buses
?




Yes, but only as a use case. For example, platform devices are of various
types - what if we have a south-bound bus over a platform bus. In which
case, a hierarchical bus layout is possible.
But, this is far-fetched idea for now.




How to express the hierarchical bus layout as the bus in your design
is more like independent objects to hold drivers and their devices?


What I had in mind was something on the lines of:
 1) Add a new linked list 'bus_list' in rte_bus
 2) OR, embed rte_device in rte_bus

(1) is for maintaining buses as independent entity; (2) is for treating 
buses like devices (very similar to what Ferruh once suggested [2]). I
prefer (1), but I think programmatically (2) is much more symmetrical. I 
am assuming (1) below.


If we have: (taking hint from [1])

 CPU

Re: [dpdk-dev] [PATCH] SDK: Add scripts to initialize DPDK runtime

[Christian Ehrhardt]

On Mon, Dec 12, 2016 at 10:58 PM, Luca Boccassi 
wrote:

> If the 2 authors (CC'ed Stefan, the second one) agree and give
> permission it could be relicensed to BSD.
>
> Stefan, Christian, is that OK for you?
>

To re-license it for this purpose is ok for me, I'll ask Stefan later today
who was starting on it before me (and added the License initially).
Thanks for pushing that forward Luca!


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

[dpdk-dev] [PATCH] app/testpmd: fix invalid port ID

[Wenzhuo Lu]

Some CLIs don't check the input port ID, it
may cause segmentation fault (core dumped).

Fixes: 425781ff5afe ("app/testpmd: add ixgbe VF management")

Signed-off-by: Wenzhuo Lu 
Signed-off-by: Chen Jing D(Mark) 
---
CC: sta...@dpdk.org
---
 app/test-pmd/cmdline.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 63b55dc..315a252 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10807,6 +10807,9 @@ struct cmd_vf_vlan_anti_spoof_result {
int ret = 0;
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
ret = rte_pmd_ixgbe_set_vf_vlan_anti_spoof(res->port_id, res->vf_id,
is_on);
switch (ret) {
@@ -10892,6 +10895,9 @@ struct cmd_vf_mac_anti_spoof_result {
int ret;
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
ret = rte_pmd_ixgbe_set_vf_mac_anti_spoof(res->port_id, res->vf_id,
is_on);
switch (ret) {
@@ -10977,6 +10983,9 @@ struct cmd_vf_vlan_stripq_result {
int ret = 0;
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
ret = rte_pmd_ixgbe_set_vf_vlan_stripq(res->port_id, res->vf_id, is_on);
switch (ret) {
case 0:
@@ -11060,6 +11069,9 @@ struct cmd_vf_vlan_insert_result {
struct cmd_vf_vlan_insert_result *res = parsed_result;
int ret;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
ret = rte_pmd_ixgbe_set_vf_vlan_insert(res->port_id, res->vf_id, 
res->vlan_id);
switch (ret) {
case 0:
@@ -11134,6 +11146,9 @@ struct cmd_tx_loopback_result {
int ret;
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
ret = rte_pmd_ixgbe_set_tx_loopback(res->port_id, is_on);
switch (ret) {
case 0:
@@ -11211,6 +11226,9 @@ struct cmd_all_queues_drop_en_result {
int ret = 0;
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
ret = rte_pmd_ixgbe_set_all_queues_drop_en(res->port_id, is_on);
switch (ret) {
case 0:
@@ -11294,6 +11312,9 @@ struct cmd_vf_split_drop_en_result {
int ret;
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
ret = rte_pmd_ixgbe_set_vf_split_drop_en(res->port_id, res->vf_id,
is_on);
switch (ret) {
@@ -11378,6 +11399,9 @@ struct cmd_set_vf_mac_addr_result {
struct cmd_set_vf_mac_addr_result *res = parsed_result;
int ret;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
ret = rte_pmd_ixgbe_set_vf_mac_addr(res->port_id, res->vf_id,
&res->mac_addr);
switch (ret) {
-- 
1.9.3