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

2016-03-21 Thread Tetsuya Mukawa
2016-03-21 20:05 GMT+09:00 Bruce Richardson :
> On Mon, Mar 21, 2016 at 06:24:36PM +0900, Tetsuya Mukawa wrote:
>> 2016-03-21 17:37 GMT+09:00 Thomas Monjalon :
>> > 2016-03-21 14:45, Tetsuya Mukawa:
>> >> This event will be occured when some queues are enabled or disabled.
>> >> So far, only vhost PMD supports the event, and it indicates some queues
>> >> are enabled or disabled by virtio-net device. Such an event is needed
>> >> because virtio-net device may not enable all queues vhost PMD prepare.
>> >>
>> >> Because only vhost PMD uses the event so far, it isn't an actual hardware
>> >> interrupt but a simple software event.
>> > [...]
>> >>
>> >> + RTE_ETH_EVENT_QUEUE_STATE_CHANGE,
>> >> + /**< queue state changed interrupt */
>> >
>> > Is the shorter RTE_ETH_EVENT_QUEUE_STATE descriptive enough?
>> >
>> > What about this comment?
>> > /**< queue state event (enabled/disabled) */
>>
>> Hi Thomas,
>>
>> Yes, it's enough, and above comment is nice.
>> Thanks for suggestion.
>>
>>
>> Hi Bruce,
>>
>> If today is the deadline, could you kindly please replace above
>> changes while merging?
>> I need half a day to re-submit the patch. Sorry for asking it.
>> I will ask my company to let me have vpn access. ;)
>>
>> Regards,
>> Tetsuya
>
> Yes, I can fix on apply to dpdk-next-net.
>
> /Bruce

I appreciate your helping.

Regards,
Tetsuya


[dpdk-dev] [PATCH] mk: restrict CPU flags list

2016-03-21 Thread Thomas Monjalon
When compiling each file, the CPU flags are given as RTE_MACHINE_CPUFLAG_*
and in the list RTE_COMPILE_TIME_CPUFLAGS.

RTE_MACHINE_CPUFLAG_* are used to check the CPU features when compiling.

The list RTE_COMPILE_TIME_CPUFLAGS is used only to check the CPU at
runtime in the function rte_cpu_check_supported(). So it is not needed to
define this list for every files.
That's why RTE_COMPILE_TIME_CPUFLAGS is removed from the common variable
MACHINE_CFLAGS and is added only to the CFLAGS of eal_common_cpuflags.c.

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/bsdapp/eal/Makefile   | 2 ++
 lib/librte_eal/linuxapp/eal/Makefile | 2 ++
 mk/rte.cpuflags.mk   | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index 349b0d0..9054ad6 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -92,6 +92,8 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += rte_keepalive.c
 # from arch dir
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += rte_cpuflags.c

+CFLAGS_eal_common_cpuflags.o := $(CPUFLAGS_LIST)
+
 CFLAGS_eal.o := -D_GNU_SOURCE
 #CFLAGS_eal_thread.o := -D_GNU_SOURCE
 CFLAGS_eal_log.o := -D_GNU_SOURCE
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 25b3a8e..53d5b69 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -102,6 +102,8 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += rte_keepalive.c
 # from arch dir
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += rte_cpuflags.c

+CFLAGS_eal_common_cpuflags.o := $(CPUFLAGS_LIST)
+
 CFLAGS_eal.o := -D_GNU_SOURCE
 CFLAGS_eal_interrupts.o := -D_GNU_SOURCE
 CFLAGS_eal_pci_vfio_mp_sync.o := -D_GNU_SOURCE
diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
index 19a3e7e..c494654 100644
--- a/mk/rte.cpuflags.mk
+++ b/mk/rte.cpuflags.mk
@@ -128,4 +128,4 @@ empty:=
 space:= $(empty) $(empty)
 CPUFLAGSTMP1 := $(addprefix RTE_CPUFLAG_,$(CPUFLAGS))
 CPUFLAGSTMP2 := $(subst $(space),$(comma),$(CPUFLAGSTMP1))
-MACHINE_CFLAGS += -DRTE_COMPILE_TIME_CPUFLAGS=$(CPUFLAGSTMP2)
+CPUFLAGS_LIST := -DRTE_COMPILE_TIME_CPUFLAGS=$(CPUFLAGSTMP2)
-- 
2.7.0



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

2016-03-21 Thread Tetsuya Mukawa
2016-03-21 17:37 GMT+09:00 Thomas Monjalon :
> 2016-03-21 14:45, Tetsuya Mukawa:
>> This event will be occured when some queues are enabled or disabled.
>> So far, only vhost PMD supports the event, and it indicates some queues
>> are enabled or disabled by virtio-net device. Such an event is needed
>> because virtio-net device may not enable all queues vhost PMD prepare.
>>
>> Because only vhost PMD uses the event so far, it isn't an actual hardware
>> interrupt but a simple software event.
> [...]
>>
>> + RTE_ETH_EVENT_QUEUE_STATE_CHANGE,
>> + /**< queue state changed interrupt */
>
> Is the shorter RTE_ETH_EVENT_QUEUE_STATE descriptive enough?
>
> What about this comment?
> /**< queue state event (enabled/disabled) */

Hi Thomas,

Yes, it's enough, and above comment is nice.
Thanks for suggestion.


Hi Bruce,

If today is the deadline, could you kindly please replace above
changes while merging?
I need half a day to re-submit the patch. Sorry for asking it.
I will ask my company to let me have vpn access. ;)

Regards,
Tetsuya


[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

2016-03-21 Thread Xie, Huawei
On 3/18/2016 10:17 PM, Bruce Richardson wrote:
> On Fri, Mar 18, 2016 at 01:47:29PM +0100, Mauricio V?squez wrote:
>> Hi,
>>
>>
>> On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon > 6wind.com
>>> wrote:
>>> 2016-03-18 11:27, Olivier Matz:
 On 03/18/2016 11:18 AM, Bruce Richardson wrote:
>>> +   /* Avoid the unnecessary cmpset operation below, which is
>>> also
>>> +* potentially harmful when n equals 0. */
>>> +   if (n == 0)
>>>
>> What about using unlikely here?
>>
> Unless there is a measurable performance increase by adding in
>>> likely/unlikely
> I'd suggest avoiding it's use. In general, likely/unlikely should only
>>> be used
> for things like catestrophic errors because the penalty for taking the
>>> unlikely
> leg of the code can be quite severe. For normal stuff, where the code
>>> nearly
> always goes one way in the branch but occasionally goes the other, the
>>> hardware
> branch predictors generally do a good enough job.
 Do you mean using likely/unlikely could be worst than not using it
 in this case?

 To me, using unlikely here is not a bad idea: it shows to the compiler
 and to the reader of the code that is case is not the usual case.
>>> It would be nice to have a guideline section about likely/unlikely in
>>> doc/guides/contributing/design.rst
>>>
>>> Bruce gave a talk at Dublin about this kind of things.
>>> I'm sure he could contribute more design guidelines ;)
>>>
>> There is a small explanation in the section "Branch Prediction" of
>> doc/guides/contributing/coding_style.rst, but I do not know if that is
>> enough to understand when to use them.
>>
>> I've made a fast check and there are many PMDs that use them to check if
>> number of packets is zero in the transmission function.
> Yeah, and I wonder how many of those are actually necessary too :-)
>
> It's not a big deal either way, I just think the patch is fine as-is without
> the extra macros.

IMO we use likely/unlikely in two cases, catastrophic errors and the
code nearly always goes one way, i.e, preferred/favored fast path.
Likely/unlikely helps not only for branch predication but also for cache
usage. The code generated for the likely path will directly follow the
branch instruction. To me, it is reasonable enough to add unlikely for n
== 0, which we don't expect to happen.
I remember with/without likely, compiler could generate three kind of
instructions. Didn't deep dive into it.

>
> /Bruce
>



[dpdk-dev] [PATCH] mlx4: use dummy rxqs when a non-pow2 number is requested

2016-03-21 Thread Adrien Mazarguil
On Mon, Mar 21, 2016 at 05:08:04PM +0100, Olivier Matz wrote:
> When using RSS, the number of rxqs has to be a power of two.
> This is a problem because there is no API is dpdk that makes
> the application aware of that.
> 
> A good compromise is to allow the application to request a
> number of rxqs that is not a power of 2, but having inactive
> queues that will never receive packets. In this configuration,
> a warning will be issued to users to let them know that
> this is not an optimal configuration.
> 
> Signed-off-by: Olivier Matz 
> ---
>  drivers/net/mlx4/mlx4.c | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)

Acked-by: Adrien Mazarguil 

-- 
Adrien Mazarguil
6WIND


[dpdk-dev] [PATCH] mlx4: use dummy rxqs when a non-pow2 number is requested

2016-03-21 Thread Wiles, Keith


Sent from my iPhone

> On Mar 21, 2016, at 11:10 AM, Olivier Matz  wrote:
> 
> When using RSS, the number of rxqs has to be a power of two.
> This is a problem because there is no API is dpdk that makes
> the application aware of that.
> 
> A good compromise is to allow the application to request a
> number of rxqs that is not a power of 2, but having inactive
> queues that will never receive packets. In this configuration,
> a warning will be issued to users to let them know that
> this is not an optimal configuration.

Not sure I like this solution. I think an error should be returned with a log 
message instead. What if the next driver needs power of three or must be odd or 
even number. 

The bigger problem is the application is no longer portable for any given nic 
configuration.

We need a method for the application to query the system for these types of 
information. But as we do not have that API we need to just error the request 
off.

> 
> Signed-off-by: Olivier Matz 
> ---
> drivers/net/mlx4/mlx4.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index cc4e9aa..eaf06db 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -698,7 +698,7 @@ txq_cleanup(struct txq *txq);
> 
> static int
> rxq_setup(struct rte_eth_dev *dev, struct rxq *rxq, uint16_t desc,
> -  unsigned int socket, const struct rte_eth_rxconf *conf,
> +  unsigned int socket, int inactive, const struct rte_eth_rxconf *conf,
>  struct rte_mempool *mp);
> 
> static void
> @@ -734,12 +734,12 @@ dev_configure(struct rte_eth_dev *dev)
>}
>if (rxqs_n == priv->rxqs_n)
>return 0;
> -if ((rxqs_n & (rxqs_n - 1)) != 0) {
> -ERROR("%p: invalid number of RX queues (%u),"
> -  " must be a power of 2",
> +if (!rte_is_power_of_2(rxqs_n)) {
> +WARN("%p: number of RX queues (%u), must be a"
> +  " power of 2: remaining queues will be inactive",
>  (void *)dev, rxqs_n);
> -return EINVAL;
>}
> +
>INFO("%p: RX queues number update: %u -> %u",
> (void *)dev, priv->rxqs_n, rxqs_n);
>/* If RSS is enabled, disable it first. */
> @@ -775,7 +775,7 @@ dev_configure(struct rte_eth_dev *dev)
>priv->rss = 1;
>tmp = priv->rxqs_n;
>priv->rxqs_n = rxqs_n;
> -ret = rxq_setup(dev, >rxq_parent, 0, 0, NULL, NULL);
> +ret = rxq_setup(dev, >rxq_parent, 0, 0, 0, NULL, NULL);
>if (!ret)
>return 0;
>/* Failure, rollback. */
> @@ -3466,7 +3466,8 @@ rxq_setup_qp_rss(struct priv *priv, struct ibv_cq *cq, 
> uint16_t desc,
>attr.qpg.qpg_type = IBV_EXP_QPG_PARENT;
>/* TSS isn't necessary. */
>attr.qpg.parent_attrib.tss_child_count = 0;
> -attr.qpg.parent_attrib.rss_child_count = priv->rxqs_n;
> +attr.qpg.parent_attrib.rss_child_count =
> +rte_align32pow2(priv->rxqs_n + 1) >> 1;
>DEBUG("initializing parent RSS queue");
>} else {
>attr.qpg.qpg_type = IBV_EXP_QPG_CHILD_RX;
> @@ -3689,6 +3690,9 @@ skip_rtr:
>  *   Number of descriptors to configure in queue.
>  * @param socket
>  *   NUMA socket on which memory must be allocated.
> + * @param inactive
> + *   If true, the queue is disabled because its index is higher or
> + *   equal to the real number of queues, which must be a power of 2.
>  * @param[in] conf
>  *   Thresholds parameters.
>  * @param mp
> @@ -3699,7 +3703,7 @@ skip_rtr:
>  */
> static int
> rxq_setup(struct rte_eth_dev *dev, struct rxq *rxq, uint16_t desc,
> -  unsigned int socket, const struct rte_eth_rxconf *conf,
> +  unsigned int socket, int inactive, const struct rte_eth_rxconf *conf,
>  struct rte_mempool *mp)
> {
>struct priv *priv = dev->data->dev_private;
> @@ -3800,7 +3804,7 @@ skip_mr:
>DEBUG("priv->device_attr.max_sge is %d",
>  priv->device_attr.max_sge);
> #ifdef RSS_SUPPORT
> -if (priv->rss)
> +if (priv->rss && !inactive)
>tmpl.qp = rxq_setup_qp_rss(priv, tmpl.cq, desc, parent,
>   tmpl.rd);
>else
> @@ -3936,6 +3940,7 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
> idx, uint16_t desc,
> {
>struct priv *priv = dev->data->dev_private;
>struct rxq *rxq = (*priv->rxqs)[idx];
> +int inactive = 0;
>int ret;
> 
>if (mlx4_is_secondary())
> @@ -3967,7 +3972,9 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
> idx, uint16_t desc,
>return -ENOMEM;
>}
>}
> -ret = rxq_setup(dev, rxq, desc, socket, conf, mp);
> +if (idx >= rte_align32pow2(priv->rxqs_n + 1) >> 1)
> +inactive = 1;
> +ret = rxq_setup(dev, rxq, desc, socket, inactive, conf, mp);
>if (ret)
>rte_free(rxq);
>else {
> -- 
> 2.1.4
> 


[dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of compiler ones.

2016-03-21 Thread Ananyev, Konstantin


> -Original Message-
> From: Xie, Huawei
> Sent: Monday, March 21, 2016 5:26 PM
> To: Ananyev, Konstantin; Ilya Maximets; Yuanhan Liu
> Cc: dev at dpdk.org; Dyasly Sergey
> Subject: Re: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of 
> compiler ones.
> 
> On 3/21/2016 10:07 PM, Ananyev, Konstantin wrote:
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ilya Maximets
> >> Sent: Monday, March 21, 2016 4:50 AM
> >> To: Yuanhan Liu
> >> Cc: dev at dpdk.org; Xie, Huawei; Dyasly Sergey
> >> Subject: Re: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of 
> >> compiler ones.
> >>
> >>
> >>
> >> On 18.03.2016 15:41, Yuanhan Liu wrote:
> >>> On Fri, Mar 18, 2016 at 03:23:53PM +0300, Ilya Maximets wrote:
>  Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virtio
>  uses architecture dependent SMP barriers. vHost should use them too.
> 
>  Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers")
> 
>  Signed-off-by: Ilya Maximets 
>  ---
>   lib/librte_vhost/vhost_rxtx.c | 7 ---
>   1 file changed, 4 insertions(+), 3 deletions(-)
> 
>  diff --git a/lib/librte_vhost/vhost_rxtx.c 
>  b/lib/librte_vhost/vhost_rxtx.c
>  index b4da665..859c669 100644
>  --- a/lib/librte_vhost/vhost_rxtx.c
>  +++ b/lib/librte_vhost/vhost_rxtx.c
>  @@ -315,7 +315,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t 
>  queue_id,
>   rte_prefetch0(>desc[desc_indexes[i+1]]);
>   }
> 
>  -rte_compiler_barrier();
>  +rte_smp_wmb();
> 
>   /* Wait until it's our turn to add our buffer to the used ring. 
>  */
>   while (unlikely(vq->last_used_idx != res_start_idx))
>  @@ -565,7 +565,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t 
>  queue_id,
> 
>   nr_used = copy_mbuf_to_desc_mergeable(dev, vq, start, 
>  end,
> pkts[pkt_idx]);
>  -rte_compiler_barrier();
>  +rte_smp_wmb();
> 
>   /*
>    * Wait until it's our turn to add our buffer
>  @@ -923,7 +923,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, 
>  uint16_t queue_id,
>   sizeof(vq->used->ring[used_idx]));
>   }
> 
>  -rte_compiler_barrier();
>  +rte_smp_wmb();
>  +rte_smp_rmb();
> >>> rte_smp_mb?
> >> rte_smp_mb() is a real mm_fence() on x86. And we don't need to synchronize 
> >> reads with
> >> writes here, only reads with reads and writes with writes. It is enough 
> >> because next
> >> increment uses read and write. Pair of barriers is better because it will 
> >> not impact
> >> on performance on x86.
> > Not arguing about that particular patch, just a question:
> > Why do we have:
> > #define rte_smp_mb() rte_mb()
> 
> Konstantine, actually smp_mb is defined as mfence while smp_r/wmb are
> defined as barrier in kernel_src/arch/x86/include/asm/barrier.h.

I am aware of that, but who said that we should do the same?
Konstantin

> 
> > for  x86?
> > Why not just:
> > #define rte_smp_mb() rte_compiler_barrier()
> > here?
> > I meant for situations when we do need real mfence, there is an 'rte_mb' to 
> > use.
> > Konstantin
> >
> >> Best regards, Ilya Maximets.



[dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of compiler ones.

2016-03-21 Thread Xie, Huawei
On 3/21/2016 10:07 PM, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ilya Maximets
>> Sent: Monday, March 21, 2016 4:50 AM
>> To: Yuanhan Liu
>> Cc: dev at dpdk.org; Xie, Huawei; Dyasly Sergey
>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of 
>> compiler ones.
>>
>>
>>
>> On 18.03.2016 15:41, Yuanhan Liu wrote:
>>> On Fri, Mar 18, 2016 at 03:23:53PM +0300, Ilya Maximets wrote:
 Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virtio
 uses architecture dependent SMP barriers. vHost should use them too.

 Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers")

 Signed-off-by: Ilya Maximets 
 ---
  lib/librte_vhost/vhost_rxtx.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
 index b4da665..859c669 100644
 --- a/lib/librte_vhost/vhost_rxtx.c
 +++ b/lib/librte_vhost/vhost_rxtx.c
 @@ -315,7 +315,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t 
 queue_id,
rte_prefetch0(>desc[desc_indexes[i+1]]);
}

 -  rte_compiler_barrier();
 +  rte_smp_wmb();

/* Wait until it's our turn to add our buffer to the used ring. */
while (unlikely(vq->last_used_idx != res_start_idx))
 @@ -565,7 +565,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t 
 queue_id,

nr_used = copy_mbuf_to_desc_mergeable(dev, vq, start, end,
  pkts[pkt_idx]);
 -  rte_compiler_barrier();
 +  rte_smp_wmb();

/*
 * Wait until it's our turn to add our buffer
 @@ -923,7 +923,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, 
 uint16_t queue_id,
sizeof(vq->used->ring[used_idx]));
}

 -  rte_compiler_barrier();
 +  rte_smp_wmb();
 +  rte_smp_rmb();
>>> rte_smp_mb?
>> rte_smp_mb() is a real mm_fence() on x86. And we don't need to synchronize 
>> reads with
>> writes here, only reads with reads and writes with writes. It is enough 
>> because next
>> increment uses read and write. Pair of barriers is better because it will 
>> not impact
>> on performance on x86.
> Not arguing about that particular patch, just a question:
> Why do we have:
> #define rte_smp_mb() rte_mb()

Konstantine, actually smp_mb is defined as mfence while smp_r/wmb are
defined as barrier in kernel_src/arch/x86/include/asm/barrier.h.

> for  x86?
> Why not just:
> #define rte_smp_mb() rte_compiler_barrier()
> here?
> I meant for situations when we do need real mfence, there is an 'rte_mb' to 
> use.
> Konstantin
>
>> Best regards, Ilya Maximets.



[dpdk-dev] [PATCH] mlx4: use dummy rxqs when a non-pow2 number is requested

2016-03-21 Thread Olivier Matz
When using RSS, the number of rxqs has to be a power of two.
This is a problem because there is no API is dpdk that makes
the application aware of that.

A good compromise is to allow the application to request a
number of rxqs that is not a power of 2, but having inactive
queues that will never receive packets. In this configuration,
a warning will be issued to users to let them know that
this is not an optimal configuration.

Signed-off-by: Olivier Matz 
---
 drivers/net/mlx4/mlx4.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index cc4e9aa..eaf06db 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -698,7 +698,7 @@ txq_cleanup(struct txq *txq);

 static int
 rxq_setup(struct rte_eth_dev *dev, struct rxq *rxq, uint16_t desc,
- unsigned int socket, const struct rte_eth_rxconf *conf,
+ unsigned int socket, int inactive, const struct rte_eth_rxconf *conf,
  struct rte_mempool *mp);

 static void
@@ -734,12 +734,12 @@ dev_configure(struct rte_eth_dev *dev)
}
if (rxqs_n == priv->rxqs_n)
return 0;
-   if ((rxqs_n & (rxqs_n - 1)) != 0) {
-   ERROR("%p: invalid number of RX queues (%u),"
- " must be a power of 2",
+   if (!rte_is_power_of_2(rxqs_n)) {
+   WARN("%p: number of RX queues (%u), must be a"
+ " power of 2: remaining queues will be inactive",
  (void *)dev, rxqs_n);
-   return EINVAL;
}
+
INFO("%p: RX queues number update: %u -> %u",
 (void *)dev, priv->rxqs_n, rxqs_n);
/* If RSS is enabled, disable it first. */
@@ -775,7 +775,7 @@ dev_configure(struct rte_eth_dev *dev)
priv->rss = 1;
tmp = priv->rxqs_n;
priv->rxqs_n = rxqs_n;
-   ret = rxq_setup(dev, >rxq_parent, 0, 0, NULL, NULL);
+   ret = rxq_setup(dev, >rxq_parent, 0, 0, 0, NULL, NULL);
if (!ret)
return 0;
/* Failure, rollback. */
@@ -3466,7 +3466,8 @@ rxq_setup_qp_rss(struct priv *priv, struct ibv_cq *cq, 
uint16_t desc,
attr.qpg.qpg_type = IBV_EXP_QPG_PARENT;
/* TSS isn't necessary. */
attr.qpg.parent_attrib.tss_child_count = 0;
-   attr.qpg.parent_attrib.rss_child_count = priv->rxqs_n;
+   attr.qpg.parent_attrib.rss_child_count =
+   rte_align32pow2(priv->rxqs_n + 1) >> 1;
DEBUG("initializing parent RSS queue");
} else {
attr.qpg.qpg_type = IBV_EXP_QPG_CHILD_RX;
@@ -3689,6 +3690,9 @@ skip_rtr:
  *   Number of descriptors to configure in queue.
  * @param socket
  *   NUMA socket on which memory must be allocated.
+ * @param inactive
+ *   If true, the queue is disabled because its index is higher or
+ *   equal to the real number of queues, which must be a power of 2.
  * @param[in] conf
  *   Thresholds parameters.
  * @param mp
@@ -3699,7 +3703,7 @@ skip_rtr:
  */
 static int
 rxq_setup(struct rte_eth_dev *dev, struct rxq *rxq, uint16_t desc,
- unsigned int socket, const struct rte_eth_rxconf *conf,
+ unsigned int socket, int inactive, const struct rte_eth_rxconf *conf,
  struct rte_mempool *mp)
 {
struct priv *priv = dev->data->dev_private;
@@ -3800,7 +3804,7 @@ skip_mr:
DEBUG("priv->device_attr.max_sge is %d",
  priv->device_attr.max_sge);
 #ifdef RSS_SUPPORT
-   if (priv->rss)
+   if (priv->rss && !inactive)
tmpl.qp = rxq_setup_qp_rss(priv, tmpl.cq, desc, parent,
   tmpl.rd);
else
@@ -3936,6 +3940,7 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
idx, uint16_t desc,
 {
struct priv *priv = dev->data->dev_private;
struct rxq *rxq = (*priv->rxqs)[idx];
+   int inactive = 0;
int ret;

if (mlx4_is_secondary())
@@ -3967,7 +3972,9 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev, uint16_t 
idx, uint16_t desc,
return -ENOMEM;
}
}
-   ret = rxq_setup(dev, rxq, desc, socket, conf, mp);
+   if (idx >= rte_align32pow2(priv->rxqs_n + 1) >> 1)
+   inactive = 1;
+   ret = rxq_setup(dev, rxq, desc, socket, inactive, conf, mp);
if (ret)
rte_free(rxq);
else {
-- 
2.1.4



[dpdk-dev] [PATCH] igb_uio: fix vmware e1000 input/output error

2016-03-21 Thread Qian Xu
In vmware esxi 6.0, add the emulated e1000 device to guest, then
launch the VM, we will see the error meassage as below:

EAL: Error reading from file descriptor 21: Input/output error

INTX is badly emulated in Vmware, INTX toggle check didn't work
with Vmware e1000 device. The patch is to fix the issue. And the
patch is from http://dpdk.org/dev/patchwork/patch/945/, so Masaru
OKI is the author. Qian just updated the patch for latest code.

Signed-off-by: Masaru OKI

diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c 
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 72b2692..f5e9aeb 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -450,14 +450,11 @@ igbuio_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
}
/* fall back to INTX */
case RTE_INTR_MODE_LEGACY:
-   if (pci_intx_mask_supported(dev)) {
-   dev_dbg(>dev, "using INTX");
-   udev->info.irq_flags = IRQF_SHARED;
-   udev->info.irq = dev->irq;
-   udev->mode = RTE_INTR_MODE_LEGACY;
-   break;
-   }
-   dev_notice(>dev, "PCI INTX mask not supported\n");
+dev_dbg(>dev, "using INTX");
+udev->info.irq_flags = IRQF_SHARED;
+udev->info.irq = dev->irq;
+udev->mode = RTE_INTR_MODE_LEGACY;
+break;
/* fall back to no IRQ */
case RTE_INTR_MODE_NONE:
udev->mode = RTE_INTR_MODE_NONE;
-- 
2.1.0



[dpdk-dev] multi-segment mbuf

2016-03-21 Thread Clarylin L
I am trying multi-segment mbuf, but it seems not working.

On my target host, the mbuf size is set to 2048 and I am trying to send
large packet to it (say 2500 bytes without fragmentation) from another
host. I enabled both jumbo_frame and enable_scatter for the port. But I saw
on the target only one mbuf is received with data_len equal to 2500 (it's
supposed to be a two-mbuf chain).  Although mbuf itself is not working as
expected, ping between two hosts succeeded (large ping size; no
fragmentation).

1. my mbuf size is only 2048. how can it support receiving such large
packet in one mbuf?

2.how to make it work as expected (enable multi-segment mbuf and receive
using mbuf chain when needed)?

Appreciate your help.


[dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread

2016-03-21 Thread Liang, Cunming
Hi Matthew,

On 3/18/2016 6:55 AM, Matthew Hall wrote:
>  From Cunming:
>> I'm trying to understand the motivation.
>>
>> I don't think you're going to gracefully exit intr thread but leave all
>> other eal threads live. We don't have API to new launch intr thread again.
> The doc comment added for rte_eal_intr_exit already explains this. According
> to the doc I wrote, use of the function is limited to shutting everything
> down.
>
>> So I guess your app is using own pthread(none EAL thread), you're trying to
>> safely shutdown the whole application by your signal handler.
> No, the app is using DPDK pthreads, and trying to shutdown everything safely
> and cleanly w/ its signal handler, across DPDK and many other services in the
> app.
Get you. You don't satisfy with the default termination signal 
handler(SIG_DEL). The purpose is to safely clean everything by 
self-defined signal handler. Can you share us more of your observation 
on why the default termination handler is not enough/safe? As some of 
the samples are using it to terminate app, your concern may be necessary 
to apply on them as well.

> Unfortunately, right now from my experience it is impossible to get 
> everything to
> cleanly shutdown, one an interrupt thread is activated. Because interrupt
> threads violate violate POSIX semantics:
>
> 1) It ignores EINTR and immediately forcibly restarts a poll() syscall. If the
> signal is delivered to the interrupt thread of the process by the kernel, this
> makes the thread uninterruptible to process the signal. Stuck running forever.
If EINTR is caused by some non-term purpose signals, are you going to 
exit the interrupt thread any way?

> 2) It does not properly set PTHREAD_CREATE_DETACHED for a background thread.
> So it holds the process open for its infinite loop of poll(). Stuck running
> forever.
Without setting 'PTHREAD_CREATE_DETACHED' won't cause the infinite loop. 
However by using pthread_cancel to terminate the thread, indeed it's 
necessary to set 'PTHREAD_CREATE_DETACHED'.

> 3) There is no way to access the thread_id from intr_thread. So then you can't
> call pthread_cancel on it to shut it down. Stuck running forever.
It looks like 'pthread_cancel' is the right way and I saw it continue 
keeps current EINTR handling in EAL interrupt thread.

>> For this purpose, the device shall close safely(turn off intr) during the
>> time, intr thread still wait but no event will be raised.
> In theory yes. In practice no. Because the intr thread violated POSIX rules
> for background processing threads per above.
>
>> In this view, it seems not necessary to have this new. Can you explain more
>> detail for the purpose?
> Based on my testing, I disagree. I could not get reliable shutdowns without
> this, or I wouldn't have coded it. (:

Now it's clear to me, overall it's fine. Three additional comments.
1. Can you explain and add patch comments why default signal handler is 
not good enough to terminate app.
2. I propose to add addition comments on rte_epoll_wait() API 
description. For any signal, it causes an error return, user needs to 
handle.
3. Will you do a favorite to add 'PTHREAD_CREATE_DETACHED' to all EAL 
pthread too.

Cunming

> Matthew.
>
>




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

2016-03-21 Thread Loftus, Ciara
Hi Tetsuya,

Thanks for the patches. Just one query below re max queue numbers.

Thanks,
Ciara

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> Sent: Monday, March 21, 2016 5:45 AM
> To: dev at dpdk.org
> Cc: Richardson, Bruce ;
> ann.zhuangyanying at huawei.com; thomas.monjalon at 6wind.com; Tetsuya
> Mukawa 
> Subject: [dpdk-dev] [PATCH v13 2/2] vhost: Add VHOST PMD
> 
> The patch introduces a new PMD. This PMD is implemented as thin wrapper
> of librte_vhost. It means librte_vhost is also needed to compile the PMD.
> The vhost messages will be handled only when a port is started. So start
> a port first, then invoke QEMU.
> 
> The PMD has 2 parameters.
>  - iface:  The parameter is used to specify a path to connect to a
>virtio-net device.
>  - queues: The parameter is used to specify the number of the queues
>virtio-net device has.
>(Default: 1)
> 
> Here is an example.
> $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i
> 
> To connect above testpmd, here is qemu command example.
> 
> $ qemu-system-x86_64 \
> 
> -chardev socket,id=chr0,path=/tmp/sock0 \
> -netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
> -device virtio-net-pci,netdev=net0,mq=on
> 
> Signed-off-by: Tetsuya Mukawa 
> Acked-by: Ferruh Yigit 
> Acked-by: Yuanhan Liu 
> Acked-by: Rich Lane 
> Tested-by: Rich Lane 
> ---
>  MAINTAINERS |   5 +
>  config/common_base  |   6 +
>  config/common_linuxapp  |   1 +
>  doc/guides/nics/index.rst   |   1 +
>  doc/guides/nics/overview.rst|  37 +-
>  doc/guides/nics/vhost.rst   | 110 
>  doc/guides/rel_notes/release_16_04.rst  |   4 +
>  drivers/net/Makefile|   4 +
>  drivers/net/vhost/Makefile  |  62 ++
>  drivers/net/vhost/rte_eth_vhost.c   | 917
> 
>  drivers/net/vhost/rte_eth_vhost.h   | 109 
>  drivers/net/vhost/rte_pmd_vhost_version.map |  10 +
>  mk/rte.app.mk   |   6 +
>  13 files changed, 1254 insertions(+), 18 deletions(-)
>  create mode 100644 doc/guides/nics/vhost.rst
>  create mode 100644 drivers/net/vhost/Makefile
>  create mode 100644 drivers/net/vhost/rte_eth_vhost.c
>  create mode 100644 drivers/net/vhost/rte_eth_vhost.h
>  create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8b21979..7a47fc0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -352,6 +352,11 @@ Null PMD
>  M: Tetsuya Mukawa 
>  F: drivers/net/null/
> 
> +Vhost PMD
> +M: Tetsuya Mukawa 
> +M: Yuanhan Liu 
> +F: drivers/net/vhost/
> +
>  Intel AES-NI GCM PMD
>  M: Declan Doherty 
>  F: drivers/crypto/aesni_gcm/
> diff --git a/config/common_base b/config/common_base
> index dbd405b..5efee07 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -514,6 +514,12 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
>  CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
> 
>  #
> +# Compile vhost PMD
> +# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
> +#
> +CONFIG_RTE_LIBRTE_PMD_VHOST=n
> +
> +#
>  #Compile Xen domain0 support
>  #
>  CONFIG_RTE_LIBRTE_XEN_DOM0=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index ffbe260..7e698e2 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -40,5 +40,6 @@ CONFIG_RTE_EAL_VFIO=y
>  CONFIG_RTE_KNI_KMOD=y
>  CONFIG_RTE_LIBRTE_KNI=y
>  CONFIG_RTE_LIBRTE_VHOST=y
> +CONFIG_RTE_LIBRTE_PMD_VHOST=y
>  CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
>  CONFIG_RTE_LIBRTE_POWER=y
> diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
> index 0b353a8..d53b0c7 100644
> --- a/doc/guides/nics/index.rst
> +++ b/doc/guides/nics/index.rst
> @@ -49,6 +49,7 @@ Network Interface Controller Drivers
>  nfp
>  szedata2
>  virtio
> +vhost
>  vmxnet3
>  pcap_ring
> 
> diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
> index 2d4f014..40ca5ec 100644
> --- a/doc/guides/nics/overview.rst
> +++ b/doc/guides/nics/overview.rst
> @@ -74,20 +74,21 @@ Most of these differences are summarized below.
> 
>  .. table:: Features availability in networking drivers
> 
> -    = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = = = =
> -   Feature  a b b b c e e i i i i i i i i i i f f m m m n n p r 
> s v v v x
> -f n n o x 1 n 4 4 4 4 g g x x x x m m l l p f u c i 
> z i i m e
> -p x x n g 0 i 0 0 0 0 b b g g g g 1 1 x x i p l a n 
> e r r x n
> -a 2 2 d b 0 c e e e e   v b b b b 0 0 4 5 p   l p g 
> d t t n v
> -c x x i e 0 . v v   f e e e e k k e 
> a i i e i
> -k   v n . f f   . v v   .   
> t o o t 

[dpdk-dev] [PATCH] examples/l3fwd: fix validation for queue id of config tuple

2016-03-21 Thread Thomas Monjalon
2016-03-18 10:35, Reshma Pattan:
> Added validation for queue id of config parameter tuple.
> 
> This validation enforces user to enter queue ids of a port
> from 0 and in sequence.
> 
> This additional validation on queue ids avoids ixgbe crash caused by null
> rxq pointer access inside ixgbe_dev_rx_init.
> 
> Reason for null rxq is, L3fwd application allocates memory only for queues 
> passed by user.
> But rte_eth_dev_start  tries to initialize rx queues in sequence from 0 to 
> nb_rx_queues,
> which is not true and coredump while accessing the unallocated queue .
> 
> Fixes: Commit af75078f

Fixes: af75078fece3 ("first public release")

>   for (i = 0; i < nb_lcore_params; ++i) {
>   if (lcore_params[i].port_id == port &&
> - lcore_params[i].queue_id > queue)
> + lcore_params[i].queue_id > queue &&

This check is not really useful if queue_id == queue+1

> + lcore_params[i].queue_id == queue+1)
>   queue = lcore_params[i].queue_id;
> + else if (lcore_params[i].port_id == port &&

This line repeats the above check.
You can nest the "if" instead of "else if".

> + lcore_params[i].queue_id != queue+1)
> + rte_exit(EXIT_FAILURE, "queue ids of the port %d must 
> be"
> + " in sequence and must start with 0",
> + lcore_params[i].port_id);
>   }




[dpdk-dev] [PATCH v4 5/5] lpm: fix missing free of rules_tbl and lpm in rte_lpm_free*

2016-03-21 Thread Christian Ehrhardt
As found in rte_lpm6_free the two lpm interfaces rte_lpm_free_v20 and
rte_lpm_free_v1604 had a leak.

rte_lpm_free_v20 might have missed to free rules_tbl
rte_lpm_free_v1604 due to an early exit might have missed to free
rules_tbl and lpm itself.

Acked-by: Olivier Matz 
Signed-off-by: Christian Ehrhardt 
---
 lib/librte_lpm/rte_lpm.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 59ce5a7..af5811c 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -367,6 +367,7 @@ rte_lpm_free_v20(struct rte_lpm_v20 *lpm)

rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);

+   rte_free(lpm->rules_tbl);
rte_free(lpm);
rte_free(te);
 }
@@ -391,15 +392,12 @@ rte_lpm_free_v1604(struct rte_lpm *lpm)
if (te->data == (void *) lpm)
break;
}
-   if (te == NULL) {
-   rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
-   return;
-   }
-
-   TAILQ_REMOVE(lpm_list, te, next);
+   if (te != NULL)
+   TAILQ_REMOVE(lpm_list, te, next);

rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);

+   rte_free(lpm->rules_tbl);
rte_free(lpm);
rte_free(te);
 }
-- 
2.7.3



[dpdk-dev] [PATCH v4 4/5] lpm: fix use after free of lpm in rte_lpm_create*

2016-03-21 Thread Christian Ehrhardt
There were further chances for a use after free by returning an already freed
pointer in rte_lpm_create for v20 and v1604.
Along that is also makes the RTE_LOG messages of the failed allocations unique.

Acked-by: Olivier Matz 
Signed-off-by: Christian Ehrhardt 
---
 lib/librte_lpm/rte_lpm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index d5fa1f8..59ce5a7 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -303,8 +303,9 @@ rte_lpm_create_v1604(const char *name, int socket_id,
(size_t)rules_size, RTE_CACHE_LINE_SIZE, socket_id);

if (lpm->rules_tbl == NULL) {
-   RTE_LOG(ERR, LPM, "LPM memory allocation failed\n");
+   RTE_LOG(ERR, LPM, "LPM rules_tbl memory allocation failed\n");
rte_free(lpm);
+   lpm = NULL;
rte_free(te);
goto exit;
}
@@ -313,8 +314,9 @@ rte_lpm_create_v1604(const char *name, int socket_id,
(size_t)tbl8s_size, RTE_CACHE_LINE_SIZE, socket_id);

if (lpm->tbl8 == NULL) {
-   RTE_LOG(ERR, LPM, "LPM memory allocation failed\n");
+   RTE_LOG(ERR, LPM, "LPM tbl8 memory allocation failed\n");
rte_free(lpm);
+   lpm = NULL;
rte_free(te);
goto exit;
}
-- 
2.7.3



[dpdk-dev] [PATCH v4 3/5] lpm: fix missing free of lpm

2016-03-21 Thread Christian Ehrhardt
Fixing lpm6 regarding a similar issue showed that that in
rte_lpm_free lpm might not be freed if it didn't find a te (early return)

Acked-by: Bruce Richardson 
Acked-by: Olivier Matz 
Signed-off-by: Christian Ehrhardt 
---
 lib/librte_lpm/rte_lpm.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index ccaaa2a..d5fa1f8 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -360,12 +360,8 @@ rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
if (te->data == (void *) lpm)
break;
}
-   if (te == NULL) {
-   rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
-   return;
-   }
-
-   TAILQ_REMOVE(lpm_list, te, next);
+   if (te != NULL)
+   TAILQ_REMOVE(lpm_list, te, next);

rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);

-- 
2.7.3



[dpdk-dev] [PATCH v4 2/5] lpm6: fix missing free of rules_tbl and lpm

2016-03-21 Thread Christian Ehrhardt
lpm6 autotests failed with the default alloc of 512M Memory.
While >=2500M was a workaround it became clear while debugging that it
had a leak.
One could see a lot of output like:
  LPM Test tests6[i]: FAIL
  LPM: LPM memory allocation failed

It turned out that in rte_lpm6_free
- lpm might not be freed if it didn't find a te (early return)
- lpm->rules_tbl was not freed ever

Acked-by: Bruce Richardson 
Acked-by: Olivier Matz 
Signed-off-by: Christian Ehrhardt 
---
 lib/librte_lpm/rte_lpm6.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 48931cc..4c44cd7 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -278,15 +278,13 @@ rte_lpm6_free(struct rte_lpm6 *lpm)
if (te->data == (void *) lpm)
break;
}
-   if (te == NULL) {
-   rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
-   return;
-   }

-   TAILQ_REMOVE(lpm_list, te, next);
+   if (te != NULL)
+   TAILQ_REMOVE(lpm_list, te, next);

rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);

+   rte_free(lpm->rules_tbl);
rte_free(lpm);
rte_free(te);
 }
-- 
2.7.3



[dpdk-dev] [PATCH v4 1/5] lpm6: fix use after free of lpm in rte_lpm6_create

2016-03-21 Thread Christian Ehrhardt
In certain autotests lpm->max_rules turned out to be non initialized.
That was caused by a failing allocation for lpm->rules_tbl in rte_lpm6_create.
It then left the function via goto exit with lpm freed, but still a pointer
value being set.

In case of an allocation failure it resets lpm to NULL now, to avoid the
upper layers operate on that already freed memory.
Along that is also makes the RTE_LOG message of the failed allocation unique.

Acked-by: Stephen Hemminger 
Acked-by: Olivier Matz 
Signed-off-by: Christian Ehrhardt 
---
 lib/librte_lpm/rte_lpm6.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 6c2b293..48931cc 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -206,8 +206,9 @@ rte_lpm6_create(const char *name, int socket_id,
(size_t)rules_size, RTE_CACHE_LINE_SIZE, socket_id);

if (lpm->rules_tbl == NULL) {
-   RTE_LOG(ERR, LPM, "LPM memory allocation failed\n");
+   RTE_LOG(ERR, LPM, "LPM rules_tbl allocation failed\n");
rte_free(lpm);
+   lpm = NULL;
rte_free(te);
goto exit;
}
-- 
2.7.3



[dpdk-dev] [PATCH v4 0/5] lpm allocation fixes

2016-03-21 Thread Christian Ehrhardt
Poking a bit on autotest revealed a few shortcomings in the lpm allocation path.
Thanks to the feedback to the first revision of the patches here v2.
Also Oliver Matz spotted similar issues and made me aware - thanks!
Integrating them revealed even more use after free / leak issues.

*updates in v4*
- re-removing the { } on single line ifs accidentially droped in v3
- adding the ack of Oliver Matz

*updates in v3*
- lpm create/free path for v20 and v1604 got the same fixes that were
  already identified for lpm6 before

*updates in v2*
- lpm/lpm6 patches split
- following dpdk coding guidelines regarding single line if's
- adding singed-off and acked-bys gathered so far
- combine all three related patches in one series

Christian Ehrhardt (5):
  lpm6: fix use after free of lpm in rte_lpm6_create
  lpm6: fix missing free of rules_tbl and lpm
  lpm: fix missing free of lpm
  lpm: fix use after free of lpm in rte_lpm_create*
  lpm: fix missing free of rules_tbl and lpm in rte_lpm_free*

 lib/librte_lpm/rte_lpm.c  | 24 ++--
 lib/librte_lpm/rte_lpm6.c | 11 +--
 2 files changed, 15 insertions(+), 20 deletions(-)

-- 
2.7.3



[dpdk-dev] [PATCH 0/5] lpm allocation fixes - v3

2016-03-21 Thread Christian Ehrhardt
Hi Oliver,
thanks for the ack - I had these {} fixed in v2, but accidentially dropped
when merging our code.
v3 was flawed anyway as my submission was not a proper reply-to to the
older series.

This shall not be Thomas work to do, I'll resubmit a v4 re-adding the {}
fix and properly replying to the former v2 as it was intended but failed
for v3.
I also add your acked-by and I'm eager looking forward seeing the patches
pushed then.

Kind Regards,
Christian

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Mon, Mar 21, 2016 at 2:18 PM, Olivier Matz 
wrote:

>
>
> On 03/16/2016 03:16 PM, Christian Ehrhardt wrote:
> > Poking a bit on autotest revealed a few shortcomings in the lpm
> allocation path.
> > Thanks to the feedback to the first revision of the patches here v2.
> > Also Oliver Matz spotted similar issues and made me aware - thanks!
> > Integrating them revealed even more use after free / leak issues.
> >
> > *updates in v3*
> > - lpm create/free path for v20 and v1604 got the same fixes that were
> >   already identified for lpm6 before
> >
> > *updates in v2*
> > - lpm/lpm6 patches split
> > - following dpdk coding guidelines regarding single line if's
> > - adding singed-off and acked-bys gathered so far
> > - combine all three related patches in one series
> >
> > [PATCH 1/5] lpm6: fix use after free of lpm in rte_lpm6_create
> > [PATCH 2/5] lpm6: fix missing free of rules_tbl and lpm
> > [PATCH 3/5] lpm: fix missing free of lpm
> > [PATCH 4/5] lpm: fix use after free of lpm in rte_lpm_create*
> > [PATCH 5/5] lpm: fix missing free of rules_tbl and lpm in
> >
> > diffstat:
> >  rte_lpm.c  |   23 ++-
> >  rte_lpm6.c |   12 ++--
> >  2 files changed, 16 insertions(+), 19 deletions(-)
> >
>
> Series
> Acked-by: Olivier Matz 
>
> Just one small comment: there are additional { } in patches
> 2/5 and 3/5.
>
> Thomas, do you think you can remove it while pushing?
>
>
>


[dpdk-dev] [PATCH v3 4/4] eal/arm: introduce CONFIG_RTE_ARCH_ARM_NEON_MEMCPY

2016-03-21 Thread Jan Viktorin
On Mon, 21 Mar 2016 06:24:37 -0700 (PDT)
Thomas Monjalon  wrote:

> 2016-03-21 13:21, Jan Viktorin:
> > On Mon, 21 Mar 2016 13:42:31 +0800
> > Jianbo Liu  wrote:
> >   
> > > On 20 March 2016 at 03:58, Jan Viktorin  
> > > wrote:  
> > > > The flag is used to enable memcpy optimizations in EAL. As it is not 
> > > > always
> > > > the performance benefit, the flag allows to disable it.
> > > >
> > > > Signed-off-by: Jan Viktorin 
> > > > ---
> > > >  config/defconfig_arm-armv7a-linuxapp-gcc   | 1 +
> > > >  lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 8 ++--
> > > >  2 files changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
> > > > b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > index 96c3343..2c60c2c 100644
> > > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > @@ -36,6 +36,7 @@ CONFIG_RTE_ARCH="arm"
> > > >  CONFIG_RTE_ARCH_ARM=y
> > > >  CONFIG_RTE_ARCH_ARMv7=y
> > > >  CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
> > > > +CONFIG_RTE_ARCH_ARM_NEON_MEMCPY=y
> > > >
> > > If it's not always benefit, why not disable here since it is common
> > > armv7a config, and enable in your or other user's own config file?  
> > 
> > Jianbo, you are right. In that case, I'd just turn it off by default.
> > And when there is a new platform-specific defconfig, it can enable it.
> > 
> > Anyway, I am thinking of adding some comment into the rte_memcpy_32.h
> > file describing the potential of the NEON code. What about:
> > 
> > /* Enable in your defconfig to accelerate memcpy operations. Consider
> >enabling this for Cortex-A15. For Cortex-A7 and Cortex-A9, It might
> >accelerate short data copies (< 64 B). */
> > 
> > Thomas, do you consider this enough?  
> 
> Yes it is perfect.
> Why not put it in defconfig_arm-armv7a-linuxapp-gcc?

So, for now, I leave the patch as is and just add the comment.

Jan


[dpdk-dev] [PATCH] testpmd: fix build on FreeBSD

2016-03-21 Thread Bruce Richardson
On Mon, Mar 21, 2016 at 09:40:07AM +, De Lara Guarch, Pablo wrote:
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez
> > Monroy
> > Sent: Monday, March 21, 2016 9:13 AM
> > To: Liu, Yong; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] testpmd: fix build on FreeBSD
> > 
> > On 21/03/2016 01:44, Marvin Liu wrote:
> > > Build log:
> > > /root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
> > > 's6_addr32' in 'struct in6_addr'
> > >   rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> > >
> > > This is caused by macro "s6_addr32" not defined on FreeBSD.
> > >
> > > Signed-off-by: Marvin Liu 
> > >
> > > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > > index 9d52b8c..51ad23b 100644
> > > --- a/app/test-pmd/cmdline.c
> > > +++ b/app/test-pmd/cmdline.c
> > > @@ -6684,7 +6684,11 @@ cmd_tunnel_filter_parsed(void *parsed_result,
> > >   int i;
> > >   for (i = 0; i < 4; i++) {
> > >   tunnel_filter_conf.ip_addr.ipv6_addr[i] =
> > > +#ifdef RTE_EXEC_ENV_BSDAPP
> > > + rte_be_to_cpu_32(res-
> > >ip_value.addr.ipv6.__u6_addr.__u6_addr32[i]);
> > > +#else
> > >   rte_be_to_cpu_32(res-
> > >ip_value.addr.ipv6.s6_addr32[i]);
> > > +#endif
> > 
> > Why not always use .__u6_addr.__u6_addr32[i] and avoid ifdef?
> > 
> > Sergio
> > 
> > >   }
> > >   tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV6;
> > >   }
> 
> Also, can you include the missing "Fixes" line?
> 
A slightly higher level question:
Why are we doing 32-bit endian conversions, when IPv6 addresses are normally
specified in 16-bit (4-hex digit) blocks?

/Bruce


[dpdk-dev] DPDK and HW offloads

2016-03-21 Thread Bruce Richardson
On Sun, Mar 20, 2016 at 08:18:57PM +0100, Thomas Monjalon wrote:
> 2016-03-20 14:17, Zhang, Helin:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > 2016-03-18 10:16, Stephen Hemminger:
> > > > Right now, all those offload features are pretty much unusable in a
> > > > real product without lots and lots of extra codes and huge bug
> > > > surface. It bothers me enough that I would recommend removing much of 
> > > > the
> > > filter/offload/ptype stuff from DPDK!
> > > 
> > > One of the biggest challenge is to think about a good filtering API.
> > > The offloading has some interaction with the mbuf struct.
> > > 
> > > I would like to suggest rewriting ethdev API by keeping it as is for some 
> > > time for
> > > compatibility while creating a new one. What about the prefix 
> > > dpdk_netdev_ to
> > > progressively replace rte_eth_dev?
> > 
> > I totally agree with to add new and generic APIs for user applications. But 
> > I don't
> > think we need to remove all current APIs. Generic APIs may not support all 
> > advanced
> > hardware features, while specific APIs can. Why not support all? One 
> > generic APIs for
> > common users, and others APIs for advanced users.
> 
> Yes we cannot access to every features of a device through generic API.
> Until now we were trying to add an ethdev API for every features even if it
> is used by only one driver.
> I think we should allow a direct access to the driver by the applications and
> work on generic API only for common features.

Definite +1.
I think that we need to start pushing driver-specific functionality to get 
exposed
via a driver's header files. That allow users who want to extract the max
functionality from a particular NIC to do so via those APIs calls, while not
polluting the generic ethdev layer.

On the other hand, I don't like the idea of dpdk_netdev. I think we can work
within the existing rte_eth_dev framework.

/Bruce



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

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

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

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

To connect above testpmd, here is qemu command example.

$ qemu-system-x86_64 \

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

Signed-off-by: Tetsuya Mukawa 
Acked-by: Ferruh Yigit 
Acked-by: Yuanhan Liu 
Acked-by: Rich Lane 
Tested-by: Rich Lane 
---
 MAINTAINERS |   5 +
 config/common_base  |   6 +
 config/common_linuxapp  |   1 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/overview.rst|  37 +-
 doc/guides/nics/vhost.rst   | 110 
 doc/guides/rel_notes/release_16_04.rst  |   4 +
 drivers/net/Makefile|   4 +
 drivers/net/vhost/Makefile  |  62 ++
 drivers/net/vhost/rte_eth_vhost.c   | 917 
 drivers/net/vhost/rte_eth_vhost.h   | 109 
 drivers/net/vhost/rte_pmd_vhost_version.map |  10 +
 mk/rte.app.mk   |   6 +
 13 files changed, 1254 insertions(+), 18 deletions(-)
 create mode 100644 doc/guides/nics/vhost.rst
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 8b21979..7a47fc0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -352,6 +352,11 @@ Null PMD
 M: Tetsuya Mukawa 
 F: drivers/net/null/

+Vhost PMD
+M: Tetsuya Mukawa 
+M: Yuanhan Liu 
+F: drivers/net/vhost/
+
 Intel AES-NI GCM PMD
 M: Declan Doherty 
 F: drivers/crypto/aesni_gcm/
diff --git a/config/common_base b/config/common_base
index dbd405b..5efee07 100644
--- a/config/common_base
+++ b/config/common_base
@@ -514,6 +514,12 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 CONFIG_RTE_LIBRTE_VHOST_DEBUG=n

 #
+# Compile vhost PMD
+# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
+#
+CONFIG_RTE_LIBRTE_PMD_VHOST=n
+
+#
 #Compile Xen domain0 support
 #
 CONFIG_RTE_LIBRTE_XEN_DOM0=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index ffbe260..7e698e2 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -40,5 +40,6 @@ CONFIG_RTE_EAL_VFIO=y
 CONFIG_RTE_KNI_KMOD=y
 CONFIG_RTE_LIBRTE_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
+CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_POWER=y
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 0b353a8..d53b0c7 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -49,6 +49,7 @@ Network Interface Controller Drivers
 nfp
 szedata2
 virtio
+vhost
 vmxnet3
 pcap_ring

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 2d4f014..40ca5ec 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -74,20 +74,21 @@ Most of these differences are summarized below.

 .. table:: Features availability in networking drivers

-    = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = =
-   Feature  a b b b c e e i i i i i i i i i i f f m m m n n p r s 
v v v x
-f n n o x 1 n 4 4 4 4 g g x x x x m m l l p f u c i z 
i i m e
-p x x n g 0 i 0 0 0 0 b b g g g g 1 1 x x i p l a n e 
r r x n
-a 2 2 d b 0 c e e e e   v b b b b 0 0 4 5 p   l p g d 
t t n v
-c x x i e 0 . v v   f e e e e k k e a 
i i e i
-k   v n . f f   . v v   .   t 
o o t r
-e   f g .   .   . f f   .   a  
 . 3 t
-t   v   v   v   v   v   2  
 v
-e   e   e   e   e  
 e
-c   c   c   c   c  
 c
-    = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = =
-   link status  X X X   X
-   link status event  X X
+    = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = = =
+   Feature  a b b b c e e i i 

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

2016-03-21 Thread Tetsuya Mukawa
This patch adds a below event type.
 - RTE_ETH_EVENT_QUEUE_STATE_CHANGE

This event will be occured when some queues are enabled or disabled.
So far, only vhost PMD supports the event, and it indicates some queues
are enabled or disabled by virtio-net device. Such an event is needed
because virtio-net device may not enable all queues vhost PMD prepare.

Because only vhost PMD uses the event so far, it isn't an actual hardware
interrupt but a simple software event.

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

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index b5704e1..470d7a5 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2917,6 +2917,8 @@ rte_eth_tx_buffer_count_callback(struct rte_mbuf **pkts, 
uint16_t unsent,
 enum rte_eth_event_type {
RTE_ETH_EVENT_UNKNOWN,  /**< unknown event type */
RTE_ETH_EVENT_INTR_LSC, /**< lsc interrupt event */
+   RTE_ETH_EVENT_QUEUE_STATE_CHANGE,
+   /**< queue state changed interrupt */
RTE_ETH_EVENT_MAX   /**< max value of this enum */
 };

-- 
2.1.4



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

2016-03-21 Thread Tetsuya Mukawa
The patch introduces a new PMD. This PMD is implemented as thin wrapper
of librte_vhost.

PATCH v13 changes:
 - Rebase on latest master.
 - Fix commit log of below patch.
   - ethdev: Add a new event type to notify a queue state changed event
 - Fix warnings from checkpatch.pl.
 - Add description to doc/guides/nics/overview.rst.

PATCH v12 changes:
 - Rebase on latest master.
 - Add a missing documentation.

PATCH v11 changes:
 - Rebase on latest master.
 - Fix MAINTAINERS file.
 - Fix Acked-by and Tested-by signatures of commit log.

PATCH v10 changes:
 - Rebase on latest master.
 - Fix DPDK version number(2.3 to 16.04)
 - Set port id to mbuf while receiving packets.

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

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

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

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

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

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

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

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

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

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

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


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

 MAINTAINERS |   5 +
 config/common_base  |   6 +
 config/common_linuxapp  |   1 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/overview.rst|  37 +-
 doc/guides/nics/vhost.rst   | 110 
 doc/guides/rel_notes/release_16_04.rst  |   4 +
 drivers/net/Makefile|   4 +
 drivers/net/vhost/Makefile  |  62 ++
 drivers/net/vhost/rte_eth_vhost.c   | 917 
 drivers/net/vhost/rte_eth_vhost.h   | 109 
 drivers/net/vhost/rte_pmd_vhost_version.map |  10 +
 lib/librte_ether/rte_ethdev.h   |   2 +
 mk/rte.app.mk   |   6 +
 14 files changed, 1256 insertions(+), 18 deletions(-)
 create mode 100644 doc/guides/nics/vhost.rst
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

-- 
2.1.4



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

2016-03-21 Thread Tetsuya Mukawa
On 2016/03/18 21:27, Bruce Richardson wrote:
> On Tue, Mar 15, 2016 at 05:31:41PM +0900, Tetsuya Mukawa wrote:
>> The patch introduces a new PMD. This PMD is implemented as thin wrapper
>> of librte_vhost. It means librte_vhost is also needed to compile the PMD.
>> The vhost messages will be handled only when a port is started. So start
>> a port first, then invoke QEMU.
>>
>> The PMD has 2 parameters.
>>  - iface:  The parameter is used to specify a path to connect to a
>>virtio-net device.
>>  - queues: The parameter is used to specify the number of the queues
>>virtio-net device has.
>>(Default: 1)
>>
>> Here is an example.
>> $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i
>>
>> To connect above testpmd, here is qemu command example.
>>
>> $ qemu-system-x86_64 \
>> 
>> -chardev socket,id=chr0,path=/tmp/sock0 \
>> -netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
>> -device virtio-net-pci,netdev=net0,mq=on
>>
>> Signed-off-by: Tetsuya Mukawa 
>> Acked-by: Ferruh Yigit 
>> Acked-by: Yuanhan Liu 
>> Acked-by: Rich Lane 
>> Tested-by: Rich Lane 
> Hi Tetsuya,
>
> I hope to get this set merged for RC2 very soon. Can you provide an update for
> the nic overview.rst doc listing out the features of this new PMD. If you 
> want,
> you can provide it as a separate patch, that I will merge into this one for 
> you
> on apply to next-net.
>
> If you do decide to respin this patchset with the extra doc, please take into
> account the following patchwork issues also - otherwise I'll also fix them on
> apply:
>
> WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should probably be 
> static const char * const
> #364: FILE: drivers/net/vhost/rte_eth_vhost.c:56:
> +static const char *valid_arguments[] = {

It seems this is false positive. So I will leave it.

Regards,
Tetsuya



[dpdk-dev] build error with default configuration

2016-03-21 Thread Thomas Monjalon
2016-03-21 12:09, Iremonger, Bernard:
> make config T=x86_64-default-linuxapp-gcc
> make install T=x86_64-default-linuxapp-gcc -j


make config T=x86_64-native-linuxapp-gcc
sed -i s,native,default, build/.config
make -j

> In file included from 
> /root/dpdk_sforge_2/lib/librte_table/rte_table_lpm.c:43:0:
> /root/dpdk_sforge_2/x86_64-default-linuxapp-gcc/include/rte_lpm.h:484:25: 
> fatal error: rte_lpm_sse.h: No such file or directory
> #include "rte_lpm_sse.h"

It works on my machine.


[dpdk-dev] [PATCH 0/5] lpm allocation fixes - v3

2016-03-21 Thread Olivier Matz


On 03/16/2016 03:16 PM, Christian Ehrhardt wrote:
> Poking a bit on autotest revealed a few shortcomings in the lpm allocation 
> path.
> Thanks to the feedback to the first revision of the patches here v2.
> Also Oliver Matz spotted similar issues and made me aware - thanks!
> Integrating them revealed even more use after free / leak issues.
> 
> *updates in v3*
> - lpm create/free path for v20 and v1604 got the same fixes that were
>   already identified for lpm6 before
> 
> *updates in v2*
> - lpm/lpm6 patches split
> - following dpdk coding guidelines regarding single line if's
> - adding singed-off and acked-bys gathered so far
> - combine all three related patches in one series
> 
> [PATCH 1/5] lpm6: fix use after free of lpm in rte_lpm6_create
> [PATCH 2/5] lpm6: fix missing free of rules_tbl and lpm
> [PATCH 3/5] lpm: fix missing free of lpm
> [PATCH 4/5] lpm: fix use after free of lpm in rte_lpm_create*
> [PATCH 5/5] lpm: fix missing free of rules_tbl and lpm in
> 
> diffstat:
>  rte_lpm.c  |   23 ++-
>  rte_lpm6.c |   12 ++--
>  2 files changed, 16 insertions(+), 19 deletions(-)
> 

Series
Acked-by: Olivier Matz 

Just one small comment: there are additional { } in patches
2/5 and 3/5.

Thomas, do you think you can remove it while pushing?




[dpdk-dev] [PATCH v5 9/9] testpmd: extend flow director commands

2016-03-21 Thread Jingjing Wu
This patch extended commands for filter's input set changing.
It added vlan as filter's input fields.

Signed-off-by: Jingjing Wu 
---
 app/test-pmd/cmdline.c  | 6 +++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6d1b9f0..aa7ecfb 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -774,7 +774,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"set_fdir_input_set (port_id) "
"(ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
"ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|"
-   "l2_payload) (ethertype|src-ipv4|dst-ipv4|src-ipv6|"
+   "l2_payload) 
(ivlan|ethertype|src-ipv4|dst-ipv4|src-ipv6|"
"dst-ipv6|ipv4-tos|ipv4-proto|ipv4-ttl|ipv6-tc|"
"ipv6-next-header|ipv6-hop-limits|udp-src-port|"
"udp-dst-port|tcp-src-port|tcp-dst-port|"
@@ -9651,7 +9651,7 @@ cmdline_parse_token_string_t 
cmd_set_fdir_input_set_flow_type =
 cmdline_parse_token_string_t cmd_set_fdir_input_set_field =
TOKEN_STRING_INITIALIZER(struct cmd_set_fdir_input_set_result,
inset_field,
-   "ethertype#src-ipv4#dst-ipv4#src-ipv6#dst-ipv6#"
+   "ivlan#ethertype#src-ipv4#dst-ipv4#src-ipv6#dst-ipv6#"
"ipv4-tos#ipv4-proto#ipv4-ttl#ipv6-tc#ipv6-next-header#"
"ipv6-hop-limits#udp-src-port#udp-dst-port#"
"tcp-src-port#tcp-dst-port#sctp-src-port#sctp-dst-port#"
@@ -9666,7 +9666,7 @@ cmdline_parse_inst_t cmd_set_fdir_input_set = {
.help_str = "set_fdir_input_set  "
"ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
"ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|l2_payload "
-   "ethertype|src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|"
+   "ivlan|ethertype|src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|"
"ipv4-tos|ipv4-proto|ipv4-ttl|ipv6-tc|ipv6-next-header|"
"ipv6-hop-limits|udp-src-port|udp-dst-port|"
"tcp-src-port|tcp-dst-port|sctp-src-port|sctp-dst-port|"
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 52a4f11..94fba6a 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1929,7 +1929,7 @@ Set the input set for flow director::

set_fdir_input_set (port_id) (ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp| \
ipv4-other|ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other| \
-   l2_payload) (ethertype|src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|ipv4-tos| \
+   l2_payload) (ivlan|ethertype|src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|ipv4-tos| \
ipv4-proto|ipv4-ttl|ipv6-tc|ipv6-next-header|ipv6-hop-limits| \
tudp-src-port|udp-dst-port|cp-src-port|tcp-dst-port|sctp-src-port| \
sctp-dst-port|sctp-veri-tag|none) (select|add)
-- 
2.4.0



[dpdk-dev] [PATCH v5 8/9] i40e: extend flow director to filter by vlan id

2016-03-21 Thread Jingjing Wu
This patch extended flow director to select vlan id
as filter's input set and program the filter rule with vlan id.

Signed-off-by: Jingjing Wu 
---
 doc/guides/rel_notes/release_16_04.rst |  2 +
 drivers/net/i40e/i40e_ethdev.c | 11 ++
 drivers/net/i40e/i40e_fdir.c   | 69 +-
 3 files changed, 55 insertions(+), 27 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 5803684..0ff4e2c 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -172,6 +172,8 @@ This section should contain new features added in this 
release. Sample format:

 * **Added i40e VEB switching support.**

+* **Added Flow director enhancements in i40e.**
+
 * **Added fm10k Rx interrupt support.**

 * **Optimized fm10k Tx.**
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ff034e7..a475ad1 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6769,48 +6769,59 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
 */
static const uint64_t valid_fdir_inset_table[] = {
[I40E_FILTER_PCTYPE_FRAG_IPV4] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_FRAG_IPV6] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_NEXT_HDR |
I40E_INSET_IPV6_HOP_LIMIT,
[I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_NEXT_HDR |
I40E_INSET_IPV6_HOP_LIMIT,
[I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_LAST_ETHER_TYPE,
};

diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c
index ebbe612..f15a080 100644
--- a/drivers/net/i40e/i40e_fdir.c
+++ b/drivers/net/i40e/i40e_fdir.c
@@ -687,11 +687,14 @@ i40e_fdir_configure(struct rte_eth_dev *dev)
return ret;
 }

-static inline void
+static inline int
 i40e_fdir_fill_eth_ip_head(const struct rte_eth_fdir_input *fdir_input,
-  unsigned char *raw_pkt)
+  unsigned char *raw_pkt,
+  bool vlan)
 {
-   struct ether_hdr *ether = (struct ether_hdr *)raw_pkt;
+   static uint8_t vlan_frame[] = {0x81, 0, 0, 0};
+   

[dpdk-dev] [PATCH v5 7/9] i40e: fix VLAN bitmasks for input set

2016-03-21 Thread Jingjing Wu
From: Andrey Chilikin 

This patch adds missing VLAN bitmask for inner frame in case of
tunneling and fixes VLAN tags bitmasks for single or outer frame
in case of tunneling.

Fixes: 98f055707685 ("i40e: configure input fields for RSS or flow director")

Signed-off-by: Andrey Chilikin 
Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 462d0d3..ff034e7 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -198,10 +198,12 @@
 #define I40E_REG_INSET_L2_DMAC   0xE000ULL
 /* Source MAC address */
 #define I40E_REG_INSET_L2_SMAC   0x1C00ULL
-/* VLAN tag in the outer L2 header */
-#define I40E_REG_INSET_L2_OUTER_VLAN 0x0080ULL
-/* VLAN tag in the inner L2 header */
-#define I40E_REG_INSET_L2_INNER_VLAN 0x0100ULL
+/* Outer (S-Tag) VLAN tag in the outer L2 header */
+#define I40E_REG_INSET_L2_OUTER_VLAN 0x0200ULL
+/* Inner (C-Tag) or single VLAN tag in the outer L2 header */
+#define I40E_REG_INSET_L2_INNER_VLAN 0x0080ULL
+/* Single VLAN tag in the inner L2 header */
+#define I40E_REG_INSET_TUNNEL_VLAN   0x0100ULL
 /* Source IPv4 address */
 #define I40E_REG_INSET_L3_SRC_IP40x00018000ULL
 /* Destination IPv4 address */
@@ -7019,7 +7021,7 @@ i40e_translate_input_set_reg(uint64_t input)
I40E_REG_INSET_TUNNEL_L4_UDP_SRC_PORT},
{I40E_INSET_TUNNEL_DST_PORT,
I40E_REG_INSET_TUNNEL_L4_UDP_DST_PORT},
-   {I40E_INSET_TUNNEL_ID, I40E_REG_INSET_TUNNEL_ID},
+   {I40E_INSET_VLAN_TUNNEL, I40E_REG_INSET_TUNNEL_VLAN},
{I40E_INSET_FLEX_PAYLOAD_W1, I40E_REG_INSET_FLEX_PAYLOAD_WORD1},
{I40E_INSET_FLEX_PAYLOAD_W2, I40E_REG_INSET_FLEX_PAYLOAD_WORD2},
{I40E_INSET_FLEX_PAYLOAD_W3, I40E_REG_INSET_FLEX_PAYLOAD_WORD3},
-- 
2.4.0



[dpdk-dev] [PATCH v5 6/9] testpmd: extend input set related commands

2016-03-21 Thread Jingjing Wu
This patch extended commands for filter's input set changing.
It added tos, protocol and ttl as filter's input fields, and
remove the words selection from flex payloads for flow director.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 app/test-pmd/cmdline.c  | 100 ++--
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  42 +++-
 2 files changed, 104 insertions(+), 38 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 9d52b8c..6d1b9f0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -669,6 +669,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"flow_director_filter (port_id) mode IP 
(add|del|update)"
" flow (ipv4-other|ipv4-frag|ipv6-other|ipv6-frag)"
" src (src_ip_address) dst (dst_ip_address)"
+   " tos (tos_value) proto (proto_value) ttl (ttl_value)"
" vlan (vlan_value) flexbytes (flexbytes_value)"
" (drop|fwd) pf|vf(vf_id) queue (queue_id)"
" fd_id (fd_id_value)\n"
@@ -678,6 +679,7 @@ static void cmd_help_long_parsed(void *parsed_result,
" flow (ipv4-tcp|ipv4-udp|ipv6-tcp|ipv6-udp)"
" src (src_ip_address) (src_port)"
" dst (dst_ip_address) (dst_port)"
+   " tos (tos_value) ttl (ttl_value)"
" vlan (vlan_value) flexbytes (flexbytes_value)"
" (drop|fwd) pf|vf(vf_id) queue (queue_id)"
" fd_id (fd_id_value)\n"
@@ -687,7 +689,9 @@ static void cmd_help_long_parsed(void *parsed_result,
" flow (ipv4-sctp|ipv6-sctp)"
" src (src_ip_address) (src_port)"
" dst (dst_ip_address) (dst_port)"
-   " tag (verification_tag) vlan (vlan_value)"
+   " tag (verification_tag) "
+   " tos (tos_value) ttl (ttl_value)"
+   " vlan (vlan_value)"
" flexbytes (flexbytes_value) (drop|fwd)"
" pf|vf(vf_id) queue (queue_id) fd_id (fd_id_value)\n"
"Add/Del a SCTP type flow director filter.\n\n"
@@ -767,14 +771,15 @@ static void cmd_help_long_parsed(void *parsed_result,
"fld-8th|none) (select|add)\n"
"Set the input set for hash.\n\n"

-   "set_fdir_input_set (port_id) (ipv4|ipv4-frag|"
-   "ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|ipv6|"
+   "set_fdir_input_set (port_id) "
+   "(ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
"ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|"
-   "l2_payload) (src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|"
-   "udp-src-port|udp-dst-port|tcp-src-port|tcp-dst-port|"
-   "sctp-src-port|sctp-dst-port|sctp-veri-tag|fld-1st|"
-   "fld-2nd|fld-3rd|fld-4th|fld-5th|fld-6th|fld-7th|"
-   "fld-8th|none) (select|add)\n"
+   "l2_payload) (ethertype|src-ipv4|dst-ipv4|src-ipv6|"
+   "dst-ipv6|ipv4-tos|ipv4-proto|ipv4-ttl|ipv6-tc|"
+   "ipv6-next-header|ipv6-hop-limits|udp-src-port|"
+   "udp-dst-port|tcp-src-port|tcp-dst-port|"
+   "sctp-src-port|sctp-dst-port|sctp-veri-tag|none)"
+   " (select|add)\n"
"Set the input set for FDir.\n\n"
);
}
@@ -8027,6 +8032,12 @@ struct cmd_flow_director_result {
uint16_t port_dst;
cmdline_fixed_string_t verify_tag;
uint32_t verify_tag_value;
+   cmdline_ipaddr_t tos;
+   uint8_t tos_value;
+   cmdline_ipaddr_t proto;
+   uint8_t proto_value;
+   cmdline_ipaddr_t ttl;
+   uint8_t ttl_value;
cmdline_fixed_string_t vlan;
uint16_t vlan_value;
cmdline_fixed_string_t flexbytes;
@@ -8206,12 +8217,15 @@ cmd_flow_director_filter_parsed(void *parsed_result,
switch (entry.input.flow_type) {
case RTE_ETH_FLOW_FRAG_IPV4:
case RTE_ETH_FLOW_NONFRAG_IPV4_OTHER:
+   entry.input.flow.ip4_flow.proto = res->proto_value;
case RTE_ETH_FLOW_NONFRAG_IPV4_UDP:
case RTE_ETH_FLOW_NONFRAG_IPV4_TCP:
IPV4_ADDR_TO_UINT(res->ip_dst,
entry.input.flow.ip4_flow.dst_ip);
IPV4_ADDR_TO_UINT(res->ip_src,
entry.input.flow.ip4_flow.src_ip);
+   entry.input.flow.ip4_flow.tos = res->tos_value;
+   entry.input.flow.ip4_flow.ttl = res->ttl_value;
/* need convert to big endian. */

[dpdk-dev] [PATCH v5 5/9] i40e: extend flow director to filter by IP Header

2016-03-21 Thread Jingjing Wu
This patch extended flow director to select more IP Header fields
as filter input set.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 69 ++
 drivers/net/i40e/i40e_fdir.c   | 26 +++-
 2 files changed, 75 insertions(+), 20 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 4cd9853..462d0d3 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -210,6 +210,8 @@
 #define I40E_REG_INSET_L3_IP4_TOS0x0040ULL
 /* IPv4 Protocol */
 #define I40E_REG_INSET_L3_IP4_PROTO  0x0004ULL
+/* IPv4 Time to Live */
+#define I40E_REG_INSET_L3_IP4_TTL0x0004ULL
 /* Source IPv6 address */
 #define I40E_REG_INSET_L3_SRC_IP60x0007F800ULL
 /* Destination IPv6 address */
@@ -218,6 +220,8 @@
 #define I40E_REG_INSET_L3_IP6_TC 0x0040ULL
 /* IPv6 Next Header */
 #define I40E_REG_INSET_L3_IP6_NEXT_HDR   0x0008ULL
+/* IPv6 Hop Limit */
+#define I40E_REG_INSET_L3_IP6_HOP_LIMIT  0x0008ULL
 /* Source L4 port */
 #define I40E_REG_INSET_L4_SRC_PORT   0x0004ULL
 /* Destination L4 port */
@@ -261,10 +265,12 @@
 #define I40E_TRANSLATE_INSET 0
 #define I40E_TRANSLATE_REG   1

-#define I40E_INSET_IPV4_TOS_MASK  0x0009FF00UL
-#define I40E_INSET_IPV4_PROTO_MASK0x000DFF00UL
-#define I40E_INSET_IPV6_TC_MASK   0x0009F00FUL
-#define I40E_INSET_IPV6_NEXT_HDR_MASK 0x000C00FFUL
+#define I40E_INSET_IPV4_TOS_MASK0x0009FF00UL
+#define I40E_INSET_IPv4_TTL_MASK0x000D00FFUL
+#define I40E_INSET_IPV4_PROTO_MASK  0x000DFF00UL
+#define I40E_INSET_IPV6_TC_MASK 0x0009F00FUL
+#define I40E_INSET_IPV6_HOP_LIMIT_MASK  0x000CFF00UL
+#define I40E_INSET_IPV6_NEXT_HDR_MASK   0x000C00FFUL

 #define I40E_GL_SWT_L2TAGCTRL(_i) (0x001C0A70 + ((_i) * 4))
 #define I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_SHIFT 16
@@ -6761,30 +6767,47 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
 */
static const uint64_t valid_fdir_inset_table[] = {
[I40E_FILTER_PCTYPE_FRAG_IPV4] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
+   I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
+   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
+   I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_FRAG_IPV6] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_NEXT_HDR |
+   I40E_INSET_IPV6_HOP_LIMIT,
[I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
+   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
+   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_NEXT_HDR |
+   I40E_INSET_IPV6_HOP_LIMIT,

[dpdk-dev] [PATCH v5 4/9] i40e: restore default setting on input set

2016-03-21 Thread Jingjing Wu
This patch added a new function to set the input set to default
when initialization.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 57 ++
 1 file changed, 57 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 158910b..4cd9853 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -384,6 +384,7 @@ static int i40e_dev_udp_tunnel_port_add(struct rte_eth_dev 
*dev,
struct rte_eth_udp_tunnel *udp_tunnel);
 static int i40e_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
struct rte_eth_udp_tunnel *udp_tunnel);
+static void i40e_filter_input_set_init(struct i40e_pf *pf);
 static int i40e_ethertype_filter_set(struct i40e_pf *pf,
struct rte_eth_ethertype_filter *filter,
bool add);
@@ -816,6 +817,9 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 */
i40e_flex_payload_reg_init(hw);

+   /* Initialize the input set for filters (hash and fd) to default value 
*/
+   i40e_filter_input_set_init(pf);
+
/* Initialize the parameters for adminq */
i40e_init_adminq_parameter(hw);
ret = i40e_init_adminq(hw);
@@ -7055,6 +7059,59 @@ i40e_check_write_reg(struct i40e_hw *hw, uint32_t addr, 
uint32_t val)
(uint32_t)i40e_read_rx_ctl(hw, addr));
 }

+static void
+i40e_filter_input_set_init(struct i40e_pf *pf)
+{
+   struct i40e_hw *hw = I40E_PF_TO_HW(pf);
+   enum i40e_filter_pctype pctype;
+   uint64_t input_set, inset_reg;
+   uint32_t mask_reg[I40E_INSET_MASK_NUM_REG] = {0};
+   int num, i;
+
+   for (pctype = I40E_FILTER_PCTYPE_NONF_IPV4_UDP;
+pctype <= I40E_FILTER_PCTYPE_L2_PAYLOAD; pctype++) {
+   if (!I40E_VALID_PCTYPE(pctype))
+   continue;
+   input_set = i40e_get_default_input_set(pctype);
+
+   num = i40e_generate_inset_mask_reg(input_set, mask_reg,
+  I40E_INSET_MASK_NUM_REG);
+   if (num < 0)
+   return;
+   inset_reg = i40e_translate_input_set_reg(input_set);
+
+   i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
+ (uint32_t)(inset_reg & UINT32_MAX));
+   i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 1),
+(uint32_t)((inset_reg >>
+I40E_32_BIT_WIDTH) & UINT32_MAX));
+   i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(0, pctype),
+ (uint32_t)(inset_reg & UINT32_MAX));
+   i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(1, pctype),
+(uint32_t)((inset_reg >>
+I40E_32_BIT_WIDTH) & UINT32_MAX));
+
+   for (i = 0; i < num; i++) {
+   i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+mask_reg[i]);
+   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+mask_reg[i]);
+   }
+   /*clear unused mask registers of the pctype */
+   for (i = num; i < I40E_INSET_MASK_NUM_REG; i++) {
+   i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+0);
+   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+0);
+   }
+   I40E_WRITE_FLUSH(hw);
+
+   /* store the default input set */
+   pf->hash_input_set[pctype] = input_set;
+   pf->fdir.input_set[pctype] = input_set;
+   }
+}
+
 int
 i40e_hash_filter_inset_select(struct i40e_hw *hw,
 struct rte_eth_input_set_conf *conf)
-- 
2.4.0



[dpdk-dev] [PATCH v5 3/9] i40e: remove flex payload from input selection

2016-03-21 Thread Jingjing Wu
In this patch, flex payload is removed from valid fdir input set
values. It is because all flex payload configuration can be set
in struct rte_fdir_conf during device configure phase.
And it is a more flexible configuration including flexpayload's
selection, input set selection by word and mask setting in bits.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 59 +++---
 1 file changed, 26 insertions(+), 33 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index faceb8b..158910b 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -254,7 +254,8 @@
 #define I40E_REG_INSET_FLEX_PAYLOAD_WORD70x0080ULL
 /* 8th word of flex payload */
 #define I40E_REG_INSET_FLEX_PAYLOAD_WORD80x0040ULL
-
+/* all 8 words flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORDS0x3FC0ULL
 #define I40E_REG_INSET_MASK_DEFAULT  0xULL

 #define I40E_TRANSLATE_INSET 0
@@ -6756,43 +6757,32 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
 */
static const uint64_t valid_fdir_inset_table[] = {
[I40E_FILTER_PCTYPE_FRAG_IPV4] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
-   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
-   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
[I40E_FILTER_PCTYPE_FRAG_IPV6] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
[I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
-   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
-   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
[I40E_FILTER_PCTYPE_L2_PAYLOAD] =
-   I40E_INSET_LAST_ETHER_TYPE | I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_LAST_ETHER_TYPE,
};

if (pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD)
@@ -7020,7 +7010,7 @@ i40e_translate_input_set_reg(uint64_t input)
return val;
 }

-static uint8_t
+static int
 i40e_generate_inset_mask_reg(uint64_t inset, uint32_t *mask, uint8_t nb_elem)
 {
uint8_t i, idx = 0;
@@ -7038,16 +7028,13 @@ i40e_generate_inset_mask_reg(uint64_t inset, uint32_t 
*mask, uint8_t nb_elem)
if (!inset || !mask || !nb_elem)
return 0;

-   if (!inset && nb_elem >= I40E_INSET_MASK_NUM_REG) {
-   for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++)
-   mask[i] = 0;
-   return I40E_INSET_MASK_NUM_REG;
-   }

for (i = 0, idx = 0; i < RTE_DIM(inset_mask_map); i++) {
-   if (idx >= nb_elem)
-   break;
-   if (inset & inset_mask_map[i].inset) {
+   if ((inset & inset_mask_map[i].inset) == 
inset_mask_map[i].inset) {
+   if (idx >= nb_elem) {
+   PMD_DRV_LOG(ERR, "exceed maximal number of 
bitmasks");
+ 

[dpdk-dev] [PATCH v5 2/9] i40e: split function for hash and fdir input

2016-03-21 Thread Jingjing Wu
This patch split function for input set changing of hash
and fdir to avoid multiple check on different situation.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 235 +
 drivers/net/i40e/i40e_ethdev.h |  11 +-
 drivers/net/i40e/i40e_fdir.c   |   5 +-
 3 files changed, 107 insertions(+), 144 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 10e0d38..faceb8b 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -7056,25 +7056,6 @@ i40e_generate_inset_mask_reg(uint64_t inset, uint32_t 
*mask, uint8_t nb_elem)
return idx;
 }

-static uint64_t
-i40e_get_reg_inset(struct i40e_hw *hw, enum rte_filter_type filter,
-   enum i40e_filter_pctype pctype)
-{
-   uint64_t reg = 0;
-
-   if (filter == RTE_ETH_FILTER_HASH) {
-   reg = i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(1, pctype));
-   reg <<= I40E_32_BIT_WIDTH;
-   reg |= i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(0, pctype));
-   } else if (filter == RTE_ETH_FILTER_FDIR) {
-   reg = i40e_read_rx_ctl(hw, I40E_PRTQF_FD_INSET(pctype, 1));
-   reg <<= I40E_32_BIT_WIDTH;
-   reg |= i40e_read_rx_ctl(hw, I40E_PRTQF_FD_INSET(pctype, 0));
-   }
-
-   return reg;
-}
-
 static void
 i40e_check_write_reg(struct i40e_hw *hw, uint32_t addr, uint32_t val)
 {
@@ -7087,105 +7068,96 @@ i40e_check_write_reg(struct i40e_hw *hw, uint32_t 
addr, uint32_t val)
(uint32_t)i40e_read_rx_ctl(hw, addr));
 }

-static int
-i40e_set_hash_inset_mask(struct i40e_hw *hw,
-enum i40e_filter_pctype pctype,
-enum rte_filter_input_set_op op,
-uint32_t *mask_reg,
-uint8_t num)
+int
+i40e_hash_filter_inset_select(struct i40e_hw *hw,
+struct rte_eth_input_set_conf *conf)
 {
-   uint32_t reg;
-   uint8_t i;
+   struct i40e_pf *pf = &((struct i40e_adapter *)hw->back)->pf;
+   enum i40e_filter_pctype pctype;
+   uint64_t input_set, inset_reg = 0;
+   uint32_t mask_reg[I40E_INSET_MASK_NUM_REG] = {0};
+   int ret, i, num;

-   if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+   if (!conf) {
+   PMD_DRV_LOG(ERR, "Invalid pointer");
+   return -EFAULT;
+   }
+   if (conf->op != RTE_ETH_INPUT_SET_SELECT &&
+   conf->op != RTE_ETH_INPUT_SET_ADD) {
+   PMD_DRV_LOG(ERR, "Unsupported input set operation");
return -EINVAL;
-
-   if (op == RTE_ETH_INPUT_SET_SELECT) {
-   for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
-   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
-0);
-   if (i >= num)
-   continue;
-   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
-mask_reg[i]);
-   }
-   } else if (op == RTE_ETH_INPUT_SET_ADD) {
-   uint8_t j, count = 0;
-
-   for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
-   reg = i40e_read_rx_ctl(hw,
-  I40E_GLQF_HASH_MSK(i, pctype));
-   if (reg & I40E_GLQF_HASH_MSK_MASK_MASK)
-   count++;
-   }
-   if (count + num > I40E_INSET_MASK_NUM_REG)
-   return -EINVAL;
-
-   for (i = count, j = 0; i < I40E_INSET_MASK_NUM_REG; i++, j++)
-   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
-mask_reg[j]);
}

-   return 0;
-}
-
-static int
-i40e_set_fd_inset_mask(struct i40e_hw *hw,
-  enum i40e_filter_pctype pctype,
-  enum rte_filter_input_set_op op,
-  uint32_t *mask_reg,
-  uint8_t num)
-{
-   uint32_t reg;
-   uint8_t i;
+   pctype = i40e_flowtype_to_pctype(conf->flow_type);
+   if (pctype == 0 || pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD) {
+   PMD_DRV_LOG(ERR, "Not supported flow type (%u)",
+   conf->flow_type);
+   return -EINVAL;
+   }

-   if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+   ret = i40e_parse_input_set(_set, pctype, conf->field,
+  conf->inset_size);
+   if (ret) {
+   PMD_DRV_LOG(ERR, "Failed to parse input set");
+   return -EINVAL;
+   }
+   if (i40e_validate_input_set(pctype, RTE_ETH_FILTER_HASH,
+   input_set) != 0) {
+   PMD_DRV_LOG(ERR, "Invalid input set");
+   return -EINVAL;
+   }
+ 

[dpdk-dev] [PATCH v5 1/9] ethdev: extend flow director for input selection

2016-03-21 Thread Jingjing Wu
This patch added RTE_ETH_INPUT_SET_L3_IP4_TTL,
RTE_ETH_INPUT_SET_L3_IP6_HOP_LIMITS input field type and extended
struct rte_eth_ipv4_flow and rte_eth_ipv6_flow to support filtering
by tos, protocol and ttl.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 doc/guides/rel_notes/deprecation.rst   | 4 
 doc/guides/rel_notes/release_16_04.rst | 2 ++
 lib/librte_ether/rte_eth_ctrl.h| 8 
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 252a096..e7a7c7f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -22,10 +22,6 @@ Deprecation Notices
 * The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
   must be updated to support 100G link and to have a cleaner link speed API.

-* ABI changes are planned for struct rte_eth_fdir_flow in order to support
-  extend flow director's input set. The release 2.2 does not contain these ABI
-  changes, but release 2.3 will, and no backwards compatibility is planned.
-
 * ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow to
   include more fields to be matched against. The release 2.2 does not
   contain these ABI changes, but release 2.3 will.
diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 2785b29..5803684 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -435,6 +435,8 @@ ABI Changes

 * The cmdline buffer size has been increase from 256 to 512.

+* The ethdev flow director structure ``rte_eth_fdir_flow`` structure was
+  changed. New fields were added to extend flow director's input set.

 Shared Library Versions
 ---
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 6e2f617..aabd724 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -343,6 +343,8 @@ enum rte_eth_input_set_field {
RTE_ETH_INPUT_SET_L3_IP4_PROTO,
RTE_ETH_INPUT_SET_L3_IP6_TC,
RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER,
+   RTE_ETH_INPUT_SET_L3_IP4_TTL,
+   RTE_ETH_INPUT_SET_L3_IP6_HOP_LIMITS,

/* L4 */
RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT = 257,
@@ -410,6 +412,9 @@ struct rte_eth_l2_flow {
 struct rte_eth_ipv4_flow {
uint32_t src_ip;  /**< IPv4 source address to match. */
uint32_t dst_ip;  /**< IPv4 destination address to match. */
+   uint8_t  tos; /**< Type of service to match. */
+   uint8_t  ttl; /**< Time to live to match. */
+   uint8_t  proto;   /**< Protocol, next header to match. */
 };

 /**
@@ -446,6 +451,9 @@ struct rte_eth_sctpv4_flow {
 struct rte_eth_ipv6_flow {
uint32_t src_ip[4];  /**< IPv6 source address to match. */
uint32_t dst_ip[4];  /**< IPv6 destination address to match. */
+   uint8_t  tc; /**< Traffic class to match. */
+   uint8_t  proto;  /**< Protocol, next header to match. */
+   uint8_t  hop_limits; /**< Hop limits to match. */
 };

 /**
-- 
2.4.0



[dpdk-dev] [PATCH v5 0/9] extend flow director fields in i40e driver

2016-03-21 Thread Jingjing Wu
v5 changes:
 - remove the reorganizing of struct rte_eth_fdir_flow
 - remove fdir supporting on Tunnel Id
 - rebase to latest dpdk/master

v4 changes:
 - rebase to latest dpdk-next-net/rel_16_04.
 - comments on new fields in API structure.

v3 changes:
 - rebase to latest dpdk-next-net/rel_16_04(commit: 0f9564a0e4f2)
 - use AQ rx control register read/write for some registers
 - remove few useless lines
 - patch title rewording

v2 changes:
 - rebase on dpdk-next-net/rel_16_04
 - comments rewording.
 - redefine the value of RTE_ETH_INPUT_SET_L3_IP4_TTL to
   avoid ABI breaking.
 - remove ABI announce in Deprecation.
 - fix the ethertype setting when program filter in v1 patch set.

This patch set extends flow director to support filtering by
additional fields below in i40e driver:
 - TOS, Protocol and TTL in IP header
 - single vlan or inner vlan 




Andrey Chilikin (1):
  i40e: fix VLAN bitmasks for input set

Jingjing Wu (8):
  ethdev: extend flow director for input selection
  i40e: split function for hash and fdir input
  i40e: remove flex payload from input selection
  i40e: restore default setting on input set
  i40e: extend flow director to filter by IP Header
  testpmd: extend input set related commands
  i40e: extend flow director to filter by vlan id
  testpmd: extend flow director commands

 app/test-pmd/cmdline.c  | 100 +--
 doc/guides/rel_notes/deprecation.rst|   4 -
 doc/guides/rel_notes/release_16_04.rst  |   4 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  42 +--
 drivers/net/i40e/i40e_ethdev.c  | 393 
 drivers/net/i40e/i40e_ethdev.h  |  11 +-
 drivers/net/i40e/i40e_fdir.c| 100 ---
 lib/librte_ether/rte_eth_ctrl.h |   8 +
 8 files changed, 416 insertions(+), 246 deletions(-)

-- 
2.4.0



[dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of compiler ones.

2016-03-21 Thread Ananyev, Konstantin


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ilya Maximets
> Sent: Monday, March 21, 2016 4:50 AM
> To: Yuanhan Liu
> Cc: dev at dpdk.org; Xie, Huawei; Dyasly Sergey
> Subject: Re: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of 
> compiler ones.
> 
> 
> 
> On 18.03.2016 15:41, Yuanhan Liu wrote:
> > On Fri, Mar 18, 2016 at 03:23:53PM +0300, Ilya Maximets wrote:
> >> Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virtio
> >> uses architecture dependent SMP barriers. vHost should use them too.
> >>
> >> Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers")
> >>
> >> Signed-off-by: Ilya Maximets 
> >> ---
> >>  lib/librte_vhost/vhost_rxtx.c | 7 ---
> >>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
> >> index b4da665..859c669 100644
> >> --- a/lib/librte_vhost/vhost_rxtx.c
> >> +++ b/lib/librte_vhost/vhost_rxtx.c
> >> @@ -315,7 +315,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t 
> >> queue_id,
> >>rte_prefetch0(>desc[desc_indexes[i+1]]);
> >>}
> >>
> >> -  rte_compiler_barrier();
> >> +  rte_smp_wmb();
> >>
> >>/* Wait until it's our turn to add our buffer to the used ring. */
> >>while (unlikely(vq->last_used_idx != res_start_idx))
> >> @@ -565,7 +565,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t 
> >> queue_id,
> >>
> >>nr_used = copy_mbuf_to_desc_mergeable(dev, vq, start, end,
> >>  pkts[pkt_idx]);
> >> -  rte_compiler_barrier();
> >> +  rte_smp_wmb();
> >>
> >>/*
> >> * Wait until it's our turn to add our buffer
> >> @@ -923,7 +923,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, 
> >> uint16_t queue_id,
> >>sizeof(vq->used->ring[used_idx]));
> >>}
> >>
> >> -  rte_compiler_barrier();
> >> +  rte_smp_wmb();
> >> +  rte_smp_rmb();
> >
> > rte_smp_mb?
> 
> rte_smp_mb() is a real mm_fence() on x86. And we don't need to synchronize 
> reads with
> writes here, only reads with reads and writes with writes. It is enough 
> because next
> increment uses read and write. Pair of barriers is better because it will not 
> impact
> on performance on x86.

Not arguing about that particular patch, just a question:
Why do we have:
#define rte_smp_mb() rte_mb()
for  x86?
Why not just:
#define rte_smp_mb() rte_compiler_barrier()
here?
I meant for situations when we do need real mfence, there is an 'rte_mb' to use.
Konstantin

> 
> Best regards, Ilya Maximets.


[dpdk-dev] [PATCH] git: ignore build directory

2016-03-21 Thread Matthew Hall
On Mon, Mar 21, 2016 at 10:56:18AM -0700, Stephen Hemminger wrote:
> The mk environment in DPDK puts files in build/ directory
> so it makes sense to have a .gitignore file to skip that
> directory.

The last time I proposed such a patch it was rejected. It is sad when 
community patches are second class citizens behind core committers' 
patches.

Matthew.


[dpdk-dev] [PATCH] mempool: allow for user-owned mempool caches

2016-03-21 Thread Wiles, Keith
>Hi Lazaros,
>
>Thanks for this patch. To me, this is a valuable enhancement.
>Please find some comments inline.
>
>On 03/10/2016 03:44 PM, Lazaros Koromilas wrote:
>> The mempool cache is only available to EAL threads as a per-lcore
>> resource. Change this so that the user can create and provide their own
>> cache on mempool get and put operations. This works with non-EAL threads
>> too. This commit introduces new API calls with the 'with_cache' suffix,
>> while the current ones default to the per-lcore local cache.
>> 
>> Signed-off-by: Lazaros Koromilas 
>> ---
>>  lib/librte_mempool/rte_mempool.c |  65 +-
>>  lib/librte_mempool/rte_mempool.h | 442 
>> ---
>>  2 files changed, 467 insertions(+), 40 deletions(-)
>> 
>> diff --git a/lib/librte_mempool/rte_mempool.c 
>> b/lib/librte_mempool/rte_mempool.c
>> index f8781e1..cebc2b7 100644
>> --- a/lib/librte_mempool/rte_mempool.c
>> +++ b/lib/librte_mempool/rte_mempool.c
>> @@ -375,6 +375,43 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, 
>> size_t elt_sz,
>>  return usz;
>>  }
>>  
>> +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>
>I wonder if this wouldn't cause a conflict with Keith's patch
>that removes some #ifdefs RTE_MEMPOOL_CACHE_MAX_SIZE.
>See: http://www.dpdk.org/dev/patchwork/patch/10492/

Hi Lazaros,

The patch I submitted keeps the mempool cache structure (pointers and 
variables) and only allocates the cache if specified by the caller to use a 
cache. This means to me the caller could fill in the cache pointer and values 
into the mempool structure to get a cache without a lot of extra code. If we 
added a set of APIs to fill in these structure variables would that not give 
you the external cache support. I have not really looked at the patch to verify 
this will work, but it sure seems like it.

So my suggestion the caller can just create a mempool without a cache and then 
call a set of APIs to fill in his cache values, does that not work?

If we can do this it reduces the API and possible the ABI changes to mempool as 
the new cache create routines and APIs could be in a new file I think, which 
just updates the mempool structure correctly.

>
>As this patch is already acked for 16.07, I think that your v2
>could be rebased on top of it to avoid conflicts when Thomas will apply
>it.
>
>By the way, I also encourage you to have a look at other works in
>progress in mempool:
>http://www.dpdk.org/ml/archives/dev/2016-March/035107.html
>http://www.dpdk.org/ml/archives/dev/2016-March/035201.html
>
>

Regards,
Keith






[dpdk-dev] [PATCH v3 4/4] eal/arm: introduce CONFIG_RTE_ARCH_ARM_NEON_MEMCPY

2016-03-21 Thread Jianbo Liu
On 20 March 2016 at 03:58, Jan Viktorin  wrote:
> The flag is used to enable memcpy optimizations in EAL. As it is not always
> the performance benefit, the flag allows to disable it.
>
> Signed-off-by: Jan Viktorin 
> ---
>  config/defconfig_arm-armv7a-linuxapp-gcc   | 1 +
>  lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 8 ++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
> b/config/defconfig_arm-armv7a-linuxapp-gcc
> index 96c3343..2c60c2c 100644
> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> @@ -36,6 +36,7 @@ CONFIG_RTE_ARCH="arm"
>  CONFIG_RTE_ARCH_ARM=y
>  CONFIG_RTE_ARCH_ARMv7=y
>  CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
> +CONFIG_RTE_ARCH_ARM_NEON_MEMCPY=y
>
If it's not always benefit, why not disable here since it is common
armv7a config, and enable in your or other user's own config file?

Thanks!
Jianbo


[dpdk-dev] [PATCH 2/2] mk: fix two more missing libm dependencies

2016-03-21 Thread Panu Matilainen
Commit e86a699cf6b1 missed two further libm dependencies: ceil() used by
librte_meter is typically inlined so the missing dependency does not
actually cause failures, and librte_pmd_nfp is not built by default
so its easy to miss.

This causes duplicates in LDLIBS in many configurations so its vital
they are removed before passing to linker.

Fixes: e86a699cf6b1 ("mk: fix shared library dependencies on libm and librt")

Reported-by: Ferruh Yigit 
Signed-off-by: Panu Matilainen 
---
 drivers/net/nfp/Makefile  | 2 ++
 lib/librte_meter/Makefile | 2 ++
 mk/rte.app.mk | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/drivers/net/nfp/Makefile b/drivers/net/nfp/Makefile
index ef7a13d..11f 100644
--- a/drivers/net/nfp/Makefile
+++ b/drivers/net/nfp/Makefile
@@ -39,6 +39,8 @@ LIB = librte_pmd_nfp.a
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)

+LDLIBS += -lm
+
 EXPORT_MAP := rte_pmd_nfp_version.map

 LIBABIVER := 1
diff --git a/lib/librte_meter/Makefile b/lib/librte_meter/Makefile
index 8765881..f07fced 100644
--- a/lib/librte_meter/Makefile
+++ b/lib/librte_meter/Makefile
@@ -39,6 +39,8 @@ LIB = librte_meter.a
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)

+LDLIBS += -lm
+
 EXPORT_MAP := rte_meter_version.map

 LIBABIVER := 1
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index f4eb5e8..2f9bafe 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -85,6 +85,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST)  += -lrte_vhost
 ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
 _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)  += -lm
 _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)  += -lrt
+_LDLIBS-$(CONFIG_RTE_LIBRTE_METER)  += -lm
 ifeq ($(CONFIG_RTE_LIBRTE_VHOST_NUMA),y)
 _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST)  += -lnuma
 endif
@@ -101,6 +102,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD)   += -libverbs
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2)   += -lsze2
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT)+= -lxenstore
 _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD)  += -lgxio
+_LDLIBS-$(CONFIG_RTE_LIBRTE_NFP_PMD)+= -lm
 # QAT / AESNI GCM PMDs are dependent on libcrypto (from openssl)
 # for calculating HMAC precomputes
 ifeq ($(CONFIG_RTE_LIBRTE_PMD_QAT),y)
-- 
2.5.0



[dpdk-dev] [PATCH 1/2] mk: Eliminate possible duplicates from LDLIBS

2016-03-21 Thread Panu Matilainen
Duplicates in LDLIBS can cause link failures from multiply defined
symbols, ensure all libraries are only mentioned once. Can't use
sorting for duplicate elimination as order is critical so awk one-liner
is used.

Signed-off-by: Panu Matilainen 
---
 mk/rte.app.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index a1cd9a3..f4eb5e8 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -174,6 +174,9 @@ _LDLIBS-y += --no-whole-archive

 LDLIBS += $(_LDLIBS-y) $(CPU_LDLIBS) $(EXTRA_LDLIBS)

+# Eliminate duplicates without sorting
+LDLIBS := $(shell echo $(LDLIBS) | awk '{for (i = 1; i <= NF; i++) { if 
(!seen[$$i]++) print $$i }}')
+
 .PHONY: all
 all: install

-- 
2.5.0



[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

2016-03-21 Thread Olivier Matz
Hi,

On 03/17/2016 04:49 PM, Lazaros Koromilas wrote:
> Issuing a zero objects dequeue with a single consumer has no effect.
> Doing so with multiple consumers, can get more than one thread to succeed
> the compare-and-set operation and observe starvation or even deadlock in
> the while loop that checks for preceding dequeues.  The problematic piece
> of code when n = 0:
> 
> cons_next = cons_head + n;
> success = rte_atomic32_cmpset(>cons.head, cons_head, cons_next);
> 
> The same is possible on the enqueue path.
> 
> Signed-off-by: Lazaros Koromilas 

Acked-by: Olivier Matz 



[dpdk-dev] [PATCH] mempool: allow for user-owned mempool caches

2016-03-21 Thread Olivier Matz
Hi Lazaros,

Thanks for this patch. To me, this is a valuable enhancement.
Please find some comments inline.

On 03/10/2016 03:44 PM, Lazaros Koromilas wrote:
> The mempool cache is only available to EAL threads as a per-lcore
> resource. Change this so that the user can create and provide their own
> cache on mempool get and put operations. This works with non-EAL threads
> too. This commit introduces new API calls with the 'with_cache' suffix,
> while the current ones default to the per-lcore local cache.
> 
> Signed-off-by: Lazaros Koromilas 
> ---
>  lib/librte_mempool/rte_mempool.c |  65 +-
>  lib/librte_mempool/rte_mempool.h | 442 
> ---
>  2 files changed, 467 insertions(+), 40 deletions(-)
> 
> diff --git a/lib/librte_mempool/rte_mempool.c 
> b/lib/librte_mempool/rte_mempool.c
> index f8781e1..cebc2b7 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -375,6 +375,43 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, 
> size_t elt_sz,
>   return usz;
>  }
>  
> +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0

I wonder if this wouldn't cause a conflict with Keith's patch
that removes some #ifdefs RTE_MEMPOOL_CACHE_MAX_SIZE.
See: http://www.dpdk.org/dev/patchwork/patch/10492/

As this patch is already acked for 16.07, I think that your v2
could be rebased on top of it to avoid conflicts when Thomas will apply
it.

By the way, I also encourage you to have a look at other works in
progress in mempool:
http://www.dpdk.org/ml/archives/dev/2016-March/035107.html
http://www.dpdk.org/ml/archives/dev/2016-March/035201.html


> +static void
> +mempool_cache_init(struct rte_mempool_cache *cache, uint32_t size)
> +{
> + cache->size = size;
> + cache->flushthresh = CALC_CACHE_FLUSHTHRESH(size);
> + cache->len = 0;
> +}
> +
> +/*
> + * Creates and initializes a cache for objects that are retrieved from and
> + * returned to an underlying mempool. This structure is identical to the
> + * structure included inside struct rte_mempool.
> + */

On top of Keith's patch, this comment may be reworked as the cache
structure is not included in the mempool structure anymore.

nit: I think the imperative form is preferred


> +struct rte_mempool_cache *
> +rte_mempool_cache_create(uint32_t size)
> +{
> + struct rte_mempool_cache *cache;
> +
> + if (size > RTE_MEMPOOL_CACHE_MAX_SIZE) {
> + rte_errno = EINVAL;
> + return NULL;
> + }
> +
> + cache = rte_zmalloc("MEMPOOL_CACHE", sizeof(*cache), 
> RTE_CACHE_LINE_SIZE);
> + if (cache == NULL) {
> + RTE_LOG(ERR, MEMPOOL, "Cannot allocate mempool cache!\n");

I would remove the '!'



> @@ -587,10 +624,18 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
> unsigned elt_size,
>   mp->elt_size = objsz.elt_size;
>   mp->header_size = objsz.header_size;
>   mp->trailer_size = objsz.trailer_size;
> - mp->cache_size = cache_size;
> - mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
> + mp->cache_size = cache_size; /* Keep this for backwards compat. */

I'm wondering if this should be kept for compat or if it makes sense
to keep it. The question is: do we want the cache_size to be a parameter
of the mempool or should it be a parameter of the cache?

I think we could remove this field from the mempool structure.


> @@ -673,13 +718,17 @@ rte_mempool_dump_cache(FILE *f, const struct 
> rte_mempool *mp)
>  #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>   unsigned lcore_id;
>   unsigned count = 0;
> + unsigned cache_size;
>   unsigned cache_count;
>  
>   fprintf(f, "  cache infos:\n");
> - fprintf(f, "cache_size=%"PRIu32"\n", mp->cache_size);
>   for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
> + cache_size = mp->local_cache[lcore_id].size;
> + fprintf(f, "cache_size[%u]=%"PRIu32"\n",
> + lcore_id, cache_size);
>   cache_count = mp->local_cache[lcore_id].len;
> - fprintf(f, "cache_count[%u]=%u\n", lcore_id, cache_count);
> + fprintf(f, "cache_count[%u]=%"PRIu32"\n",
> + lcore_id, cache_count);
>   count += cache_count;

Does it still make sense to dump the content of the cache as some
external caches may exist?

If we want to list all caches, we could imagine a sort of cache
registration before using a cache structure. Example:

   cache = rte_mempool_add_cache()
   rte_mempool_del_cache()

All the caches could be browsed internally using a list.

Thoughts?


> --- a/lib/librte_mempool/rte_mempool.h
> +++ b/lib/librte_mempool/rte_mempool.h
> @@ -95,19 +95,19 @@ struct rte_mempool_debug_stats {
>  } __rte_cache_aligned;
>  #endif
>  
> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>  /**
>   * A structure that stores a per-core object cache.
>   */
>  struct rte_mempool_cache {
> - unsigned len; /**< Cache len */
> + uint32_t size;/**< Size of 

[dpdk-dev] [PATCH v3 4/4] eal/arm: introduce CONFIG_RTE_ARCH_ARM_NEON_MEMCPY

2016-03-21 Thread Jan Viktorin
On Mon, 21 Mar 2016 13:42:31 +0800
Jianbo Liu  wrote:

> On 20 March 2016 at 03:58, Jan Viktorin  wrote:
> > The flag is used to enable memcpy optimizations in EAL. As it is not always
> > the performance benefit, the flag allows to disable it.
> >
> > Signed-off-by: Jan Viktorin 
> > ---
> >  config/defconfig_arm-armv7a-linuxapp-gcc   | 1 +
> >  lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 8 ++--
> >  2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
> > b/config/defconfig_arm-armv7a-linuxapp-gcc
> > index 96c3343..2c60c2c 100644
> > --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> > @@ -36,6 +36,7 @@ CONFIG_RTE_ARCH="arm"
> >  CONFIG_RTE_ARCH_ARM=y
> >  CONFIG_RTE_ARCH_ARMv7=y
> >  CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
> > +CONFIG_RTE_ARCH_ARM_NEON_MEMCPY=y
> >  
> If it's not always benefit, why not disable here since it is common
> armv7a config, and enable in your or other user's own config file?

Jianbo, you are right. In that case, I'd just turn it off by default.
And when there is a new platform-specific defconfig, it can enable it.

Anyway, I am thinking of adding some comment into the rte_memcpy_32.h
file describing the potential of the NEON code. What about:

/* Enable in your defconfig to accelerate memcpy operations. Consider
   enabling this for Cortex-A15. For Cortex-A7 and Cortex-A9, It might
   accelerate short data copies (< 64 B). */

Thomas, do you consider this enough?

Jan

> 
> Thanks!
> Jianbo



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic


[dpdk-dev] [PATCH] mempool: allow for user-owned mempool caches

2016-03-21 Thread Ananyev, Konstantin

Hi lads,

> 
> Hi Lazaros,
> 
> Thanks for this patch. To me, this is a valuable enhancement.
> Please find some comments inline.

Yep, patch seems interesting.
One question - what would be the usage model for get/put_with_cache functions 
for non-EAL threads?
I meant for each non-EAL thread user will need to maintain an array (or list or 
some other structure)
of pair  to make sure that the cache always 
matches the mempool,
correct? 
Again, for non-EAL threads don't we need some sort of invalidate_cache()
that would put all mbufs in the cache back to the pool?
For thread termination case or so?

> 
> On 03/10/2016 03:44 PM, Lazaros Koromilas wrote:
> > The mempool cache is only available to EAL threads as a per-lcore
> > resource. Change this so that the user can create and provide their own
> > cache on mempool get and put operations. This works with non-EAL threads
> > too. This commit introduces new API calls with the 'with_cache' suffix,
> > while the current ones default to the per-lcore local cache.
> >
> > Signed-off-by: Lazaros Koromilas 
> > ---
> >  lib/librte_mempool/rte_mempool.c |  65 +-
> >  lib/librte_mempool/rte_mempool.h | 442 
> > ---
> >  2 files changed, 467 insertions(+), 40 deletions(-)
> >
> > diff --git a/lib/librte_mempool/rte_mempool.c 
> > b/lib/librte_mempool/rte_mempool.c
> > index f8781e1..cebc2b7 100644
> > --- a/lib/librte_mempool/rte_mempool.c
> > +++ b/lib/librte_mempool/rte_mempool.c
> > @@ -375,6 +375,43 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, 
> > size_t elt_sz,
> > return usz;
> >  }
> >
> > +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> 
> I wonder if this wouldn't cause a conflict with Keith's patch
> that removes some #ifdefs RTE_MEMPOOL_CACHE_MAX_SIZE.
> See: http://www.dpdk.org/dev/patchwork/patch/10492/
> 
> As this patch is already acked for 16.07, I think that your v2
> could be rebased on top of it to avoid conflicts when Thomas will apply
> it.
> 
> By the way, I also encourage you to have a look at other works in
> progress in mempool:
> http://www.dpdk.org/ml/archives/dev/2016-March/035107.html
> http://www.dpdk.org/ml/archives/dev/2016-March/035201.html
> 
> 
> > +static void
> > +mempool_cache_init(struct rte_mempool_cache *cache, uint32_t size)
> > +{
> > +   cache->size = size;
> > +   cache->flushthresh = CALC_CACHE_FLUSHTHRESH(size);
> > +   cache->len = 0;
> > +}
> > +
> > +/*
> > + * Creates and initializes a cache for objects that are retrieved from and
> > + * returned to an underlying mempool. This structure is identical to the
> > + * structure included inside struct rte_mempool.
> > + */
> 
> On top of Keith's patch, this comment may be reworked as the cache
> structure is not included in the mempool structure anymore.
> 
> nit: I think the imperative form is preferred
> 
> 
> > +struct rte_mempool_cache *
> > +rte_mempool_cache_create(uint32_t size)

I suppose extra socket_id parameter is needed, so you can call
zmalloc_socket() beneath.

> > +{
> > +   struct rte_mempool_cache *cache;
> > +
> > +   if (size > RTE_MEMPOOL_CACHE_MAX_SIZE) {
> > +   rte_errno = EINVAL;
> > +   return NULL;
> > +   }
> > +
> > +   cache = rte_zmalloc("MEMPOOL_CACHE", sizeof(*cache), 
> > RTE_CACHE_LINE_SIZE);
> > +   if (cache == NULL) {
> > +   RTE_LOG(ERR, MEMPOOL, "Cannot allocate mempool cache!\n");
> 
> I would remove the '!'
> 
> 
> 
> > @@ -587,10 +624,18 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
> > unsigned elt_size,
> > mp->elt_size = objsz.elt_size;
> > mp->header_size = objsz.header_size;
> > mp->trailer_size = objsz.trailer_size;
> > -   mp->cache_size = cache_size;
> > -   mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
> > +   mp->cache_size = cache_size; /* Keep this for backwards compat. */
> 
> I'm wondering if this should be kept for compat or if it makes sense
> to keep it. The question is: do we want the cache_size to be a parameter
> of the mempool or should it be a parameter of the cache?
> 
> I think we could remove this field from the mempool structure.
> 
> 
> > @@ -673,13 +718,17 @@ rte_mempool_dump_cache(FILE *f, const struct 
> > rte_mempool *mp)
> >  #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> > unsigned lcore_id;
> > unsigned count = 0;
> > +   unsigned cache_size;
> > unsigned cache_count;
> >
> > fprintf(f, "  cache infos:\n");
> > -   fprintf(f, "cache_size=%"PRIu32"\n", mp->cache_size);
> > for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
> > +   cache_size = mp->local_cache[lcore_id].size;
> > +   fprintf(f, "cache_size[%u]=%"PRIu32"\n",
> > +   lcore_id, cache_size);
> > cache_count = mp->local_cache[lcore_id].len;
> > -   fprintf(f, "cache_count[%u]=%u\n", lcore_id, cache_count);
> > +   fprintf(f, "cache_count[%u]=%"PRIu32"\n",
> > +   lcore_id, cache_count);

[dpdk-dev] [PATCH v6] examples/l3fwd: em path performance fix

2016-03-21 Thread Thomas Monjalon
2016-03-18 14:31, Tomasz Kulasek:
> It seems that for the most use cases, previous hash_multi_lookup provides
> better performance, and more, sequential lookup can cause significant
> performance drop.
> 
> This patch sets previously optional hash_multi_lookup method as default.
> It also provides some minor optimizations such as queue drain only on used
> tx ports.

Applied, thanks


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

2016-03-21 Thread Bruce Richardson
On Mon, Mar 21, 2016 at 02:45:06PM +0900, Tetsuya Mukawa wrote:
> The patch introduces a new PMD. This PMD is implemented as thin wrapper
> of librte_vhost.
> 
 
> 
> Tetsuya Mukawa (2):
>   ethdev: Add a new event type to notify a queue state changed event
>   vhost: Add VHOST PMD
> 
Applied to dpdk-next-net/rel_16_04

Thanks,
/Bruce


[dpdk-dev] [PATCH v2] l3fwd: Fix compilation with HASH_MULTI_LOOKUP

2016-03-21 Thread Thomas Monjalon
2016-03-16 07:23, Maciej Czekaj:
> l3fwd does not compile with HASH_MULTI_LOOKUP.
> 2 issues:
>  * in 64d395 mask0 changed type from xmm_t to rte_xmm_t
>   -> use x field from rte_xmm_t
>  * in dc81eb dst_port parameter changed to uint32_t
>   -> change uint16_t dst_port to uin32_t dsp_port
> 
> Signed-off-by: Maciej Czekaj 

Applied, thanks


[dpdk-dev] build error with default configuration

2016-03-21 Thread Iremonger, Bernard
Hi Thomas,

There is a build error occurring when using the default configuration.

make config T=x86_64-default-linuxapp-gcc


make install T=x86_64-default-linuxapp-gcc -j

In file included from /root/dpdk_sforge_2/lib/librte_table/rte_table_lpm.c:43:0:
/root/dpdk_sforge_2/x86_64-default-linuxapp-gcc/include/rte_lpm.h:484:25: fatal 
error: rte_lpm_sse.h: No such file or directory
#include "rte_lpm_sse.h"
 ^
compilation terminated.

Regards,

Bernard.


[dpdk-dev] [PATCH 2/2] mk: fix two more missing libm dependencies

2016-03-21 Thread Ferruh Yigit
On 3/21/2016 11:33 AM, Panu Matilainen wrote:
> Commit e86a699cf6b1 missed two further libm dependencies: ceil() used by
> librte_meter is typically inlined so the missing dependency does not
> actually cause failures, and librte_pmd_nfp is not built by default
> so its easy to miss.
> 
> This causes duplicates in LDLIBS in many configurations so its vital
> they are removed before passing to linker.
> 
> Fixes: e86a699cf6b1 ("mk: fix shared library dependencies on libm and librt")
> 
> Reported-by: Ferruh Yigit 
> Signed-off-by: Panu Matilainen 

Tested-by: Ferruh Yigit 



[dpdk-dev] DPDK and HW offloads

2016-03-21 Thread Kyle Larose
On Mon, Mar 21, 2016 at 10:52 AM, Bruce Richardson
 wrote:
> On Sun, Mar 20, 2016 at 08:18:57PM +0100, Thomas Monjalon wrote:
>> 2016-03-20 14:17, Zhang, Helin:
>> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> > > 2016-03-18 10:16, Stephen Hemminger:
>> > > > Right now, all those offload features are pretty much unusable in a
>> > > > real product without lots and lots of extra codes and huge bug
>> > > > surface. It bothers me enough that I would recommend removing much of 
>> > > > the
>> > > filter/offload/ptype stuff from DPDK!
>> > >
>> > > One of the biggest challenge is to think about a good filtering API.
>> > > The offloading has some interaction with the mbuf struct.
>> > >
>> > > I would like to suggest rewriting ethdev API by keeping it as is for 
>> > > some time for
>> > > compatibility while creating a new one. What about the prefix 
>> > > dpdk_netdev_ to
>> > > progressively replace rte_eth_dev?
>> >
>> > I totally agree with to add new and generic APIs for user applications. 
>> > But I don't
>> > think we need to remove all current APIs. Generic APIs may not support all 
>> > advanced
>> > hardware features, while specific APIs can. Why not support all? One 
>> > generic APIs for
>> > common users, and others APIs for advanced users.
>>
>> Yes we cannot access to every features of a device through generic API.
>> Until now we were trying to add an ethdev API for every features even if it
>> is used by only one driver.
>> I think we should allow a direct access to the driver by the applications and
>> work on generic API only for common features.
>
> Definite +1.
> I think that we need to start pushing driver-specific functionality to get 
> exposed
> via a driver's header files. That allow users who want to extract the max
> functionality from a particular NIC to do so via those APIs calls, while not
> polluting the generic ethdev layer.
>

What sort of requirements on ABI/API compatibility would this place on
the drivers? I would hope that it would be treated like any other
public API within DPDK. I don't think this would be too onerous, but
it would require that the drivers be designed to deal with it. (I.e.
don't just expose any old internal driver function).

> On the other hand, I don't like the idea of dpdk_netdev. I think we can work
> within the existing rte_eth_dev framework.
>
> /Bruce
>


[dpdk-dev] [PATCH] igb_uio: fix vmware e1000 input/output error

2016-03-21 Thread Thomas Monjalon
2016-03-21 17:01, Qian Xu:
> INTX is badly emulated in Vmware, INTX toggle check didn't work
> with Vmware e1000 device. The patch is to fix the issue.

Is it possible to detect a VMware e1000 device?

> --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>   case RTE_INTR_MODE_LEGACY:
> - if (pci_intx_mask_supported(dev)) {
> - dev_dbg(>dev, "using INTX");
> - udev->info.irq_flags = IRQF_SHARED;
> - udev->info.irq = dev->irq;
> - udev->mode = RTE_INTR_MODE_LEGACY;
> - break;
> - }
> - dev_notice(>dev, "PCI INTX mask not supported\n");
> +dev_dbg(>dev, "using INTX");
> +udev->info.irq_flags = IRQF_SHARED;
> +udev->info.irq = dev->irq;
> +udev->mode = RTE_INTR_MODE_LEGACY;
> +break;
>   /* fall back to no IRQ */
>   case RTE_INTR_MODE_NONE:

This patch is removing the INTX support detection and the
fallback to no IRQ.



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

2016-03-21 Thread Bruce Richardson
On Mon, Mar 21, 2016 at 06:24:36PM +0900, Tetsuya Mukawa wrote:
> 2016-03-21 17:37 GMT+09:00 Thomas Monjalon :
> > 2016-03-21 14:45, Tetsuya Mukawa:
> >> This event will be occured when some queues are enabled or disabled.
> >> So far, only vhost PMD supports the event, and it indicates some queues
> >> are enabled or disabled by virtio-net device. Such an event is needed
> >> because virtio-net device may not enable all queues vhost PMD prepare.
> >>
> >> Because only vhost PMD uses the event so far, it isn't an actual hardware
> >> interrupt but a simple software event.
> > [...]
> >>
> >> + RTE_ETH_EVENT_QUEUE_STATE_CHANGE,
> >> + /**< queue state changed interrupt */
> >
> > Is the shorter RTE_ETH_EVENT_QUEUE_STATE descriptive enough?
> >
> > What about this comment?
> > /**< queue state event (enabled/disabled) */
> 
> Hi Thomas,
> 
> Yes, it's enough, and above comment is nice.
> Thanks for suggestion.
> 
> 
> Hi Bruce,
> 
> If today is the deadline, could you kindly please replace above
> changes while merging?
> I need half a day to re-submit the patch. Sorry for asking it.
> I will ask my company to let me have vpn access. ;)
> 
> Regards,
> Tetsuya

Yes, I can fix on apply to dpdk-next-net.

/Bruce


[dpdk-dev] [PATCH] git: ignore build directory

2016-03-21 Thread Stephen Hemminger
The mk environment in DPDK puts files in build/ directory
so it makes sense to have a .gitignore file to skip that
directory.

Signed-off-by: Stephen Hemminger 
---
 .gitignore | 5 +
 1 file changed, 5 insertions(+)

diff --git a/.gitignore b/.gitignore
index e69de29..5dc652b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1,5 @@
+*.orig
+*.rej
+*~
+
+build
-- 
2.1.4



[dpdk-dev] [PATCH 6/6] mpipe: make eth_dev_ops const

2016-03-21 Thread Stephen Hemminger
Signed-off-by: Stephen Hemminger 
---
 drivers/net/mpipe/mpipe_tilegx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index aef7600..7180e5a 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -1165,7 +1165,7 @@ mpipe_promiscuous_disable(struct rte_eth_dev *dev)
}
 }

-static struct eth_dev_ops mpipe_dev_ops = {
+static const struct eth_dev_ops mpipe_dev_ops = {
.dev_infos_get   = mpipe_infos_get,
.dev_configure   = mpipe_configure,
.dev_start   = mpipe_start,
-- 
2.1.4



[dpdk-dev] [PATCH 5/6] szedata: make eth_dev_ops const

2016-03-21 Thread Stephen Hemminger
All usage of eth_dev_ops should be const.
And fix the indentation

Signed-off-by: Stephen Hemminger 
---
 drivers/net/szedata2/rte_eth_szedata2.c | 48 -
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/net/szedata2/rte_eth_szedata2.c 
b/drivers/net/szedata2/rte_eth_szedata2.c
index 81c806e..1d6a600 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1317,30 +1317,30 @@ eth_allmulticast_disable(struct rte_eth_dev *dev)
cgmii_ibuf_mac_mode_write(ibuf, SZEDATA2_MAC_CHMODE_ONLY_VALID);
 }

-static struct eth_dev_ops ops = {
-   .dev_start  = eth_dev_start,
-   .dev_stop   = eth_dev_stop,
-   .dev_set_link_up= eth_dev_set_link_up,
-   .dev_set_link_down  = eth_dev_set_link_down,
-   .dev_close  = eth_dev_close,
-   .dev_configure  = eth_dev_configure,
-   .dev_infos_get  = eth_dev_info,
-   .promiscuous_enable   = eth_promiscuous_enable,
-   .promiscuous_disable  = eth_promiscuous_disable,
-   .allmulticast_enable  = eth_allmulticast_enable,
-   .allmulticast_disable = eth_allmulticast_disable,
-   .rx_queue_start = eth_rx_queue_start,
-   .rx_queue_stop  = eth_rx_queue_stop,
-   .tx_queue_start = eth_tx_queue_start,
-   .tx_queue_stop  = eth_tx_queue_stop,
-   .rx_queue_setup = eth_rx_queue_setup,
-   .tx_queue_setup = eth_tx_queue_setup,
-   .rx_queue_release   = eth_rx_queue_release,
-   .tx_queue_release   = eth_tx_queue_release,
-   .link_update= eth_link_update,
-   .stats_get  = eth_stats_get,
-   .stats_reset= eth_stats_reset,
-   .mac_addr_set   = eth_mac_addr_set,
+static const struct eth_dev_ops ops = {
+   .dev_start  = eth_dev_start,
+   .dev_stop   = eth_dev_stop,
+   .dev_set_link_up= eth_dev_set_link_up,
+   .dev_set_link_down  = eth_dev_set_link_down,
+   .dev_close  = eth_dev_close,
+   .dev_configure  = eth_dev_configure,
+   .dev_infos_get  = eth_dev_info,
+   .promiscuous_enable   = eth_promiscuous_enable,
+   .promiscuous_disable  = eth_promiscuous_disable,
+   .allmulticast_enable  = eth_allmulticast_enable,
+   .allmulticast_disable = eth_allmulticast_disable,
+   .rx_queue_start = eth_rx_queue_start,
+   .rx_queue_stop  = eth_rx_queue_stop,
+   .tx_queue_start = eth_tx_queue_start,
+   .tx_queue_stop  = eth_tx_queue_stop,
+   .rx_queue_setup = eth_rx_queue_setup,
+   .tx_queue_setup = eth_tx_queue_setup,
+   .rx_queue_release   = eth_rx_queue_release,
+   .tx_queue_release   = eth_tx_queue_release,
+   .link_update= eth_link_update,
+   .stats_get  = eth_stats_get,
+   .stats_reset= eth_stats_reset,
+   .mac_addr_set   = eth_mac_addr_set,
 };

 /*
-- 
2.1.4



[dpdk-dev] [PATCH 4/6] nfp: make eth_dev_ops const

2016-03-21 Thread Stephen Hemminger
Signed-off-by: Stephen Hemminger 
---
 drivers/net/nfp/nfp_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 8810704..85d4009 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2272,7 +2272,7 @@ nfp_net_rss_hash_conf_get(struct rte_eth_dev *dev,
 }

 /* Initialise and register driver with DPDK Application */
-static struct eth_dev_ops nfp_net_eth_dev_ops = {
+static const struct eth_dev_ops nfp_net_eth_dev_ops = {
.dev_configure  = nfp_net_configure,
.dev_start  = nfp_net_start,
.dev_stop   = nfp_net_stop,
-- 
2.1.4



[dpdk-dev] [PATCH 3/6] bnx2x: make eth_dev_ops const

2016-03-21 Thread Stephen Hemminger
Signed-off-by: Stephen Hemminger 
---
 drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index fe8cfd0..7e5be08 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -348,7 +348,7 @@ bnx2x_mac_addr_remove(struct rte_eth_dev *dev, uint32_t 
index)
sc->mac_ops.mac_addr_remove(dev, index);
 }

-static struct eth_dev_ops bnx2x_eth_dev_ops = {
+static const struct eth_dev_ops bnx2x_eth_dev_ops = {
.dev_configure= bnx2x_dev_configure,
.dev_start= bnx2x_dev_start,
.dev_stop = bnx2x_dev_stop,
@@ -371,7 +371,7 @@ static struct eth_dev_ops bnx2x_eth_dev_ops = {
 /*
  * dev_ops for virtual function
  */
-static struct eth_dev_ops bnx2xvf_eth_dev_ops = {
+static const struct eth_dev_ops bnx2xvf_eth_dev_ops = {
.dev_configure= bnx2x_dev_configure,
.dev_start= bnx2x_dev_start,
.dev_stop = bnx2x_dev_stop,
-- 
2.1.4



[dpdk-dev] [PATCH 2/6] cxgbe: make eth_dev_ops const

2016-03-21 Thread Stephen Hemminger

Signed-off-by: Stephen Hemminger 
---
 drivers/net/cxgbe/cxgbe_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 8c6dd59..0d636ad 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -767,7 +767,7 @@ static int cxgbe_flow_ctrl_set(struct rte_eth_dev *eth_dev,
 >link_cfg);
 }

-static struct eth_dev_ops cxgbe_eth_dev_ops = {
+static const struct eth_dev_ops cxgbe_eth_dev_ops = {
.dev_start  = cxgbe_dev_start,
.dev_stop   = cxgbe_dev_stop,
.dev_close  = cxgbe_dev_close,
-- 
2.1.4



[dpdk-dev] [PATCH 1/6] bonding: make eth_dev_ops const

2016-03-21 Thread Stephen Hemminger
This structure has immutable function pointers.
Also fix indentation.

Signed-off-by: Stephen Hemminger 

---
 drivers/net/bonding/rte_eth_bond_pmd.c | 38 +++---
 drivers/net/bonding/rte_eth_bond_private.h |  2 +-
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 011150a..8961a67 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2142,25 +2142,25 @@ bond_ethdev_rss_hash_conf_get(struct rte_eth_dev *dev,
return 0;
 }

-struct eth_dev_ops default_dev_ops = {
-   .dev_start= bond_ethdev_start,
-   .dev_stop = bond_ethdev_stop,
-   .dev_close= bond_ethdev_close,
-   .dev_configure= bond_ethdev_configure,
-   .dev_infos_get= bond_ethdev_info,
-   .rx_queue_setup   = bond_ethdev_rx_queue_setup,
-   .tx_queue_setup   = bond_ethdev_tx_queue_setup,
-   .rx_queue_release = bond_ethdev_rx_queue_release,
-   .tx_queue_release = bond_ethdev_tx_queue_release,
-   .link_update  = bond_ethdev_link_update,
-   .stats_get= bond_ethdev_stats_get,
-   .stats_reset  = bond_ethdev_stats_reset,
-   .promiscuous_enable   = bond_ethdev_promiscuous_enable,
-   .promiscuous_disable  = bond_ethdev_promiscuous_disable,
-   .reta_update  = bond_ethdev_rss_reta_update,
-   .reta_query   = bond_ethdev_rss_reta_query,
-   .rss_hash_update  = bond_ethdev_rss_hash_update,
-   .rss_hash_conf_get= bond_ethdev_rss_hash_conf_get
+const struct eth_dev_ops default_dev_ops = {
+   .dev_start= bond_ethdev_start,
+   .dev_stop = bond_ethdev_stop,
+   .dev_close= bond_ethdev_close,
+   .dev_configure= bond_ethdev_configure,
+   .dev_infos_get= bond_ethdev_info,
+   .rx_queue_setup   = bond_ethdev_rx_queue_setup,
+   .tx_queue_setup   = bond_ethdev_tx_queue_setup,
+   .rx_queue_release = bond_ethdev_rx_queue_release,
+   .tx_queue_release = bond_ethdev_tx_queue_release,
+   .link_update  = bond_ethdev_link_update,
+   .stats_get= bond_ethdev_stats_get,
+   .stats_reset  = bond_ethdev_stats_reset,
+   .promiscuous_enable   = bond_ethdev_promiscuous_enable,
+   .promiscuous_disable  = bond_ethdev_promiscuous_disable,
+   .reta_update  = bond_ethdev_rss_reta_update,
+   .reta_query   = bond_ethdev_rss_reta_query,
+   .rss_hash_update  = bond_ethdev_rss_hash_update,
+   .rss_hash_conf_get= bond_ethdev_rss_hash_conf_get
 };

 static int
diff --git a/drivers/net/bonding/rte_eth_bond_private.h 
b/drivers/net/bonding/rte_eth_bond_private.h
index 6c47a29..8312397 100644
--- a/drivers/net/bonding/rte_eth_bond_private.h
+++ b/drivers/net/bonding/rte_eth_bond_private.h
@@ -171,7 +171,7 @@ struct bond_dev_private {
uint8_t slave_update_idx;
 };

-extern struct eth_dev_ops default_dev_ops;
+extern const struct eth_dev_ops default_dev_ops;

 int
 check_for_bonded_ethdev(const struct rte_eth_dev *eth_dev);
-- 
2.1.4



[dpdk-dev] [PATCH 0/6] make eth_dev_ops const

2016-03-21 Thread Stephen Hemminger
Newer driver seem not to have gotten the message that eth_dev_ops
structure should be const.

Stephen Hemminger (6):
  bonding: make eth_dev_ops const
  cxgbe: make eth_dev_ops const
  bnx2x: make eth_dev_ops const
  nfp: make eth_dev_ops const
  szedata: make eth_dev_ops const
  mpipe: make eth_dev_ops const

 drivers/net/bnx2x/bnx2x_ethdev.c   |  4 +--
 drivers/net/bonding/rte_eth_bond_pmd.c | 38 +++
 drivers/net/bonding/rte_eth_bond_private.h |  2 +-
 drivers/net/cxgbe/cxgbe_ethdev.c   |  2 +-
 drivers/net/mpipe/mpipe_tilegx.c   |  2 +-
 drivers/net/nfp/nfp_net.c  |  2 +-
 drivers/net/szedata2/rte_eth_szedata2.c| 48 +++---
 7 files changed, 49 insertions(+), 49 deletions(-)

-- 
2.1.4



[dpdk-dev] [PATCH 1/2] szedata2: new poll mode driver

2016-03-21 Thread Stephen Hemminger
On Fri, 19 Jun 2015 10:25:00 +0200
Matej Vido  wrote:

> +static struct ether_addr eth_addr = {
> + .addr_bytes = { 0, 0, 0, 0x1, 0x2, 0x3 }
> +};
...

> static int
> rte_szedata2_eth_dev_init(struct rte_eth_dev *dev)
> {
.. 
>   /* Allocate space for one mac address */
>   data->mac_addrs = rte_zmalloc(data->name, sizeof(struct ether_addr),
>   RTE_CACHE_LINE_SIZE);
>   if (data->mac_addrs == NULL) {
>   RTE_LOG(ERR, PMD, "Could not alloc space for MAC address!\n");
>   munmap(dev->pci_dev->mem_resource[PCI_RESOURCE_NUMBER].addr,
>   dev->pci_dev->mem_resource[PCI_RESOURCE_NUMBER].len);
>   return -EINVAL;
>   }
> 
>   ether_addr_copy(_addr, data->mac_addrs);

If your hardware has no permanent MAC address, then please use eth_random_addr()
to make one on boot, rather than having a bogus static value.


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

2016-03-21 Thread Stephen Hemminger
On Thu, 17 Mar 2016 15:31:18 +0100
Jan Medala  wrote:

> +static struct eth_dev_ops ena_dev_ops = {
> + .dev_configure= ena_dev_configure,
> + .dev_infos_get= ena_infos_get,
> + .rx_queue_setup   = ena_rx_queue_setup,
> + .tx_queue_setup   = ena_tx_queue_setup,
> + .dev_start= ena_start,
> + .link_update  = ena_link_update,
> + .stats_get= ena_stats_get,
> + .mtu_set  = ena_mtu_set,
> + .rx_queue_release = ena_rx_queue_release,
> + .tx_queue_release = ena_tx_queue_release,
> + .dev_close= ena_close,
> + .reta_update  = ena_rss_reta_update,
> + .reta_query   = ena_rss_reta_query,
> +};
> +

Why is ena_dev_ops not const?


[dpdk-dev] [PATCH v3 05/10] qede: Add core driver

2016-03-21 Thread Stephen Hemminger
On Fri, 18 Mar 2016 17:53:20 -0700
Rasesh Mody  wrote:

> +static struct eth_dev_ops qede_eth_dev_ops = {
> + .dev_configure = qede_dev_configure,
> + .dev_infos_get = qede_dev_info_get,
> + .rx_queue_setup = qede_rx_queue_setup,
> + .rx_queue_release = qede_rx_queue_release,
> + .tx_queue_setup = qede_tx_queue_setup,
> + .tx_queue_release = qede_tx_queue_release,
> + .dev_start = qede_dev_start,
> + .dev_set_link_up = qede_dev_set_link_up,
> + .dev_set_link_down = qede_dev_set_link_down,
> + .link_update = qede_link_update,
> + .promiscuous_enable = qede_promiscuous_enable,
> + .promiscuous_disable = qede_promiscuous_disable,
> + .allmulticast_enable = qede_allmulticast_enable,
> + .allmulticast_disable = qede_allmulticast_disable,
> + .dev_stop = qede_dev_stop,
> + .dev_close = qede_dev_close,
> + .stats_get = qede_get_stats,
> + .mac_addr_add = qede_mac_addr_add,
> + .mac_addr_remove = qede_mac_addr_remove,
> + .vlan_offload_set = qede_vlan_offload_set,
> + .vlan_filter_set = qede_vlan_filter_set,
> + .flow_ctrl_set = qede_flow_ctrl_set,
> + .flow_ctrl_get = qede_flow_ctrl_get,
> +};
> +

All eth_dev_ops structures should be marked const.
It makes it harder for attacker to find a handle.


[dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the tail of rx hwring

2016-03-21 Thread Jianbo Liu
On 18 March 2016 at 18:03, Bruce Richardson  
wrote:
> On Thu, Mar 17, 2016 at 10:20:01AM +0800, Jianbo Liu wrote:
>> On 16 March 2016 at 19:14, Bruce Richardson  
>> wrote:
>> > On Wed, Mar 16, 2016 at 03:51:53PM +0800, Jianbo Liu wrote:
>> >> Hi Wenzhuo,
>> >>
>> >> On 16 March 2016 at 14:06, Lu, Wenzhuo  wrote:
>> >> > HI Jianbo,
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jianbo Liu
>> >> >> Sent: Monday, March 14, 2016 10:26 PM
>> >> >> To: Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org
>> >> >> Cc: Jianbo Liu
>> >> >> Subject: [dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking 
>> >> >> at the
>> >> >> tail of rx hwring
>> >> >>
>> >> >> When checking rx ring queue, it's possible that loop will break at the 
>> >> >> tail while
>> >> >> there are packets still in the queue header.
>> >> > Would you like to give more details about in what scenario this issue 
>> >> > will be hit? Thanks.
>> >> >
>> >>
>> >> vPMD will place extra RTE_IXGBE_DESCS_PER_LOOP - 1 number of empty
>> >> descriptiors at the end of hwring to avoid overflow when do checking
>> >> on rx side.
>> >>
>> >> For the loop in _recv_raw_pkts_vec(), we check 4 descriptors each
>> >> time. If all 4 DD are set, and all 4 packets are received.That's OK in
>> >> the middle.
>> >> But if come to the end of hwring, and less than 4 descriptors left, we
>> >> still need to check 4 descriptors at the same time, so the extra empty
>> >> descriptors are checked with them.
>> >> This time, the number of received packets is apparently less than 4,
>> >> and we break out of the loop because of the condition "var !=
>> >> RTE_IXGBE_DESCS_PER_LOOP".
>> >> So the problem arises. It is possible that there could be more packets
>> >> at the hwring beginning that still waiting for being received.
>> >> I think this fix can avoid this situation, and at least reduce the
>> >> latency for the packets in the header.
>> >>
>> > Packets are always received in order from the NIC, so no packets ever get 
>> > left
>> > behind or skipped on an RX burst call.
>> >
>> > /Bruce
>> >
>>
>> I knew packets are received in order, and no packets will be skipped,
>> but some will be left behind as I explained above.
>> vPMD will not received nb_pkts required by one RX burst call, and
>> those at the beginning of hwring are still waiting to be received till
>> the next call.
>>
>> Thanks!
>> Jianbo
> HI Jianbo,
>
> ok, I understand now. I'm not sure that this is a significant problem though,
> since we are working in polling mode. Is there a performance impact to your
> change, because I don't think that we can reduce performance just to fix this?
>
> Regards,
> /Bruce
It will be a problem because the possibility could be high.
Considering rx hwring size is 128 and rx burst is 32, the possiblity
can be 32/128.
I know this change is critical, so I want you (and maintainers) to do
full evaluations about throughput/latency..before making conclusion.

Jianbo


[dpdk-dev] [PATCH] testpmd: fix build on FreeBSD

2016-03-21 Thread Marvin Liu
Build log:
/root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
's6_addr32' in 'struct in6_addr'
rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);

This is caused by macro "s6_addr32" not defined on FreeBSD.

Signed-off-by: Marvin Liu 

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 9d52b8c..51ad23b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6684,7 +6684,11 @@ cmd_tunnel_filter_parsed(void *parsed_result,
int i;
for (i = 0; i < 4; i++) {
tunnel_filter_conf.ip_addr.ipv6_addr[i] =
+#ifdef RTE_EXEC_ENV_BSDAPP
+   
rte_be_to_cpu_32(res->ip_value.addr.ipv6.__u6_addr.__u6_addr32[i]);
+#else
rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
+#endif
}
tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV6;
}
-- 
1.9.3



[dpdk-dev] [PATCH] testpmd: fix build on FreeBSD

2016-03-21 Thread De Lara Guarch, Pablo


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez
> Monroy
> Sent: Monday, March 21, 2016 9:13 AM
> To: Liu, Yong; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] testpmd: fix build on FreeBSD
> 
> On 21/03/2016 01:44, Marvin Liu wrote:
> > Build log:
> > /root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
> > 's6_addr32' in 'struct in6_addr'
> > rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> >
> > This is caused by macro "s6_addr32" not defined on FreeBSD.
> >
> > Signed-off-by: Marvin Liu 
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index 9d52b8c..51ad23b 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -6684,7 +6684,11 @@ cmd_tunnel_filter_parsed(void *parsed_result,
> > int i;
> > for (i = 0; i < 4; i++) {
> > tunnel_filter_conf.ip_addr.ipv6_addr[i] =
> > +#ifdef RTE_EXEC_ENV_BSDAPP
> > +   rte_be_to_cpu_32(res-
> >ip_value.addr.ipv6.__u6_addr.__u6_addr32[i]);
> > +#else
> > rte_be_to_cpu_32(res-
> >ip_value.addr.ipv6.s6_addr32[i]);
> > +#endif
> 
> Why not always use .__u6_addr.__u6_addr32[i] and avoid ifdef?
> 
> Sergio
> 
> > }
> > tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV6;
> > }

Also, can you include the missing "Fixes" line?

Thanks,
Pablo



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

2016-03-21 Thread Thomas Monjalon
2016-03-21 14:45, Tetsuya Mukawa:
> This event will be occured when some queues are enabled or disabled.
> So far, only vhost PMD supports the event, and it indicates some queues
> are enabled or disabled by virtio-net device. Such an event is needed
> because virtio-net device may not enable all queues vhost PMD prepare.
> 
> Because only vhost PMD uses the event so far, it isn't an actual hardware
> interrupt but a simple software event.
[...]
> 
> + RTE_ETH_EVENT_QUEUE_STATE_CHANGE,
> + /**< queue state changed interrupt */

Is the shorter RTE_ETH_EVENT_QUEUE_STATE descriptive enough?

What about this comment?
/**< queue state event (enabled/disabled) */


[dpdk-dev] Issues with openvswitch2.5+dpdk2.2+kvm/virtio-pci

2016-03-21 Thread Christian Ehrhardt
FYI - a user also reported that the same issue also affects non-virtual
environments when using the BNX2X_PMD

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Fri, Mar 18, 2016 at 4:20 PM, Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

> Hi,
> I was trying to replicate a setup that I have working on physical devices
> (ixgbe) under kvm since there is a virtio pmd driver.
>
> TL;DR:
> - under KVM with virtio-pci (working on baremetal with ixgbe cards)
> - adding dpdk port to ovs fails with memzone  already exists
> and causes a segfault
> - I couldn't find a solution in similar mails that popped up here
> recently, any help or pointer appreciated.
>
> ## Details ##
> I thought I've read that others have it working I thought that would be a
> great way to gain more debug control of the environment, but something
> seems to be eluding me.
>
> There were quite some similar mails on the List recently, but none seemed
> to hit the same issue as I do. At least none of the tunings/workarounds
> seemed to apply to me.
> As versions I have Openvswitch 2.5, DPDK 2.2, Qemu 2.5, Kernel 4.4 - so a
> fairly recent software stack.
>
> The super-short repro summary is:
> 1. starting ovs-dpdk like
> ovs-vswitchd --dpdk -c 0x1 -n 4 --pci-blacklist :00:03.0 -m 2048 --
> unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info
> --mlockall --no-chdir --log-file=/var/log/openvswitch/ovs-vswitchd.log
> --pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach --monitor
> 2. add a bridge and a ovs dpdk port
> ovs-vsctl add-port ovsdpdkbr0 dpdk0 -- set Interface dpdk0 type=dpdk
> ovs-vsctl add-port ovsdpdkbr0 dpdk0 -- set Interface dpdk0 type=dpdk
>
> The log of the initialization after #1 looks good to me - I can see two of
> my three virtio devices recognized and one blacklisted.
> Memory allocation looks good, ... I'll attach the log at the end of the
> mail
>
>
> ## ISSUE ##
> But when I add a port and refer to one of the dpdk ports it fails with the
> following:
> ovs-vsctl[14023]: ovs|1|vsctl|INFO|Called as ovs-vsctl add-port
> ovsdpdkbr0 dpdk0 -- set Interface dpdk0 type=dpdk
> ovs-vswitchd[13903]: EAL: memzone_reserve_aligned_thread_unsafe(): memzone
>  already exists
> ovs-vswitchd[13903]: EAL: memzone_reserve_aligned_thread_unsafe(): memzone
>  already exists
> ovs-vswitchd[13903]: EAL: memzone_reserve_aligned_thread_unsafe(): memzone
>  already exists
> kernel: show_signal_msg: 18 callbacks suppressed
> kernel: pmd12[14025]: segfault at 2 ip 7f3eb205eab2 sp
> 7f3e3dffa590 error 4 in libdpdk.so.0[7f3eb1fdf000+1e9000]
> ovs-vswitchd[13902]: ovs|3|daemon_unix(monitor)|ERR|1 crashes: pid
> 13903 died, killed (Segmentation fault), core dumped, restarting
> systemd-udevd[14040]: Could not generate persistent MAC address for
> ovs-netdev: No such file or directory
> kernel: device ovs-netdev entered promiscuous mode
> ovs-vswitchd[14036]: EAL: memzone_reserve_aligned_thread_unsafe(): memzone
>  already exists
> ovs-vswitchd[14036]: RING: Cannot reserve memory
> kernel: device ovsdpdkbr0 entered promiscuous mode
> ovs-vswitchd[14036]: EAL: memzone_reserve_aligned_thread_unsafe(): memzone
>  already exists
> ovs-vswitchd[14036]: RING: Cannot reserve memory
>
>
> ## Experiments (failed) ##
> I thought it could be related to all the multiqueue chances that recently
> going in.
> My usual setup has 4 vCPUs and 4 queues per virtio-net device.
> I tried them with only 1 of 4 queues, also with only 1 queue defined and
> only 1 CPU - but all fail the same way.
> I have testpmd and l2fwd on the same devices working, so I hope they are
> not totally set up badly.
>
> I also tried hilarious things like reassigning to uio_pci_generic before,
> but well its virtio_pmd eventually anyways - so it made no difference.
>
> From how it appears I felt that it could be related to the old discussions
> around
> [1] http://dpdk.org/ml/archives/dev/2015-May/017589.html
> [2] http://openvswitch.org/pipermail/dev/2015-March/052344.html
> But they are (partially) applied upstream already and the issue doesn't
> 100% match the old discussions.
>
>
> ## Logs ##
> [3] log of openvswitch start:
> systemd[1]: Starting Open vSwitch Internal Unit...
> ovs-ctl[13868]:  * Starting ovsdb-server
> ovs-vsctl[13893]: ovs|1|vsctl|INFO|Called as ovs-vsctl --no-wait --
> init -- set Open_vSwitch . db-version=7.12.1
> ovs-vsctl[13898]: ovs|1|vsctl|INFO|Called as ovs-vsctl --no-wait set
> Open_vSwitch . ovs-version=2.5.0
> "external-ids:system-id=\"8ddb892c-53a5-410d-a765-0031ad6eb1be\""
> "system-type=\"Ubuntu\"" "system-version=\"16.04-xenial\""
> ovs-ctl[13868]:  * Configuring Open vSwitch system IDs
> ovs-ctl[13868]: 2016-03-18T14:28:28Z|1|dpdk|INFO|No -vhost_sock_dir
> provided - defaulting to /var/run/openvswitch
> ovs-vswitchd[13900]: ovs|1|dpdk|INFO|No -vhost_sock_dir provided -
> defaulting to /var/run/openvswitch
> ovs-ctl[13868]: EAL: Detected lcore 0 as core 0 on 

[dpdk-dev] [PATCH] testpmd: fix build on FreeBSD

2016-03-21 Thread Sergio Gonzalez Monroy
On 21/03/2016 01:44, Marvin Liu wrote:
> Build log:
> /root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
> 's6_addr32' in 'struct in6_addr'
>   rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
>
> This is caused by macro "s6_addr32" not defined on FreeBSD.
>
> Signed-off-by: Marvin Liu 
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 9d52b8c..51ad23b 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -6684,7 +6684,11 @@ cmd_tunnel_filter_parsed(void *parsed_result,
>   int i;
>   for (i = 0; i < 4; i++) {
>   tunnel_filter_conf.ip_addr.ipv6_addr[i] =
> +#ifdef RTE_EXEC_ENV_BSDAPP
> + 
> rte_be_to_cpu_32(res->ip_value.addr.ipv6.__u6_addr.__u6_addr32[i]);
> +#else
>   rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> +#endif

Why not always use .__u6_addr.__u6_addr32[i] and avoid ifdef?

Sergio

>   }
>   tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV6;
>   }



[dpdk-dev] [PATCH] testpmd: fix build on FreeBSD

2016-03-21 Thread Mrzyglod, DanielX T
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marvin Liu
>Sent: Monday, March 21, 2016 2:45 AM
>To: dev at dpdk.org
>Cc: Liu, Yong 
>Subject: [dpdk-dev] [PATCH] testpmd: fix build on FreeBSD
>
>Build log:
>/root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
>'s6_addr32' in 'struct in6_addr'
>   rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
>
>This is caused by macro "s6_addr32" not defined on FreeBSD.
>
>Signed-off-by: Marvin Liu 

Acked-by: Daniel Mrzyglod 


[dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of compiler ones.

2016-03-21 Thread Ilya Maximets


On 18.03.2016 15:41, Yuanhan Liu wrote:
> On Fri, Mar 18, 2016 at 03:23:53PM +0300, Ilya Maximets wrote:
>> Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virtio
>> uses architecture dependent SMP barriers. vHost should use them too.
>>
>> Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers")
>>
>> Signed-off-by: Ilya Maximets 
>> ---
>>  lib/librte_vhost/vhost_rxtx.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
>> index b4da665..859c669 100644
>> --- a/lib/librte_vhost/vhost_rxtx.c
>> +++ b/lib/librte_vhost/vhost_rxtx.c
>> @@ -315,7 +315,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
>>  rte_prefetch0(>desc[desc_indexes[i+1]]);
>>  }
>>  
>> -rte_compiler_barrier();
>> +rte_smp_wmb();
>>  
>>  /* Wait until it's our turn to add our buffer to the used ring. */
>>  while (unlikely(vq->last_used_idx != res_start_idx))
>> @@ -565,7 +565,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t 
>> queue_id,
>>  
>>  nr_used = copy_mbuf_to_desc_mergeable(dev, vq, start, end,
>>pkts[pkt_idx]);
>> -rte_compiler_barrier();
>> +rte_smp_wmb();
>>  
>>  /*
>>   * Wait until it's our turn to add our buffer
>> @@ -923,7 +923,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
>> queue_id,
>>  sizeof(vq->used->ring[used_idx]));
>>  }
>>  
>> -rte_compiler_barrier();
>> +rte_smp_wmb();
>> +rte_smp_rmb();
> 
> rte_smp_mb?

rte_smp_mb() is a real mm_fence() on x86. And we don't need to synchronize 
reads with
writes here, only reads with reads and writes with writes. It is enough because 
next
increment uses read and write. Pair of barriers is better because it will not 
impact
on performance on x86.

Best regards, Ilya Maximets.


[dpdk-dev] [PATCH v5 9/9] testpmd: extend flow director commands

2016-03-21 Thread Zhang, Helin


> -Original Message-
> From: Wu, Jingjing
> Sent: Monday, March 21, 2016 2:19 PM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin
> Subject: [PATCH v5 9/9] testpmd: extend flow director commands
> 
> This patch extended commands for filter's input set changing.
> It added vlan as filter's input fields.
> 
> Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 


[dpdk-dev] [PATCH v5 8/9] i40e: extend flow director to filter by vlan id

2016-03-21 Thread Zhang, Helin


> -Original Message-
> From: Wu, Jingjing
> Sent: Monday, March 21, 2016 2:19 PM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin
> Subject: [PATCH v5 8/9] i40e: extend flow director to filter by vlan id
> 
> This patch extended flow director to select vlan id as filter's input set and
> program the filter rule with vlan id.
> 
> Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 


[dpdk-dev] [PATCH v3 4/4] eal/arm: introduce CONFIG_RTE_ARCH_ARM_NEON_MEMCPY

2016-03-21 Thread Thomas Monjalon
2016-03-21 13:21, Jan Viktorin:
> On Mon, 21 Mar 2016 13:42:31 +0800
> Jianbo Liu  wrote:
> 
> > On 20 March 2016 at 03:58, Jan Viktorin  wrote:
> > > The flag is used to enable memcpy optimizations in EAL. As it is not 
> > > always
> > > the performance benefit, the flag allows to disable it.
> > >
> > > Signed-off-by: Jan Viktorin 
> > > ---
> > >  config/defconfig_arm-armv7a-linuxapp-gcc   | 1 +
> > >  lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 8 ++--
> > >  2 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
> > > b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > index 96c3343..2c60c2c 100644
> > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > @@ -36,6 +36,7 @@ CONFIG_RTE_ARCH="arm"
> > >  CONFIG_RTE_ARCH_ARM=y
> > >  CONFIG_RTE_ARCH_ARMv7=y
> > >  CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
> > > +CONFIG_RTE_ARCH_ARM_NEON_MEMCPY=y
> > >  
> > If it's not always benefit, why not disable here since it is common
> > armv7a config, and enable in your or other user's own config file?
> 
> Jianbo, you are right. In that case, I'd just turn it off by default.
> And when there is a new platform-specific defconfig, it can enable it.
> 
> Anyway, I am thinking of adding some comment into the rte_memcpy_32.h
> file describing the potential of the NEON code. What about:
> 
> /* Enable in your defconfig to accelerate memcpy operations. Consider
>enabling this for Cortex-A15. For Cortex-A7 and Cortex-A9, It might
>accelerate short data copies (< 64 B). */
> 
> Thomas, do you consider this enough?

Yes it is perfect.
Why not put it in defconfig_arm-armv7a-linuxapp-gcc?