[dpdk-dev] [PATCH 3/4] vhost: log vring changes

[Xie, Huawei]

On 12/2/2015 10:09 PM, Victor Kaplansky wrote:
> On Wed, Dec 02, 2015 at 11:43:12AM +0800, Yuanhan Liu wrote:
>> Invoking vhost_log_write() to mark corresponding page as dirty while
>> updating used vring.
> Looks good, thanks!
>
> I didn't find where you log the dirty pages in result of data
> written to the buffers pointed by the descriptors in RX vring.
> AFAIU, the buffers of RX queue reside in guest's memory and have
> to be marked as dirty if they are written. What do you say?
Yes, that is actually the majority of the work.
Besides, in the first version, we could temporarily ignore zero copy,
which is much more complicated, as we have no idea when the page has
been accessed.
-- Huawei
>
> -- Victor
>
>

[dpdk-dev] [PATCH 2/4] vhost: introduce vhost_log_write

[Xie, Huawei]

On 12/2/2015 9:53 PM, Victor Kaplansky wrote:
> On Wed, Dec 02, 2015 at 11:43:11AM +0800, Yuanhan Liu wrote:
>> Introduce vhost_log_write() helper function to log the dirty pages we
>> touched. Page size is harded code to 4096 (VHOST_LOG_PAGE), and each
>> log is presented by 1 bit.
>>
>> Therefore, vhost_log_write() simply finds the right bit for related
>> page we are gonna change, and set it to 1. dev->log_base denotes the
>> start of the dirty page bitmap.
>>
>> The page address is biased by log_guest_addr, which is derived from
>> SET_VRING_ADDR request as part of the vring related addresses.
>>
>> Signed-off-by: Yuanhan Liu 
>> ---
>>  lib/librte_vhost/rte_virtio_net.h | 34 ++
>>  lib/librte_vhost/virtio-net.c |  4 
>>  2 files changed, 38 insertions(+)
>>
>> diff --git a/lib/librte_vhost/rte_virtio_net.h 
>> b/lib/librte_vhost/rte_virtio_net.h
>> index 416dac2..191c1be 100644
>> --- a/lib/librte_vhost/rte_virtio_net.h
>> +++ b/lib/librte_vhost/rte_virtio_net.h
>> @@ -40,6 +40,7 @@
>>   */
>>  
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -59,6 +60,8 @@ struct rte_mbuf;
>>  /* Backend value set by guest. */
>>  #define VIRTIO_DEV_STOPPED -1
>>  
>> +#define VHOST_LOG_PAGE  4096
>> +
>>  
>>  /* Enum for virtqueue management. */
>>  enum {VIRTIO_RXQ, VIRTIO_TXQ, VIRTIO_QNUM};
>> @@ -82,6 +85,7 @@ struct vhost_virtqueue {
>>  struct vring_desc   *desc;  /**< Virtqueue 
>> descriptor ring. */
>>  struct vring_avail  *avail; /**< Virtqueue 
>> available ring. */
>>  struct vring_used   *used;  /**< Virtqueue used 
>> ring. */
>> +uint64_tlog_guest_addr; /**< Physical address 
>> of used ring, for logging */
>>  uint32_tsize;   /**< Size of descriptor 
>> ring. */
>>  uint32_tbackend;/**< Backend value to 
>> determine if device should started/stopped. */
>>  uint16_tvhost_hlen; /**< Vhost header 
>> length (varies depending on RX merge buffers. */
>> @@ -203,6 +207,36 @@ gpa_to_vva(struct virtio_net *dev, uint64_t guest_pa)
>>  return vhost_va;
>>  }
>>  
>> +static inline void __attribute__((always_inline))
>> +vhost_log_page(uint8_t *log_base, uint64_t page)
>> +{
>> +/* TODO: to make it atomic? */
>> +log_base[page / 8] |= 1 << (page % 8);
> I think the atomic OR operation is necessary only if there can be
> more than one vhost-user back-end updating the guest's memory
> simultaneously. However probably it is pretty safe to perform
> regular OR operation, since rings are not shared between
> back-end. What about buffers pointed by descriptors?  To be on
> the safe side, I would use a GCC built-in function
> __sync_fetch_and_or(). 
>
>> +}
>> +
>> +static inline void __attribute__((always_inline))
>> +vhost_log_write(struct virtio_net *dev, struct vhost_virtqueue *vq,
>> +uint64_t offset, uint64_t len)
>> +{
>> +uint64_t addr = vq->log_guest_addr;
>> +uint64_t page;
>> +
>> +if (unlikely(((dev->features & (1ULL << VHOST_F_LOG_ALL)) == 0) ||
>> + !dev->log_base || !len))
>> +return;
> Isn't "likely" more appropriate in above, since the whole
> expression is expected to be true most of the time?
Victor:
So we are not always logging, what is the message that tells the backend
the migration is started?
[...]

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Xie, Huawei]

On 12/2/2015 11:40 AM, Yuanhan Liu wrote:
> This patch set adds the initial vhost-user live migration support.
>
> The major task behind that is to log pages we touched during
> live migration. So, this patch is basically about adding vhost
> log support, and using it.
>
> Patchset
> 
> - Patch 1 handles VHOST_USER_SET_LOG_BASE, which tells us where
>   the dirty memory bitmap is.
> 
> - Patch 2 introduces a vhost_log_write() helper function to log
>   pages we are gonna change.
>
> - Patch 3 logs changes we made to used vring.
>
> - Patch 4 sets log_fhmfd protocol feature bit, which actually
>   enables the vhost-user live migration support.
>
> A simple test guide (on same host)
> ==
>
> The following test is based on OVS + DPDK. And here is guide
> to setup OVS + DPDK:
>
> http://wiki.qemu.org/Features/vhost-user-ovs-dpdk
>
> 1. start ovs-vswitchd
>
> 2. Add two ovs vhost-user port, say vhost0 and vhost1
>
> 3. Start a VM1 to connect to vhost0. Here is my example:
>
>$QEMU -enable-kvm -m 1024 -smp 4 \
>-chardev socket,id=char0,path=/var/run/openvswitch/vhost0  \
>-netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
>-device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 \
>-object 
> memory-backend-file,id=mem,size=1024M,mem-path=$HOME/hugetlbfs,share=on \
>-numa node,memdev=mem -mem-prealloc \
>-kernel $HOME/iso/vmlinuz -append "root=/dev/sda1" \
>-hda fc-19-i386.img \
>-monitor telnet::,server,nowait -curses
>
> 4. run "ping $host" inside VM1
>
> 5. Start VM2 to connect to vhost0, and marking it as the target
>of live migration (by adding -incoming tcp:0: option)
>
>$QEMU -enable-kvm -m 1024 -smp 4 \
>-chardev socket,id=char0,path=/var/run/openvswitch/vhost1  \
>-netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
>-device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 \
>-object 
> memory-backend-file,id=mem,size=1024M,mem-path=$HOME/hugetlbfs,share=on \
>-numa node,memdev=mem -mem-prealloc \
>-kernel $HOME/iso/vmlinuz -append "root=/dev/sda1" \
>-hda fc-19-i386.img \
>-monitor telnet::3334,server,nowait -curses \
>-incoming tcp:0: 
>
> 6. connect to VM1 monitor, and start migration:
>
>> migrate tcp:0:
>
> 7. After a while, you will find that VM1 has been migrated to VM2,
>and the "ping" command continues running, perfectly.
Is there some formal verification that migration is truly successful? At
least that the memory we care in our vhost-user case has been migrated
successfully?
For instance, we miss logging guest RX buffers in this patch set, but we
have no idea.

[...]

[dpdk-dev] [PATCH 2/4] vhost: introduce vhost_log_write

[Yuanhan Liu]

On Wed, Dec 09, 2015 at 03:33:16AM +, Xie, Huawei wrote:
...
> >> +static inline void __attribute__((always_inline))
> >> +vhost_log_write(struct virtio_net *dev, struct vhost_virtqueue *vq,
> >> +  uint64_t offset, uint64_t len)
> >> +{
> >> +  uint64_t addr = vq->log_guest_addr;
> >> +  uint64_t page;
> >> +
> >> +  if (unlikely(((dev->features & (1ULL << VHOST_F_LOG_ALL)) == 0) ||
> >> +   !dev->log_base || !len))
> >> +  return;
> > Isn't "likely" more appropriate in above, since the whole
> > expression is expected to be true most of the time?
> Victor:
> So we are not always logging, what is the message that tells the backend
> the migration is started?

When log starts, VHOST_USER_SET_FEATURES request will be sent again,
with VHOST_F_LOG_ALL feature bit set.

--yliu

[dpdk-dev] [PATCH] librte_hash: Fix compile errors on IBM POWER

[Chao Zhu]

Jerin,

Both stdio.h and stddef.h works on POWER.  To make it work on ARM, I'll 
use stddef.h and submit another patch.
Thanks!

On 2015/12/8 17:10, Jerin Jacob wrote:
> On Tue, Dec 08, 2015 at 04:28:52PM +0800, Chao Zhu wrote:
>> This patch fixes the compile errors caused by lacking of "size_t" definition 
>> in rte_hash.h.
>>
>> Signed-off-by: Chao Zhu 
>> ---
>>   lib/librte_hash/rte_hash.h |1 +
>>   1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
>> index 6494ade..5046e9b 100644
>> --- a/lib/librte_hash/rte_hash.h
>> +++ b/lib/librte_hash/rte_hash.h
>> @@ -41,6 +41,7 @@
>>*/
>>   
>>   #include 
>> +#include 
> Thanks for the patch.
> The Same issue comes with arm64 GCC 5.2 compiler too.
> Shouldn't be stddef.h instead of stdio.h?
>
>>   
>>   #ifdef __cplusplus
>>   extern "C" {
>> -- 
>> 1.7.1
>>

[dpdk-dev] [PATCH] librte_hash: Fix compile errors on IBM POWER

[Chao Zhu]

This patch fixes the compile errors caused by lacking of "size_t" definition in 
rte_hash.h. The
compile error exists on IBM POWER and ARM (see jerin.jacob at 
caviumnetworks.com's message).

The errors are like:
In file included from /tmp/dpdk/app/test/test_hash_scaling.c:35:0:
/tmp/dpdk/build/include/rte_hash.h:70:70: error: unknown type name ?size_t?
 typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, size_t 
key_len);
  ^
/tmp/dpdk/build/include/rte_hash.h:120:48: error: unknown type name 
?rte_hash_cmp_eq_t?
 void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func);

Signed-off-by: Chao Zhu 
---
 lib/librte_hash/rte_hash.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index 6494ade..85fc416 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -41,6 +41,7 @@
  */

 #include 
+#include 

 #ifdef __cplusplus
 extern "C" {
-- 
1.7.1

[dpdk-dev] Coverity runs

[Vithal Mohare]

Hi,

Recently upgraded to DPDK version 2.1 and we run coverity periodically.  
Coverity throwing quite a few warnings and most of them sounds serious issues 
too.  Wondering if coverity is run on released versions of dpdk or any plans to 
do so in future, if not being done so far.

Thanks,
-Vithal

[dpdk-dev] Coverity runs

[Vithal Mohare]

Sorry for my ignorance, going through archives found coverity related 
discussions.  So, coverity is being run, but rel version 2.1 still has warnings 
left, may be marked as 'ignore'.

Thanks,
-Vithal

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Vithal Mohare
Sent: 09 December 2015 AM 10:03
To: dev at dpdk.org
Subject: [dpdk-dev] Coverity runs

Hi,

Recently upgraded to DPDK version 2.1 and we run coverity periodically.  
Coverity throwing quite a few warnings and most of them sounds serious issues 
too.  Wondering if coverity is run on released versions of dpdk or any plans to 
do so in future, if not being done so far.

Thanks,
-Vithal

[dpdk-dev] [PATCH] librte_hash: Fix compile errors on IBM POWER

[Jerin Jacob]

On Wed, Dec 09, 2015 at 12:11:47PM +0800, Chao Zhu wrote:
> This patch fixes the compile errors caused by lacking of "size_t" definition 
> in rte_hash.h. The
> compile error exists on IBM POWER and ARM (see jerin.jacob at 
> caviumnetworks.com's message).

remove relative references from git log,

- compile error exists on IBM POWER and ARM (see jerin.jacob at 
caviumnetworks.com's message).
+ compile error exists on IBM POWER and ARM64 GCC 5.2


> 
> The errors are like:
> In file included from /tmp/dpdk/app/test/test_hash_scaling.c:35:0:
> /tmp/dpdk/build/include/rte_hash.h:70:70: error: unknown type name ?size_t?
>  typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, size_t 
> key_len);
>   ^
> /tmp/dpdk/build/include/rte_hash.h:120:48: error: unknown type name 
> ?rte_hash_cmp_eq_t?
>  void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func);

add fixes:

Fixes: 95da2f8e9c61 ("hash: customize compare function")

with above changes,

Acked-by: Jerin Jacob 

> 
> Signed-off-by: Chao Zhu 
> ---
>  lib/librte_hash/rte_hash.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
> index 6494ade..85fc416 100644
> --- a/lib/librte_hash/rte_hash.h
> +++ b/lib/librte_hash/rte_hash.h
> @@ -41,6 +41,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  #ifdef __cplusplus
>  extern "C" {
> -- 
> 1.7.1
> 

[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow

[Jijiang Liu]

The struct 'rte_eth_tunnel_flow' is only used by struct 'rte_eth_fdir_flow' 
now, but its name is generic,
and I plan to extend new fileds like below to support generic configuration for 
tunneling packet.

struct rte_eth_tunnel_flow {
enum rte_eth_fdir_tunnel_type tunnel_type; /**< Tunnel type to match. */
uint32_t tunnel_id;/**< Tunnel ID to match. 
TNI, VNI... */
uint16_t flags;
struct ether_addr outer_mac_src;
struct ether_addr outer_mac_dst;
union {
struct rte_eth_ipv4_flow outer_ipv4;
struct rte_eth_ipv6_flow outer_ipv6;
   };
uint16_t dst_port;
uint16_t src_port;
struct ether_addr mac_addr;/**< Mac address to match. */
union {
struct rte_eth_ipv4_flow ipv4;
struct rte_eth_ipv6_flow ipv6;
};
 };

Note: It have not finalized yet.

Signed-off-by: Jijiang Liu 
---
 doc/guides/rel_notes/deprecation.rst |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 1c7ab01..5c458f2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -19,3 +19,7 @@ Deprecation Notices
   and table action handlers will be updated:
   the pipeline parameter will be added, the packets mask parameter will be
   either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned for struct rte_eth_tunnel_flow in order to extend 
new fileds to support
+  tunneling packet configuration in unified tunneling APIs. The release 2.2 
does not contain these ABI
+  changes, but release 2.3 will, and no backwards compatibility is planned.
-- 
1.7.7.6

[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_flow

[Lu, Wenzhuo]

Hi,

Acked-by: Wenzhuo Lu 

[dpdk-dev] [PATCH 2/4] vhost: introduce vhost_log_write

[Xie, Huawei]

On 12/9/2015 11:41 AM, Yuanhan Liu wrote:
> On Wed, Dec 09, 2015 at 03:33:16AM +, Xie, Huawei wrote:
> ...
 +static inline void __attribute__((always_inline))
 +vhost_log_write(struct virtio_net *dev, struct vhost_virtqueue *vq,
 +  uint64_t offset, uint64_t len)
 +{
 +  uint64_t addr = vq->log_guest_addr;
 +  uint64_t page;
 +
 +  if (unlikely(((dev->features & (1ULL << VHOST_F_LOG_ALL)) == 0) ||
 +   !dev->log_base || !len))
 +  return;
>>> Isn't "likely" more appropriate in above, since the whole
>>> expression is expected to be true most of the time?
>> Victor:
>> So we are not always logging, what is the message that tells the backend
>> the migration is started?
> When log starts, VHOST_USER_SET_FEATURES request will be sent again,
> with VHOST_F_LOG_ALL feature bit set.
As the VHOST_USER_SET_FEATURES handling and rx/tx runs asynchronously,
we have to make sure we don't miss logging anything when this feature is
set. For example, I doubt like in virtio_dev_rx, is the dev->features
volatile?
>   --yliu
>

[dpdk-dev] ivshmem mmap to specific address

[Eli Britstein]

Hello,



In librte_eal, in eal_ivshmem.c, in function map_all_segments, there is mapping 
of segments from the metadata to the same virtual address as written in the 
metadata.

Is there a method to guarantee that this mapping won't fail, even for different 
processes, that might have large code or constructors running even before main?



Thanks,

Eli



-
This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.

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

[Panu Matilainen]

On 12/08/2015 05:33 PM, Kamil Rytarowski wrote:
> Currently rte_eal_check_module() detects Linux kernel modules via reading
> /proc/modules. Built-in ones aren't listed there and therefore they are not
> being found by the script.
>
> Add support for checking built-in modules with parsing the sysfs files
>
> This commit obsoletes the /proc/modules parsing approach.
>
> Signed-off-by: Kamil Rytarowski 
> Signed-off-by: David Marchand 
> ---
>   lib/librte_eal/linuxapp/eal/eal.c | 34 --
>   1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
> b/lib/librte_eal/linuxapp/eal/eal.c
> index 635ec36..92482a0 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -901,27 +901,33 @@ int rte_eal_has_hugepages(void)
>   int
>   rte_eal_check_module(const char *module_name)
>   {
> - char mod_name[30]; /* Any module names can be longer than 30 bytes? */
> - int ret = 0;
> + char sysfs_mod_name[PATH_MAX];
> + struct stat st;
>   int n;
>
>   if (NULL == module_name)
>   return -1;
>
> - FILE *fd = fopen("/proc/modules", "r");
> - if (NULL == fd) {
> - RTE_LOG(ERR, EAL, "Open /proc/modules failed!"
> - " error %i (%s)\n", errno, strerror(errno));
> + /* Check if there is sysfs mounted */
> + if (stat("/sys/module", &st) != 0) {
> + RTE_LOG(DEBUG, EAL, "sysfs is not mounted! error %i (%s)\n",
> + errno, strerror(errno));
>   return -1;
>   }
> - while (!feof(fd)) {
> - n = fscanf(fd, "%29s %*[^\n]", mod_name);
> - if ((n == 1) && !strcmp(mod_name, module_name)) {
> - ret = 1;
> - break;
> - }
> +
> + /* A module might be built-in, therefore try sysfs */
> + n = snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", module_name);
> + if (n < 0 || n > PATH_MAX) {
> + RTE_LOG(DEBUG, EAL, "Could not format module path\n");
> + return -1;
>   }
> - fclose(fd);
>
> - return ret;
> + if (stat(sysfs_mod_name, &st) != 0) {
> + RTE_LOG(DEBUG, EAL, "Open %s failed! error %i (%s)\n",
> + sysfs_mod_name, errno, strerror(errno));
> + return 0;
> + }

Like with /sys/module, its not trying to *open* sysfs_mod_name directory 
either so it shouldn't claim to do so.

I did use plural on purpose when I said "the debug messages are 
incorrect/misleading. It's certainly not trying to *open* these 
directories so it should not claim to do so" in my previous mail :)

- Panu -

[dpdk-dev] [PATCH] mk: fix install with minimal shell

[Thomas Monjalon]

Some shells like dash do not support the syntax {}:
{mk,scripts}: No such file or directory

Reported-by: Thiago Martins 
Reported-by: Piotr Bartosiewicz 
Signed-off-by: Thomas Monjalon 
---
 mk/rte.sdkinstall.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index c611d45..c159bf7 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -139,7 +139,8 @@ install-sdk:
tar -xf -  -C $(DESTDIR)$(includedir) --strip-components=1 \
--keep-newer-files --warning=no-ignore-newer
$(Q)$(call rte_mkdir,$(DESTDIR)$(sdkdir))
-   $(Q)cp -a   $(RTE_SDK)/{mk,scripts}  $(DESTDIR)$(sdkdir)
+   $(Q)cp -a   $(RTE_SDK)/mk$(DESTDIR)$(sdkdir)
+   $(Q)cp -a   $(RTE_SDK)/scripts   $(DESTDIR)$(sdkdir)
$(Q)$(call rte_mkdir,$(DESTDIR)$(targetdir))
$(Q)cp -a   $O/.config   $(DESTDIR)$(targetdir)
$(Q)$(call rte_symlink, $(DESTDIR)$(includedir), 
$(DESTDIR)$(targetdir)/include)
-- 
2.5.2

[dpdk-dev] [PATCH] doc: add fm10k driver

[Chen Jing D(Mark)]

From: "Chen Jing D(Mark)" 

This documentation covers introdutions and limitations on Intel
FM1 series products.

Signed-off-by: Chen Jing D(Mark) 
---
 doc/guides/nics/fm10k.rst |   54 +
 doc/guides/nics/index.rst |1 +
 2 files changed, 55 insertions(+), 0 deletions(-)
 create mode 100644 doc/guides/nics/fm10k.rst

diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst
new file mode 100644
index 000..1c7ca57
--- /dev/null
+++ b/doc/guides/nics/fm10k.rst
@@ -0,0 +1,54 @@
+..  BSD LICENSE
+Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+FM10K Poll Mode Driver
+==
+The FM10K poll mode driver library provides support for Intel FM1 family
+of 40GbE/100GbE adapters.
+
+Limitations
+---
+Intel FM1 family of NICs integrate an hardware switch and multiple host
+interfaces. FM10K PMD driver only manages host interfaces. For the switch
+component, another switch driver has to be loaded prior to FM10K PMD driver.
+The switch driver either can be acquired by Intel support or from below link:
+https://github.com/match-interface
+
+CRC strip
+FM1 family always strip CRC for every packets coming into host interface.
+So, CRC will be stripped even (struct rte_eth_conf).rxmode.hw_strip_crc is set
+to 0.
+
+Max packet length
+FM1 family support maximum of 15K jumbo frame. The value is fixed and can't
+be changed. So, even (struct rte_eth_conf).rxmode.max_rx_pkt_len is set to a 
value
+other than 15364, the frames with 15364 byte still can reach to host interface.
+
+
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 7bf2938..4f2cc6c 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -51,6 +51,7 @@ Network Interface Controller Drivers
 virtio
 vmxnet3
 pcap_ring
+fm10k

 **Figures**

-- 
1.7.7.6

[dpdk-dev] [PATCH v1 1/1] example/ip_pipeline: fix memcpy issue

[Azarewicz, PiotrX T]

> -Original Message-
> From: Mcnamara, John
> Sent: Tuesday, December 8, 2015 6:00 PM
> To: Mcnamara, John ; Azarewicz, PiotrX T
> ; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v1 1/1] example/ip_pipeline: fix memcpy
> issue
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John
> > Sent: Tuesday, December 8, 2015 2:47 PM
> > To: Azarewicz, PiotrX T; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1 1/1] example/ip_pipeline: fix memcpy
> > issue
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Piotr Azarewicz
> > > Sent: Tuesday, December 8, 2015 2:17 PM
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] [PATCH v1 1/1] example/ip_pipeline: fix memcpy
> > > issue
> > >
> > > The cmds and thread_cmds both are the arrays of cmdline_parse_ctx_t.
> > > So the goal is to copy elements size of cmdline_parse_ctx_t not
> > > cmdline_parse_ctx_t*.
> > >
> > > Coverity issue: 120412
> > > Fixes: b4aee0fb9c6d ("examples/ip_pipeline: reconfigure thread
> > > binding
> > > dynamically")
> > >
> > > Signed-off-by: Piotr Azarewicz 
> >
> > Acked-by: John McNamara 
> 
> Hi Piotr,
> 
> This issue occurs copy and pasted in two other locations as well:
> 
> examples/ip_pipeline/pipeline/pipeline_common_fe.c
> 1295:   n_cmds * sizeof(cmdline_parse_ctx_t *));
> 
> examples/ip_pipeline/thread_fe.c
> 340:n_cmds * sizeof(cmdline_parse_ctx_t *));
> 
> examples/ip_pipeline/init.c
> 1475:   n_cmds * sizeof(cmdline_parse_ctx_t *));
> 
> Perhaps you could fix those in the same patch.
> 
> Thanks,
> 
> John
> 
> 

Yes, you are right, thanks. I will send v2.

Piotr

[dpdk-dev] [PATCH 2/4] vhost: introduce vhost_log_write

[Yuanhan Liu]

On Wed, Dec 09, 2015 at 05:44:11AM +, Xie, Huawei wrote:
> On 12/9/2015 11:41 AM, Yuanhan Liu wrote:
> > On Wed, Dec 09, 2015 at 03:33:16AM +, Xie, Huawei wrote:
> > ...
>  +static inline void __attribute__((always_inline))
>  +vhost_log_write(struct virtio_net *dev, struct vhost_virtqueue *vq,
>  +uint64_t offset, uint64_t len)
>  +{
>  +uint64_t addr = vq->log_guest_addr;
>  +uint64_t page;
>  +
>  +if (unlikely(((dev->features & (1ULL << VHOST_F_LOG_ALL)) == 0) 
>  ||
>  + !dev->log_base || !len))
>  +return;
> >>> Isn't "likely" more appropriate in above, since the whole
> >>> expression is expected to be true most of the time?
> >> Victor:
> >> So we are not always logging, what is the message that tells the backend
> >> the migration is started?
> > When log starts, VHOST_USER_SET_FEATURES request will be sent again,
> > with VHOST_F_LOG_ALL feature bit set.
> As the VHOST_USER_SET_FEATURES handling and rx/tx runs asynchronously,
> we have to make sure we don't miss logging anything when this feature is
> set.

That's a good remind. Thanks.

> For example, I doubt like in virtio_dev_rx, is the dev->features
> volatile?

No, it is not volatile.

--yliu

[dpdk-dev] [PATCH] ip_pipeline: Fix compile issue with strict-aliasing

[Michael Qiu]

From: root 

strict-aliasing

Signed-off-by: Michael Qiu 
---
 .../ip_pipeline/pipeline/pipeline_routing_be.c |   11 ---
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/examples/ip_pipeline/pipeline/pipeline_routing_be.c 
b/examples/ip_pipeline/pipeline/pipeline_routing_be.c
index 4a95c7d..9baabd0 100644
--- a/examples/ip_pipeline/pipeline/pipeline_routing_be.c
+++ b/examples/ip_pipeline/pipeline/pipeline_routing_be.c
@@ -1461,8 +1461,7 @@ pipeline_routing_msg_req_route_add_handler(struct 
pipeline *p, void *msg)
uint64_t macaddr_dst;
uint64_t ethertype = ETHER_TYPE_IPv4;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

entry_arp0.slab[0] =
@@ -1503,8 +1502,7 @@ pipeline_routing_msg_req_route_add_handler(struct 
pipeline *p, void *msg)
uint64_t svlan = req->data.l2.qinq.svlan;
uint64_t cvlan = req->data.l2.qinq.cvlan;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

entry_arp0.slab[0] = rte_bswap64((svlan << 48) |
@@ -1563,8 +1561,7 @@ pipeline_routing_msg_req_route_add_handler(struct 
pipeline *p, void *msg)
uint64_t label3 = req->data.l2.mpls.labels[3];
uint32_t n_labels = req->data.l2.mpls.n_labels;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

switch (n_labels) {
@@ -1814,7 +1811,7 @@ pipeline_routing_msg_req_arp_add_handler(struct pipeline 
*p, void *msg)
return rsp;
}

-   *((struct ether_addr *) &entry.macaddr) = req->macaddr;
+   entry.macaddr = *((uint64_t *)&(req->macaddr));
entry.macaddr = entry.macaddr << 16;

rsp->status = rte_pipeline_table_entry_add(p->p,
-- 
1.7.1

[dpdk-dev] [PATCH] ip_pipeline: Fix compile issue with strict-aliasing

[Qiu, Michael]

Sorry please ignore this :)

Thanks,
Michael

-Original Message-
From: Qiu, Michael 
Sent: Wednesday, December 9, 2015 4:40 PM
To: dev at dpdk.org
Cc: Singh, Jasvinder; Dumitrescu, Cristian; root; Qiu, Michael
Subject: [PATCH] ip_pipeline: Fix compile issue with strict-aliasing

From: root 

strict-aliasing

Signed-off-by: Michael Qiu 
---
 .../ip_pipeline/pipeline/pipeline_routing_be.c |   11 ---
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/examples/ip_pipeline/pipeline/pipeline_routing_be.c 
b/examples/ip_pipeline/pipeline/pipeline_routing_be.c
index 4a95c7d..9baabd0 100644
--- a/examples/ip_pipeline/pipeline/pipeline_routing_be.c
+++ b/examples/ip_pipeline/pipeline/pipeline_routing_be.c
@@ -1461,8 +1461,7 @@ pipeline_routing_msg_req_route_add_handler(struct 
pipeline *p, void *msg)
uint64_t macaddr_dst;
uint64_t ethertype = ETHER_TYPE_IPv4;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

entry_arp0.slab[0] =
@@ -1503,8 +1502,7 @@ pipeline_routing_msg_req_route_add_handler(struct 
pipeline *p, void *msg)
uint64_t svlan = req->data.l2.qinq.svlan;
uint64_t cvlan = req->data.l2.qinq.cvlan;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

entry_arp0.slab[0] = rte_bswap64((svlan << 48) | @@ -1563,8 
+1561,7 @@ pipeline_routing_msg_req_route_add_handler(struct pipeline *p, void 
*msg)
uint64_t label3 = req->data.l2.mpls.labels[3];
uint32_t n_labels = req->data.l2.mpls.n_labels;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

switch (n_labels) {
@@ -1814,7 +1811,7 @@ pipeline_routing_msg_req_arp_add_handler(struct pipeline 
*p, void *msg)
return rsp;
}

-   *((struct ether_addr *) &entry.macaddr) = req->macaddr;
+   entry.macaddr = *((uint64_t *)&(req->macaddr));
entry.macaddr = entry.macaddr << 16;

rsp->status = rte_pipeline_table_entry_add(p->p,
--
1.7.1

[dpdk-dev] [PATCH] examples/ip_pipeline: Fix compile issue with strict-aliasing

[Michael Qiu]

Compile ip_pipeline in CentOS 6.5 with kernel 2.6.32-431
GCC 4.4.7, will lead below error:

pipeline_routing_be.c: In function 
?pipeline_routing_msg_req_arp_add_handler?:
pipeline_routing_be.c:1817: error: dereferencing pointer ?({anonymous})?
does break strict-aliasing rules

This because the code break strict-aliasing rule.
The patch solve this issue.

Fixes: 0ae7275810f1 (examples/ip_pipeline: add more functions to routing 
pipeline)

Signed-off-by: Michael Qiu 
---
 examples/ip_pipeline/pipeline/pipeline_routing_be.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/examples/ip_pipeline/pipeline/pipeline_routing_be.c 
b/examples/ip_pipeline/pipeline/pipeline_routing_be.c
index 4a95c7d..9baabd0 100644
--- a/examples/ip_pipeline/pipeline/pipeline_routing_be.c
+++ b/examples/ip_pipeline/pipeline/pipeline_routing_be.c
@@ -1461,8 +1461,7 @@ pipeline_routing_msg_req_route_add_handler(struct 
pipeline *p, void *msg)
uint64_t macaddr_dst;
uint64_t ethertype = ETHER_TYPE_IPv4;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

entry_arp0.slab[0] =
@@ -1503,8 +1502,7 @@ pipeline_routing_msg_req_route_add_handler(struct 
pipeline *p, void *msg)
uint64_t svlan = req->data.l2.qinq.svlan;
uint64_t cvlan = req->data.l2.qinq.cvlan;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

entry_arp0.slab[0] = rte_bswap64((svlan << 48) |
@@ -1563,8 +1561,7 @@ pipeline_routing_msg_req_route_add_handler(struct 
pipeline *p, void *msg)
uint64_t label3 = req->data.l2.mpls.labels[3];
uint32_t n_labels = req->data.l2.mpls.n_labels;

-   *((struct ether_addr *) &macaddr_dst) =
-   req->data.ethernet.macaddr;
+   macaddr_dst = *((uint64_t *)&(req->data.ethernet.macaddr));
macaddr_dst = rte_bswap64(macaddr_dst << 16);

switch (n_labels) {
@@ -1814,7 +1811,7 @@ pipeline_routing_msg_req_arp_add_handler(struct pipeline 
*p, void *msg)
return rsp;
}

-   *((struct ether_addr *) &entry.macaddr) = req->macaddr;
+   entry.macaddr = *((uint64_t *)&(req->macaddr));
entry.macaddr = entry.macaddr << 16;

rsp->status = rte_pipeline_table_entry_add(p->p,
-- 
1.9.3

[dpdk-dev] [PATCH] examples/vhost: fix strict aliasing error on gcc 4.4.7

[Xie, Huawei]

On 12/8/2015 7:24 PM, De Lara Guarch, Pablo wrote:
> Fixes following error on gcc 4.4.7:
>
> make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
>   CC main.o
> cc1: warnings being treated as errors
> /tmp/dpdk-tmp/examples/vhost/main.c: In function ?new_device?:
> /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
> dereferencing pointer ?mbuf.486? does break strict-aliasing rules
> /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> ...
> /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
> dereferencing pointer ?({anonymous})? does break strict-aliasing rules
> /tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
> make[1]: *** [main.o] Error 1
>
> Fixes: d19533e8 ("examples/vhost: copy old vhost example")
>
> Reported-by: Qian Xu 
> Signed-off-by: Pablo de Lara 
> ---
>  examples/vhost/main.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
[...]
>  
> - rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
> + rte_ring_sc_dequeue(vpool->ring, (void **)&obj);
> + mbuf = (struct rte_mbuf *)obj;
Is rte_ring_sc_dequeue(vpool->ring, &obj) enough? Applied to the later
enqueue as well.
>   if (unlikely(mbuf == NULL)) {
[...]
> - rte_ring_sp_enqueue(vpool->ring, (void *)mbuf);
> + rte_ring_sp_enqueue(vpool->ring, obj);
>   return;
>   }
>  
> @@ -1789,7 +1791,8 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
> rte_mbuf *m,
>  {
>   
[...]
>   vpool = &vpool_array[MAX_QUEUES + vmdq_rx_q];
> - rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
> + rte_ring_sc_dequeue(vpool->ring, (void **)&obj);
> + mbuf = (struct rte_mbuf *) obj;
>   if (unlikely(mbuf == NULL)) {
>   struct vhost_virtqueue *vq = dev->virtqueue[VIRTIO_TXQ];
>   RTE_LOG(ERR, VHOST_DATA,

[dpdk-dev] [PATCH] examples/ip_pipeline: Fix compile issue with strict-aliasing

[Singh, Jasvinder]

> -Original Message-
> From: Qiu, Michael
> Sent: Wednesday, December 9, 2015 8:44 AM
> To: dev at dpdk.org
> Cc: Singh, Jasvinder; Dumitrescu, Cristian; Qiu, Michael
> Subject: [PATCH] examples/ip_pipeline: Fix compile issue with strict-aliasing
> 
> Compile ip_pipeline in CentOS 6.5 with kernel 2.6.32-431 GCC 4.4.7, will lead
> below error:
> 
> pipeline_routing_be.c: In function
> ?pipeline_routing_msg_req_arp_add_handler?:
> pipeline_routing_be.c:1817: error: dereferencing pointer ?({anonymous})?
>   does break strict-aliasing rules
> 
> This because the code break strict-aliasing rule.
> The patch solve this issue.
> 
> Fixes: 0ae7275810f1 (examples/ip_pipeline: add more functions to routing
> pipeline)
> 
> Signed-off-by: Michael Qiu 

Acked-by: Jasvinder Singh 

[dpdk-dev] [PATCH v2 1/1] example/ip_pipeline: fix memcpy issue

[Piotr Azarewicz]

The source and destination both are the arrays of cmdline_parse_ctx_t.
So the goal is to copy elements size of cmdline_parse_ctx_t not
cmdline_parse_ctx_t*.

Coverity issue: 120412
Fixes: b4aee0fb9c6d ("examples/ip_pipeline: reconfigure thread binding
dynamically")

Fixes: ea0908c4ab89 ("examples/ip_pipeline: add master pipeline")
Fixes: eb32fe7c5574 ("examples/ip_pipeline: rework initialization parameters")

Signed-off-by: Piotr Azarewicz 
---

v2 changes:
- add the same fix in two other places

 examples/ip_pipeline/init.c|2 +-
 examples/ip_pipeline/pipeline/pipeline_common_fe.c |2 +-
 examples/ip_pipeline/thread_fe.c   |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/examples/ip_pipeline/init.c b/examples/ip_pipeline/init.c
index 52aab53..bc6d6d9 100644
--- a/examples/ip_pipeline/init.c
+++ b/examples/ip_pipeline/init.c
@@ -1472,7 +1472,7 @@ app_pipeline_type_cmd_push(struct app_params *app,
/* Push pipeline commands into the application */
memcpy(&app->cmds[app->n_cmds],
cmds,
-   n_cmds * sizeof(cmdline_parse_ctx_t *));
+   n_cmds * sizeof(cmdline_parse_ctx_t));

for (i = 0; i < n_cmds; i++)
app->cmds[app->n_cmds + i]->data = app;
diff --git a/examples/ip_pipeline/pipeline/pipeline_common_fe.c 
b/examples/ip_pipeline/pipeline/pipeline_common_fe.c
index 87ec164..1e16ad6 100644
--- a/examples/ip_pipeline/pipeline/pipeline_common_fe.c
+++ b/examples/ip_pipeline/pipeline/pipeline_common_fe.c
@@ -1292,7 +1292,7 @@ app_pipeline_common_cmd_push(struct app_params *app)
/* Push pipeline commands into the application */
memcpy(&app->cmds[app->n_cmds],
pipeline_common_cmds,
-   n_cmds * sizeof(cmdline_parse_ctx_t *));
+   n_cmds * sizeof(cmdline_parse_ctx_t));

for (i = 0; i < n_cmds; i++)
app->cmds[app->n_cmds + i]->data = app;
diff --git a/examples/ip_pipeline/thread_fe.c b/examples/ip_pipeline/thread_fe.c
index 7a3bbf8..f1df05e 100644
--- a/examples/ip_pipeline/thread_fe.c
+++ b/examples/ip_pipeline/thread_fe.c
@@ -337,7 +337,7 @@ app_pipeline_thread_cmd_push(struct app_params *app)
/* Push thread commands into the application */
memcpy(&app->cmds[app->n_cmds],
thread_cmds,
-   n_cmds * sizeof(cmdline_parse_ctx_t *));
+   n_cmds * sizeof(cmdline_parse_ctx_t));

for (i = 0; i < n_cmds; i++)
app->cmds[app->n_cmds + i]->data = app;
-- 
1.7.9.5

[dpdk-dev] [PATCH v2] examples/vhost: fix strict aliasing error on gcc 4.4.7

[Pablo de Lara]

From: "De Lara Guarch, Pablo" 

Fixes following error on gcc 4.4.7:

make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
  CC main.o
cc1: warnings being treated as errors
/tmp/dpdk-tmp/examples/vhost/main.c: In function ?new_device?:
/tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
dereferencing pointer ?mbuf.486? does break strict-aliasing rules
/tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
...
/tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
/tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
dereferencing pointer ?({anonymous})? does break strict-aliasing rules
/tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
make[1]: *** [main.o] Error 1

Fixes: d19533e8 ("examples/vhost: copy old vhost example")

Reported-by: Qian Xu 
Signed-off-by: Pablo de Lara 
---
Changes in v2:
- Remove unnecessary casting

 examples/vhost/main.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index dc3a012..2000a3a 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -1449,7 +1449,8 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
uint64_t buff_addr, phys_addr;
struct vhost_virtqueue *vq;
struct vring_desc *desc;
-   struct rte_mbuf *mbuf = NULL;
+   void *obj = NULL;
+   struct rte_mbuf *mbuf;
struct vpool *vpool;
hpa_type addr_type;
struct vhost_dev *vdev = (struct vhost_dev *)dev->priv;
@@ -1500,7 +1501,8 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
}
} while (unlikely(phys_addr == 0));

-   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
+   rte_ring_sc_dequeue(vpool->ring, &obj);
+   mbuf = (struct rte_mbuf *)obj;
if (unlikely(mbuf == NULL)) {
LOG_DEBUG(VHOST_DATA,
"(%"PRIu64") in attach_rxmbuf_zcp: "
@@ -1517,7 +1519,7 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
"size required: %d\n",
dev->device_fh, desc->len, desc_idx, vpool->buf_size);
put_desc_to_used_list_zcp(vq, desc_idx);
-   rte_ring_sp_enqueue(vpool->ring, (void *)mbuf);
+   rte_ring_sp_enqueue(vpool->ring, obj);
return;
}

@@ -1789,7 +1791,8 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
rte_mbuf *m,
 {
struct mbuf_table *tx_q;
struct rte_mbuf **m_table;
-   struct rte_mbuf *mbuf = NULL;
+   void *obj = NULL;
+   struct rte_mbuf *mbuf;
unsigned len, ret, offset = 0;
struct vpool *vpool;
uint16_t vlan_tag = (uint16_t)vlan_tags[(uint16_t)dev->device_fh];
@@ -1801,7 +1804,8 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
rte_mbuf *m,

/* Allocate an mbuf and populate the structure. */
vpool = &vpool_array[MAX_QUEUES + vmdq_rx_q];
-   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
+   rte_ring_sc_dequeue(vpool->ring, &obj);
+   mbuf = (struct rte_mbuf *)obj;
if (unlikely(mbuf == NULL)) {
struct vhost_virtqueue *vq = dev->virtqueue[VIRTIO_TXQ];
RTE_LOG(ERR, VHOST_DATA,
-- 
2.5.0

[dpdk-dev] [PATCH v2] examples/vhost: fix strict aliasing error on gcc 4.4.7

[Bruce Richardson]

On Wed, Dec 09, 2015 at 09:39:59AM +, Pablo de Lara wrote:
> From: "De Lara Guarch, Pablo" 
> 
> Fixes following error on gcc 4.4.7:
> 
> make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
>   CC main.o
> cc1: warnings being treated as errors
> /tmp/dpdk-tmp/examples/vhost/main.c: In function ?new_device?:
> /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
> dereferencing pointer ?mbuf.486? does break strict-aliasing rules
> /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> ...
> /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
> dereferencing pointer ?({anonymous})? does break strict-aliasing rules
> /tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
> make[1]: *** [main.o] Error 1
> 
> Fixes: d19533e8 ("examples/vhost: copy old vhost example")
> 
> Reported-by: Qian Xu 
> Signed-off-by: Pablo de Lara 
> ---
> Changes in v2:
> - Remove unnecessary casting

You've remove some, but not all unnecessary casting. You don't need a cast when
assigning void * to any other type, so you can remove the mbuf casts too.

/Bruce

[dpdk-dev] ivshmem mmap to specific address

[Burakov, Anatoly]

Hi Eli

> Is there a method to guarantee that this mapping won't fail, even for
> different processes, that might have large code or constructors running even
> before main?

I'm afraid there is none. That's the nature of the beast. The best you can do 
is map stuff into a different address range using --base-virtaddr flag in the 
primary process and hope that this time your "large code or constructors 
running before main" won't tread into that virtual address space. But even that 
is not a guarantee by any means.

Thanks,
Anatoly

[dpdk-dev] dev Digest, Vol 68, Issue 68

[Betts, Ian]

Date: Fri, 27 Nov 2015 15:09:24 +0200
From: Panu Matilainen 
To: "Doherty, Declan" , Thomas Monjalon

Cc: "dev at dpdk.org" 
Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
Message-ID: <56585604.9030909 at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 11/26/2015 03:51 PM, Doherty, Declan wrote:
>> -Original Message-
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> Sent: Thursday, November 26, 2015 10:09 AM
>> To: Panu Matilainen; Doherty, Declan
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
>>
>> 2015-11-26 10:00, Panu Matilainen:
>>> On 11/26/2015 09:39 AM, Panu Matilainen wrote:
 On 11/25/2015 07:38 PM, Thomas Monjalon wrote:
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
>
>#
># Compile generic crypto device library
> +# EXPERIMENTAL: API may change without prior notice
>#
>CONFIG_RTE_LIBRTE_CRYPTODEV=y
>CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
 [...]

 I think an experimental library which declares itself exempt from the
 ABI policy should not be compiled by default. That way anybody wanting
 to try it out will be forced to notice the experimental status.

 More generally / longer term, perhaps there should be a
 CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
 defaults to off.
>>>
>>> On a related note, librte_mbuf_offload cannot be built if
>>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
>>> least currently) so tightly couple to cryptodev that perhaps it too
>>> should be marked experimental and default to off.
>>
>> I think you are right.
>> Declan, what is your opinion?
>
>
> Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's
> probably one of the areas which will most likely change in the future.
>
> On the issue of turning off experimental libraries in the build by default, my
> preference would be not to turn them off unless the library has external
> dependencies, otherwise the possibility of patches being submitted which
> could break an experimental library will be much higher. In my opinion the
> fewer build configurations developers have to test against the better.

>>What I'm more worried about is users and developers starting to rely on 
>>it while still in experimental state, a single comment in the header is 
>>really easy to miss.

>>So I'd like to see *some* mechanism which forces users and developers to 
>>acknowledge the fact that they're dealing with experimental work. 
>>Defaulting to off is one possibility, another one would be wrapping 
>>experimental APIs behind a define which you have to set to be able to 
>>use the API, eg:

>>#if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES)
>>[...]
>>#endif

>>  - Panu -

I can see alternative/complementary  that is to introduce a new "experimental" 
patch state in patchwork. 


This approach might be useful to get wider exposure and feedback on  
experimental work earlier in its lifecycle.
Experimental patches may be constrained to a limited subset of target and host 
environments.
Experimental patches should be based off of a stable dpdk release, but would 
not be applied in the release.

Whilst the objective would be that any such patch would mature to  become the 
kind of "experimental component" 
as proposed above in this thread, and/or eventually be adopted as a mainstream 
component, 
there would be no guarantee of that.

For the user it should very clearly be "Buyer beware" on such patches,  and for 
the
developer community the support burden should be solely  the responsibility of 
the
patch maintainer. 

The only reason to have a new patchwork state is to make it easier to filter 
them in patchwork.
Some way of publishing the list of experimental patches available for a release 
would be
helpful, maybe as an addendum to the release note ?

[dpdk-dev] [PATCH v2] examples/vhost: fix strict aliasing error on gcc 4.4.7

[Xie, Huawei]

On 12/9/2015 5:40 PM, De Lara Guarch, Pablo wrote:
> From: "De Lara Guarch, Pablo" 
>
> Fixes following error on gcc 4.4.7:
>
> make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
>   CC main.o
> cc1: warnings being treated as errors
> /tmp/dpdk-tmp/examples/vhost/main.c: In function ?new_device?:
> /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
> dereferencing pointer ?mbuf.486? does break strict-aliasing rules
> /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> ...
> /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
> dereferencing pointer ?({anonymous})? does break strict-aliasing rules
> /tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
> make[1]: *** [main.o] Error 1
>
> Fixes: d19533e8 ("examples/vhost: copy old vhost example")
>
> Reported-by: Qian Xu 
> Signed-off-by: Pablo de Lara 
Acked-by: Huawei Xie 

[dpdk-dev] [PATCH v2 1/1] example/ip_pipeline: fix memcpy issue

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Piotr Azarewicz
> Sent: Wednesday, December 9, 2015 9:34 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 1/1] example/ip_pipeline: fix memcpy issue
> 
> The source and destination both are the arrays of cmdline_parse_ctx_t.
> So the goal is to copy elements size of cmdline_parse_ctx_t not
> cmdline_parse_ctx_t*.
> 
> Coverity issue: 120412
> Fixes: b4aee0fb9c6d ("examples/ip_pipeline: reconfigure thread binding
> dynamically")
> 
> Fixes: ea0908c4ab89 ("examples/ip_pipeline: add master pipeline")
> Fixes: eb32fe7c5574 ("examples/ip_pipeline: rework initialization
> parameters")
> 
> Signed-off-by: Piotr Azarewicz 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v2] examples/vhost: fix strict aliasing error on gcc 4.4.7

[De Lara Guarch, Pablo]

Hi Huawei,

> -Original Message-
> From: Xie, Huawei
> Sent: Wednesday, December 09, 2015 10:45 AM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Cc: yuanhan.liu at linux.intel.com
> Subject: Re: [PATCH v2] examples/vhost: fix strict aliasing error on gcc 4.4.7
> 
> On 12/9/2015 5:40 PM, De Lara Guarch, Pablo wrote:
> > From: "De Lara Guarch, Pablo" 
> >
> > Fixes following error on gcc 4.4.7:
> >
> > make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
> >   CC main.o
> > cc1: warnings being treated as errors
> > /tmp/dpdk-tmp/examples/vhost/main.c: In function 'new_device':
> > /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740:
> error:
> > dereferencing pointer 'mbuf.486' does break strict-aliasing rules
> > /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> > ...
> > /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> > /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740:
> error:
> > dereferencing pointer '({anonymous})' does break strict-aliasing rules
> > /tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
> > make[1]: *** [main.o] Error 1
> >
> > Fixes: d19533e8 ("examples/vhost: copy old vhost example")
> >
> > Reported-by: Qian Xu 
> > Signed-off-by: Pablo de Lara 
> Acked-by: Huawei Xie 
> 

I am going to send a v3 for this patch, removing the other casting that Bruce 
mentioned.
I will pre-ack it, unless you have any concerns.

Thanks,
Pablo

[dpdk-dev] Coverity runs

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vithal Mohare
> Sent: Wednesday, December 9, 2015 4:38 AM
> To: Vithal Mohare; dev at dpdk.org
> Subject: Re: [dpdk-dev] Coverity runs
> 
> Sorry for my ignorance, going through archives found coverity related
> discussions.  So, coverity is being run, but rel version 2.1 still has
> warnings left, may be marked as 'ignore'.

Hi Vithal,

You can register for the DPDK Coverity here:

http://scan.coverity.com/users/sign_up

You can then review the defects online at:

http://scan.coverity.com/projects/dpdk-data-plane-development-kit

If you would like to fix some of the open issues that would be welcome.

John

[dpdk-dev] [PATCH] ip_pipeline: fix build errors on different linux kernels

[Jasvinder Singh]

This patch fixes build errors on linux kernels such as
SuSE 11-SP2/3(64 bits), etc.

Error Log:
error: implicit declaration of function 'WIFEXITED'
error: implicit declaration of function 'WEXITSTATUS'

Fixes: ed0b2d020159 ("examples/ip_pipeline: add more ports")

Signed-off-by: Jasvinder Singh 
Acked-by: Cristian Dumitrescu 
---
 examples/ip_pipeline/config_parse.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/examples/ip_pipeline/config_parse.c 
b/examples/ip_pipeline/config_parse.c
index 6e49763..6aaca11 100644
--- a/examples/ip_pipeline/config_parse.c
+++ b/examples/ip_pipeline/config_parse.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
-- 
2.5.0

[dpdk-dev] [PATCH v3] examples/vhost: fix strict aliasing error on gcc 4.4.7

[Pablo de Lara]

From: "De Lara Guarch, Pablo" 

Fixes following error on gcc 4.4.7:

make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
  CC main.o
cc1: warnings being treated as errors
/tmp/dpdk-tmp/examples/vhost/main.c: In function ?new_device?:
/tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
dereferencing pointer ?mbuf.486? does break strict-aliasing rules
/tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
...
/tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
/tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
dereferencing pointer ?({anonymous})? does break strict-aliasing rules
/tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
make[1]: *** [main.o] Error 1

Fixes: d19533e8 ("examples/vhost: copy old vhost example")

Reported-by: Qian Xu 
Signed-off-by: Pablo de Lara 
Acked-by: Huawei Xie 
---
Changes in v3:
- Remove even more unnecessary castings

Changes in v2:
- Remove unnecessary casting

 examples/vhost/main.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index dc3a012..b30f1bd 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -1449,7 +1449,8 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
uint64_t buff_addr, phys_addr;
struct vhost_virtqueue *vq;
struct vring_desc *desc;
-   struct rte_mbuf *mbuf = NULL;
+   void *obj = NULL;
+   struct rte_mbuf *mbuf;
struct vpool *vpool;
hpa_type addr_type;
struct vhost_dev *vdev = (struct vhost_dev *)dev->priv;
@@ -1500,7 +1501,8 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
}
} while (unlikely(phys_addr == 0));

-   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
+   rte_ring_sc_dequeue(vpool->ring, &obj);
+   mbuf = obj;
if (unlikely(mbuf == NULL)) {
LOG_DEBUG(VHOST_DATA,
"(%"PRIu64") in attach_rxmbuf_zcp: "
@@ -1517,7 +1519,7 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
"size required: %d\n",
dev->device_fh, desc->len, desc_idx, vpool->buf_size);
put_desc_to_used_list_zcp(vq, desc_idx);
-   rte_ring_sp_enqueue(vpool->ring, (void *)mbuf);
+   rte_ring_sp_enqueue(vpool->ring, obj);
return;
}

@@ -1789,7 +1791,8 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
rte_mbuf *m,
 {
struct mbuf_table *tx_q;
struct rte_mbuf **m_table;
-   struct rte_mbuf *mbuf = NULL;
+   void *obj = NULL;
+   struct rte_mbuf *mbuf;
unsigned len, ret, offset = 0;
struct vpool *vpool;
uint16_t vlan_tag = (uint16_t)vlan_tags[(uint16_t)dev->device_fh];
@@ -1801,7 +1804,8 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
rte_mbuf *m,

/* Allocate an mbuf and populate the structure. */
vpool = &vpool_array[MAX_QUEUES + vmdq_rx_q];
-   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
+   rte_ring_sc_dequeue(vpool->ring, &obj);
+   mbuf = obj;
if (unlikely(mbuf == NULL)) {
struct vhost_virtqueue *vq = dev->virtqueue[VIRTIO_TXQ];
RTE_LOG(ERR, VHOST_DATA,
-- 
2.5.0

[dpdk-dev] [PATCH v2] mk: fix external shared library dependencies of libraries

[Panu Matilainen]

On 12/08/2015 06:28 PM, Sergio Gonzalez Monroy wrote:
> On 08/12/2015 11:47, Panu Matilainen wrote:
>> Similar to commit 5f9115e58cc6f304ff4ade694cf5823d32887d1a etc, but
>> for libraries. Clean up librte_vhost CFLAGS/LDFLAGS/LDLIBS confusion
>> while at it.
>>
>> Requiring applications to know about library internal details like
>> dependencies to external helper libraries is a limitation of
>> static linkage, shared libraries should always know their own
>> dependencies for sane operation.
>>
>> Linking with the combined library (whether shared or not) still
>> requires knowing the internal dependencies, and intra-dpdk
>> dependencies are also not currently recorded.
>>
>> Signed-off-by: Panu Matilainen 
>> ---
>>
>> v2:
>> - clean up librte_vhost CFLAGS/LDFLAGS/LDLIBS confusion while at it
>>
>>
> Hi Panu,
>
> Patch itself looks good but there is a small side effect on BSD that
> results
> in app/test not linking because of missing -lm.
> Linuxapp links with -lm by default (EXECENV_LDLIBS), but BSD does not.

Oh, those LIBRTE_SCHED entries were in a different if-block from the 
others...

Hmm, interesting. Without this patch, on Linux -lm gets added twice 
which actually causes a build failure on Fedora rawhide (related to some 
libmvec related changes it seems).

> Should we just add -lm to EXECENV_LDLIBS for BSD too instead of
> adding it on each app/example that uses librte_sched ?

Linking should be based on usage, not convenience or such... but there's 
no explanation why -lm is added everywhere in Linux:

commit 6da94b7a92d9706c1a4fb23a9cf54f49e6019af2
Author: Intel 
Date:   Wed Sep 18 12:00:00 2013 +0200

 mk: link with libm

 Signed-off-by: Intel

Certainly librte_sched should link to -lm and in static builds, all its 
users, but beyond that I suppose it needs closer investigation of what 
(if anything else) actually needs it.

I think we better leave it alone for 2.2, but the librte_vhost part 
should be safe. I can send another version with just that if it has a 
chance to make it to 2.2, otherwise lets postpone it to 2.3.

- Panu -

- Panu -

- Panu -

[dpdk-dev] [PATCH v4] Fixes following error on gcc 4.4.7:

[Pablo de Lara]

make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
  CC main.o
cc1: warnings being treated as errors
/tmp/dpdk-tmp/examples/vhost/main.c: In function ?new_device?:
/tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
dereferencing pointer ?mbuf.486? does break strict-aliasing rules
/tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
...
/tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
/tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
dereferencing pointer ?({anonymous})? does break strict-aliasing rules
/tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
make[1]: *** [main.o] Error 1

Fixes: d19533e8 ("examples/vhost: copy old vhost example")

Reported-by: Qian Xu 
Signed-off-by: Pablo de Lara 
---
Changes in v4:
- Simplify patch, just casting to void *, without using new variables

Changes in v3:
- Remove even more unnecessary castings

Changes in v2:
- Remove unnecessary casting

 examples/vhost/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index dc3a012..f3c50c5 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -1500,7 +1500,7 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
}
} while (unlikely(phys_addr == 0));

-   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
+   rte_ring_sc_dequeue(vpool->ring, (void *)mbuf);
if (unlikely(mbuf == NULL)) {
LOG_DEBUG(VHOST_DATA,
"(%"PRIu64") in attach_rxmbuf_zcp: "
@@ -1801,7 +1801,7 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
rte_mbuf *m,

/* Allocate an mbuf and populate the structure. */
vpool = &vpool_array[MAX_QUEUES + vmdq_rx_q];
-   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
+   rte_ring_sc_dequeue(vpool->ring, (void *)mbuf);
if (unlikely(mbuf == NULL)) {
struct vhost_virtqueue *vq = dev->virtqueue[VIRTIO_TXQ];
RTE_LOG(ERR, VHOST_DATA,
-- 
2.5.0

[dpdk-dev] Problem with new "make install" of DPDK 2.2.0-rc3 + XenVirt on 32-bit build is broken

[Piotr Bartosiewicz]

W dniu 08.12.2015 o 20:07, Martinx - ? pisze:
> On 8 December 2015 at 17:03, Thomas Monjalon 
> mailto:thomas.monjalon at 6wind.com>> wrote:
>
> 2015-12-08 18:01, Piotr Bartosiewicz:
> >
> > > cp: cannot stat
> > >
> ?/home/tmartins/sources/dpdk/2.2.0-rc3/dpdk-2.2.0-rc3/{mk,scripts}?:
> No
> > > such file or directory
> > > /home/tmartins/sources/dpdk/2.2.0-rc3/dpdk-2.2.0-rc3/mk/
> > > rte.sdkinstall.mk:137 : recipe
> for target 'install-sdk' failed
> > >
> >
> > I have the same problem and it has nothing to do with XenVirt or
> 32-bit
> > build.
> > As a workaround you can change mk/rte.sdkinstall.mk
>  as follows:
> >
> > -   $(Q)cp -a  $(RTE_SDK)/{mk,scripts} $(DESTDIR)$(sdkdir)
> > +   $(Q)cp -a   $(RTE_SDK)/mk $(DESTDIR)$(sdkdir)
> > +   $(Q)cp -a   $(RTE_SDK)/scripts
> $(DESTDIR)$(sdkdir)
>
> I had a doubt when writing it.
> Please what is your default shell? ls -l /bin/sh
>
>
> Mine is dash (default on Debian / Ubuntu):
>
> tmartins at xenial-1:~$ file /bin/sh
> /bin/sh: symbolic link to dash
>
/bin/sh -> dash
Debian GNU/Linux 8
Ubuntu 15.10

[dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application guide

[Bernard Iremonger]

correct sample console commands

Fixes: d0dff9ba445e ("doc: sample application user guide"
Fixes: 9bc23cb8209c ("doc: add vhost-user to sample guide")
Fixes: 43866bf71d58 ("doc: fix vhost sample parameter")
Signed-off-by: Bernard Iremonger 
---
 doc/guides/sample_app_ug/vhost.rst | 40 +++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/doc/guides/sample_app_ug/vhost.rst 
b/doc/guides/sample_app_ug/vhost.rst
index ceeaf52..70d31b6 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -1,6 +1,6 @@

 ..  BSD LICENSE
-Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
@@ -386,13 +386,13 @@ Running the Sample Code

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / 
mnt/huge -- -p 0x1 --dev-basename usvhost
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- -p 0x1 --dev-basename usvhost

 vhost user: a socket file named usvhost will be created under current 
directory. Use its path as the socket path in guest's qemu commandline.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / 
mnt/huge -- -p 0x1 --dev-basename usvhost
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- -p 0x1 --dev-basename usvhost

 .. note::

@@ -411,7 +411,7 @@ For compatibility with the QEMU wrapper script, a base name 
of "usvhost" should

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- -p 0x1 --dev-basename usvhost
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- -p 0x1 --dev-basename usvhost

 **vm2vm.**
 The vm2vm parameter disable/set mode of packet switching between guests in the 
host.
@@ -424,7 +424,7 @@ which bases on the packet destination MAC address and VLAN 
tag.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir /mnt/huge 
-- --vm2vm [0,1,2]
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- --vm2vm [0,1,2]

 **Mergeable Buffers.**
 The mergeable buffers parameter controls how virtio-net descriptors are used 
for virtio-net headers.
@@ -434,7 +434,7 @@ The default value is 0 or disabled since recent kernels 
virtio-net drivers show

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --mergeable [0,1]
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- --mergeable [0,1]

 **Stats.**
 The stats parameter controls the printing of virtio-net device statistics.
@@ -442,7 +442,7 @@ The parameter specifies an interval second to print 
statistics, with an interval

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --stats [0,n]
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- --stats [0,n]

 **RX Retry.**
 The rx-retry option enables/disables enqueue retries when the guests RX queue 
is full.
@@ -452,7 +452,7 @@ This option is enabled by default.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --rx-retry [0,1]
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- --rx-retry [0,1]

 **RX Retry Number.**
 The rx-retry-num option specifies the number of retries on an RX burst,
@@ -461,7 +461,7 @@ The default value is 4.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --rx-retry 1 --rx-retry-num 5
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- --rx-retry 1 --rx-retry-num 5

 **RX Retry Delay Time.**
 The rx-retry-delay option specifies the timeout (in micro seconds) between 
retries on an RX burst,
@@ -470,7 +470,7 @@ The default value is 15.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --rx-retry 1 --rx-retry-delay 20
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- --rx-retry 1 --rx-retry-delay 20

 **Zero copy.**
 The zero copy option enables/disables the zero copy mode for RX/TX packet,
@@ -481,7 +481,7 @@ This option is disabled by default.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir /mnt/huge 
-- --zero-copy [0,1]
+user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- --zero-copy [0,1]

 **R

[dpdk-dev] [PATCH v5 1/2] tools: Add support for handling built-in kernel modules

[Kamil Rytarowski]

Currently dpdk_nic_bind.py detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.

Add support for checking built-in modules with parsing the sysfs files.

This commit obsoletes the /proc/modules parsing approach.

Signed-off-by: Kamil Rytarowski 
Signed-off-by: David Marchand 
---
 tools/dpdk_nic_bind.py | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
index f02454e..e161062 100755
--- a/tools/dpdk_nic_bind.py
+++ b/tools/dpdk_nic_bind.py
@@ -156,22 +156,29 @@ def check_modules():
 '''Checks that igb_uio is loaded'''
 global dpdk_drivers

-fd = file("/proc/modules")
-loaded_mods = fd.readlines()
-fd.close()
-
 # list of supported modules
 mods =  [{"Name" : driver, "Found" : False} for driver in dpdk_drivers]

 # first check if module is loaded
-for line in loaded_mods:
+try:
+# Get list of syfs modules, some of them might be builtin and merge 
with mods
+sysfs_path = '/sys/module/'
+
+# Get the list of directories in sysfs_path
+sysfs_mods = [os.path.join(sysfs_path,o) for o in 
os.listdir(sysfs_path) if os.path.isdir(os.path.join(sysfs_path,o))]
+
+# Extract the last element of '/sys/module/abc' in the array
+sysfs_mods = [a.split('/')[-1] for a in sysfs_mods]
+
+# special case for vfio_pci (module is named vfio-pci,
+# but its .ko is named vfio_pci)
+sysfs_mods = map(lambda a: a if a != 'vfio_pci' else 'vfio-pci', 
sysfs_mods)
+
 for mod in mods:
-if line.startswith(mod["Name"]):
-mod["Found"] = True
-# special case for vfio_pci (module is named vfio-pci,
-# but its .ko is named vfio_pci)
-elif line.replace("_", "-").startswith(mod["Name"]):
+if mod["Found"] == False and (mod["Name"] in sysfs_mods):
 mod["Found"] = True
+except:
+pass

 # check if we have at least one loaded module
 if True not in [mod["Found"] for mod in mods] and b_flag is not None:
-- 
2.6.3

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

[Kamil Rytarowski]

Currently rte_eal_check_module() detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.

Add support for checking built-in modules with parsing the sysfs files

This commit obsoletes the /proc/modules parsing approach.

Signed-off-by: Kamil Rytarowski 
Signed-off-by: David Marchand 
---
 lib/librte_eal/linuxapp/eal/eal.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 635ec36..21a4a32 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -901,27 +901,33 @@ int rte_eal_has_hugepages(void)
 int
 rte_eal_check_module(const char *module_name)
 {
-   char mod_name[30]; /* Any module names can be longer than 30 bytes? */
-   int ret = 0;
+   char sysfs_mod_name[PATH_MAX];
+   struct stat st;
int n;

if (NULL == module_name)
return -1;

-   FILE *fd = fopen("/proc/modules", "r");
-   if (NULL == fd) {
-   RTE_LOG(ERR, EAL, "Open /proc/modules failed!"
-   " error %i (%s)\n", errno, strerror(errno));
+   /* Check if there is sysfs mounted */
+   if (stat("/sys/module", &st) != 0) {
+   RTE_LOG(DEBUG, EAL, "sysfs is not mounted! error %i (%s)\n",
+   errno, strerror(errno));
return -1;
}
-   while (!feof(fd)) {
-   n = fscanf(fd, "%29s %*[^\n]", mod_name);
-   if ((n == 1) && !strcmp(mod_name, module_name)) {
-   ret = 1;
-   break;
-   }
+
+   /* A module might be built-in, therefore try sysfs */
+   n = snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", module_name);
+   if (n < 0 || n > PATH_MAX) {
+   RTE_LOG(DEBUG, EAL, "Could not format module path\n");
+   return -1;
}
-   fclose(fd);

-   return ret;
+   if (stat(sysfs_mod_name, &st) != 0) {
+   RTE_LOG(DEBUG, EAL, "Module %s not found! error %i (%s)\n",
+   sysfs_mod_name, errno, strerror(errno));
+   return 0;
+   }
+
+   /* Module has been found */
+   return 1;
 }
-- 
2.6.3

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

[Kamil Rytarowski]

W dniu 09.12.2015 o 08:30, Panu Matilainen pisze:
> On 12/08/2015 05:33 PM, Kamil Rytarowski wrote:
>> Currently rte_eal_check_module() detects Linux kernel modules via 
>> reading
>> /proc/modules. Built-in ones aren't listed there and therefore they 
>> are not
>> being found by the script.
>>
>> Add support for checking built-in modules with parsing the sysfs files
>>
>> This commit obsoletes the /proc/modules parsing approach.
>>
>> Signed-off-by: Kamil Rytarowski 
>> Signed-off-by: David Marchand 
>> ---
>>   lib/librte_eal/linuxapp/eal/eal.c | 34 
>> --
>>   1 file changed, 20 insertions(+), 14 deletions(-)
>>
>> diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
>> b/lib/librte_eal/linuxapp/eal/eal.c
>> index 635ec36..92482a0 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal.c
>> @@ -901,27 +901,33 @@ int rte_eal_has_hugepages(void)
>>   int
>>   rte_eal_check_module(const char *module_name)
>>   {
>> -char mod_name[30]; /* Any module names can be longer than 30 
>> bytes? */
>> -int ret = 0;
>> +char sysfs_mod_name[PATH_MAX];
>> +struct stat st;
>>   int n;
>>
>>   if (NULL == module_name)
>>   return -1;
>>
>> -FILE *fd = fopen("/proc/modules", "r");
>> -if (NULL == fd) {
>> -RTE_LOG(ERR, EAL, "Open /proc/modules failed!"
>> -" error %i (%s)\n", errno, strerror(errno));
>> +/* Check if there is sysfs mounted */
>> +if (stat("/sys/module", &st) != 0) {
>> +RTE_LOG(DEBUG, EAL, "sysfs is not mounted! error %i (%s)\n",
>> +errno, strerror(errno));
>>   return -1;
>>   }
>> -while (!feof(fd)) {
>> -n = fscanf(fd, "%29s %*[^\n]", mod_name);
>> -if ((n == 1) && !strcmp(mod_name, module_name)) {
>> -ret = 1;
>> -break;
>> -}
>> +
>> +/* A module might be built-in, therefore try sysfs */
>> +n = snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", 
>> module_name);
>> +if (n < 0 || n > PATH_MAX) {
>> +RTE_LOG(DEBUG, EAL, "Could not format module path\n");
>> +return -1;
>>   }
>> -fclose(fd);
>>
>> -return ret;
>> +if (stat(sysfs_mod_name, &st) != 0) {
>> +RTE_LOG(DEBUG, EAL, "Open %s failed! error %i (%s)\n",
>> +sysfs_mod_name, errno, strerror(errno));
>> +return 0;
>> +}
>
> Like with /sys/module, its not trying to *open* sysfs_mod_name 
> directory either so it shouldn't claim to do so.
>
> I did use plural on purpose when I said "the debug messages are 
> incorrect/misleading. It's certainly not trying to *open* these 
> directories so it should not claim to do so" in my previous mail :)
>
> - Panu -
>

Should be good now!

Thank you.

[dpdk-dev] [PATCH v4] Fixes following error on gcc 4.4.7:

[Xie, Huawei]

On 12/9/2015 8:20 PM, De Lara Guarch, Pablo wrote:
> make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
>   CC main.o
[...]
> - rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
> + rte_ring_sc_dequeue(vpool->ring, (void *)mbuf);
Here we are expecting the address of &mbuf, not mbuf, which is NULL.
>   if (unlikely(mbuf == NULL)) {
>   LOG_DEBUG(VHOST_DATA,
>   "(%"PRIu64") in attach_rxmbuf_zcp: "
> @@ -1801,7 +1801,7 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
> rte_mbuf *m,
>  
>   /* Allocate an mbuf and populate the structure. */
>   vpool = &vpool_array[MAX_QUEUES + vmdq_rx_q];
> - rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
> + rte_ring_sc_dequeue(vpool->ring, (void *)mbuf);
Same as above.
>   if (unlikely(mbuf == NULL)) {
>   struct vhost_virtqueue *vq = dev->virtqueue[VIRTIO_TXQ];
>   RTE_LOG(ERR, VHOST_DATA,

[dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application guide

[Xie, Huawei]

On 12/9/2015 8:36 PM, Iremonger, Bernard wrote:
> correct sample console commands
>
> Fixes: d0dff9ba445e ("doc: sample application user guide"
> Fixes: 9bc23cb8209c ("doc: add vhost-user to sample guide")
> Fixes: 43866bf71d58 ("doc: fix vhost sample parameter")
> Signed-off-by: Bernard Iremonger 
Acked-by: Huawei Xie 

Thanks.
[...]

[dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue with 128-byte cache line targets

[Ananyev, Konstantin]

Hi Jerin,

> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Tuesday, December 08, 2015 5:49 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org; thomas.monjalon at 6wind.com; Richardson, Bruce; 
> olivier.matz at 6wind.com; Dumitrescu, Cristian
> Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource 
> issue with 128-byte cache line targets
> 
> On Tue, Dec 08, 2015 at 04:07:46PM +, Ananyev, Konstantin wrote:
> > >
> > > Hi Konstantin,
> > >
> > > > Hi Jerin,
> > > >
> > > > > -Original Message-
> > > > > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> > > > > Sent: Sunday, December 06, 2015 3:59 PM
> > > > > To: dev at dpdk.org
> > > > > Cc: thomas.monjalon at 6wind.com; Richardson, Bruce; olivier.matz at 
> > > > > 6wind.com; Dumitrescu, Cristian; Ananyev, Konstantin;
> Jerin
> > > > > Jacob
> > > > > Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource 
> > > > > issue with 128-byte cache line targets
> > > > >
> > > > > No need to split mbuf structure to two cache lines for 128-byte cache 
> > > > > line
> > > > > size targets as it can fit on a single 128-byte cache line.
> > > > >
> > > > > Signed-off-by: Jerin Jacob 
> > > > > ---
> > > > >  app/test/test_mbuf.c  | 4 
> > > > > 
> > > > >  lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 4 
> > > > > 
> > > > >  lib/librte_mbuf/rte_mbuf.h| 2 ++
> > > > >  3 files changed, 10 insertions(+)
> > > > >
> > > > > diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> > > > > index b32bef6..5e21075 100644
> > > > > --- a/app/test/test_mbuf.c
> > > > > +++ b/app/test/test_mbuf.c
> > > > > @@ -930,7 +930,11 @@ test_failing_mbuf_sanity_check(void)
> > > > >  static int
> > > > >  test_mbuf(void)
> > > > >  {
> > > > > +#if RTE_CACHE_LINE_SIZE == 64
> > > > >   RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE 
> > > > > * 2);
> > > > > +#elif RTE_CACHE_LINE_SIZE == 128
> > > > > + RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != 
> > > > > RTE_CACHE_LINE_SIZE);
> > > > > +#endif
> > > > >
> > > > >   /* create pktmbuf pool if it does not exist */
> > > > >   if (pktmbuf_pool == NULL) {
> > > > > diff --git 
> > > > > a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h 
> > > > > b/lib/librte_eal/linuxapp/eal/include/exec-
> > > > > env/rte_kni_common.h
> > > > > index bd1cc09..e724af7 100644
> > > > > --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > > > > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > > > > @@ -121,8 +121,12 @@ struct rte_kni_mbuf {
> > > > >   uint32_t pkt_len;   /**< Total pkt len: sum of all segment 
> > > > > data_len. */
> > > > >   uint16_t data_len;  /**< Amount of data in segment buffer. 
> > > > > */
> > > > >
> > > > > +#if RTE_CACHE_LINE_SIZE == 64
> > > > >   /* fields on second cache line */
> > > > >   char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_SIZE)));
> > > > > +#elif RTE_CACHE_LINE_SIZE == 128
> > > > > + char pad3[24];
> > > > > +#endif
> > > > >   void *pool;
> > > > >   void *next;
> > > > >  };
> > > > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > > > > index f234ac9..0bf55e0 100644
> > > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > @@ -813,8 +813,10 @@ struct rte_mbuf {
> > > > >
> > > > >   uint16_t vlan_tci_outer;  /**< Outer VLAN Tag Control 
> > > > > Identifier (CPU order) */
> > > > >
> > > > > +#if RTE_CACHE_LINE_SIZE == 64
> > > > >   /* second cache line - fields only used in slow path or on TX */
> > > > >   MARKER cacheline1 __rte_cache_aligned;
> > > > > +#endif
> > > >
> > > > I suppose you'll need to keep same space reserved for first 64B even on 
> > > > systems with 128B cache-line.
> > > > Otherwise we can endup with different mbuf format for systems with 128B 
> > > > cache-line.
> > >
> > > Just to understand, Is there any issue in mbuf format being different
> > > across the systems. I think, we are not sending the mbuf over the wire
> > > or sharing with different system etc. right?
> >
> > No, we don't have to support that.
> > At least I am not aware about such cases.
> >
> > >
> > > Yes, I do understand the KNI dependency with mbuf.
> >
> > Are you asking about what will be broken (except KNI) if mbuf layout IA and 
> > ARM would be different?
> > Probably nothing right now, except vector RX/TX.
> > But they are not supported on ARM anyway, and if someone will implement 
> > them in future, it
> > might be completely different from IA one.
> > It just seems wrong to me to have different mbuf layout for each 
> > architecture.
> 
> It's not architecture specific, it's machine and PMD specific.
> Typical ARM machines are 64-bytes CL but ThunderX and Power8  have
> 128-byte CL.

Ok, didn't know that. 

[dpdk-dev] [PATCH v4] Fixes following error on gcc 4.4.7:

[De Lara Guarch, Pablo]

> -Original Message-
> From: Xie, Huawei
> Sent: Wednesday, December 09, 2015 1:29 PM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Cc: yuanhan.liu at linux.intel.com
> Subject: Re: [PATCH v4] Fixes following error on gcc 4.4.7:
> 
> On 12/9/2015 8:20 PM, De Lara Guarch, Pablo wrote:
> > make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
> >   CC main.o
> [...]
> > -   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
> > +   rte_ring_sc_dequeue(vpool->ring, (void *)mbuf);
> Here we are expecting the address of &mbuf, not mbuf, which is NULL.
> > if (unlikely(mbuf == NULL)) {
> > LOG_DEBUG(VHOST_DATA,
> > "(%"PRIu64") in attach_rxmbuf_zcp: "
> > @@ -1801,7 +1801,7 @@ virtio_tx_route_zcp(struct virtio_net *dev,
> struct rte_mbuf *m,
> >
> > /* Allocate an mbuf and populate the structure. */
> > vpool = &vpool_array[MAX_QUEUES + vmdq_rx_q];
> > -   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
> > +   rte_ring_sc_dequeue(vpool->ring, (void *)mbuf);
> Same as above.
> > if (unlikely(mbuf == NULL)) {
> > struct vhost_virtqueue *vq = dev->virtqueue[VIRTIO_TXQ];
> > RTE_LOG(ERR, VHOST_DATA,

Right, I will revert to v3 (and fix the title as well, sorry about that).

[dpdk-dev] fix mbuf->port for eth_af_packet

[Krauz, Pavel]

Hello,
Here goes patch for DPDK 2.2.0.rc3 that fixes reported port number in mbuf when 
eth_af_packet PMD is used.

b.r.
Pavel Krauz

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dpdk_af_packet.patch.txt
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20151209/9c636d80/attachment.txt>

[dpdk-dev] [PATCH v4] Fixes following error on gcc 4.4.7:

[Xie, Huawei]

On 12/9/2015 10:01 PM, De Lara Guarch, Pablo wrote:
>
>> -Original Message-
>> From: Xie, Huawei
>> Sent: Wednesday, December 09, 2015 1:29 PM
>> To: De Lara Guarch, Pablo; dev at dpdk.org
>> Cc: yuanhan.liu at linux.intel.com
>> Subject: Re: [PATCH v4] Fixes following error on gcc 4.4.7:
>>
>> On 12/9/2015 8:20 PM, De Lara Guarch, Pablo wrote:
>>> make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
>>>   CC main.o
>> [...]
>>> -   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
>>> +   rte_ring_sc_dequeue(vpool->ring, (void *)mbuf);
>> Here we are expecting the address of &mbuf, not mbuf, which is NULL.
>>> if (unlikely(mbuf == NULL)) {
>>> LOG_DEBUG(VHOST_DATA,
>>> "(%"PRIu64") in attach_rxmbuf_zcp: "
>>> @@ -1801,7 +1801,7 @@ virtio_tx_route_zcp(struct virtio_net *dev,
>> struct rte_mbuf *m,
>>> /* Allocate an mbuf and populate the structure. */
>>> vpool = &vpool_array[MAX_QUEUES + vmdq_rx_q];
>>> -   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
>>> +   rte_ring_sc_dequeue(vpool->ring, (void *)mbuf);
>> Same as above.
>>> if (unlikely(mbuf == NULL)) {
>>> struct vhost_virtqueue *vq = dev->virtqueue[VIRTIO_TXQ];
>>> RTE_LOG(ERR, VHOST_DATA,
> Right, I will revert to v3 (and fix the title as well, sorry about that).
Actually we could try defining mbufs[1], and use (void **)mbufs as
parameter, like in examples/qos_sched to save a variable, but weird it
failed. For the time being, this fix is OK.
Another thing is would you fix examples/ip_pipeline as well?
>

[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script

[Neil Horman]

On Tue, Dec 08, 2015 at 05:03:26PM +, Robie Basak wrote:
> On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
> > Theres nothing "complex" about the simple fact that a project builds lots of
> > libraries.  Its extreemely common. Any graphic window manager has exactly 
> > the
> > same situation, as do any number of tools that have multiple hardware 
> > backends
> > impelmented in user space (v4l, sane, iptables, to name just a few).
> > 
> > > Before I go into details, it would be nice if someone could please
> > > explain why DPDK has to be "special" in needing to do this? I don't
> > Its not special, see above.  Not saying the build environment cant be 
> > improved,
> > but the fact that there are multiple libraries is pretty straightforward.
> 
> It's fine in principle for an upstream to ship multiple shared
> libraries, but it is extra and unnecessary work unless there's a
> *reason* to have multiple shared libraries. What are the reasons for
> DPDK?
> 
Separation of functionality.  There is no need to build a library that supports
10 different NICS when a given application is only using one.  Likewise with
other discrete functionality, e.g. you don't link against the ACL library if you
dont' want to use ACL's.

> > > In Debian and Ubuntu, we manage a library transition (an ABI bump in a
> > > library together with all dependencies moving to use the new ABI) by
> > > concurrently packaging both the old and new libraries at once. This
> > > works well with the norm for libraries. We ship one binary package per
> > > soname, with the major version as part of the package name. This allows
> > > a system to have two (or more) ABIs installed simultaneously. For a
> > > library transition, we just package the new version and then that can
> > > land and work concurrently as we then individually update every
> > > dependent (library-consuming) package.
> 
> > So thats, a distribution choice, not an upstream problem.
> 
> No, that's how shared libraries work. By design, multiple ABI versions
> can be co-installed. That's why sonames have the ABI major version
> inside them and the filenames reflect the sonames.
> 
We're talking about different things.  The DPDK support ABI versioning in their
sonames, if you would look at the makefiles and output, you would clearly see
that.  Theres no reason that multiple versions of DPDK can't be co-installed,
thats easy, the question here is weather it should support multiple discrete
libraries or only a single large library.  It seems from your comments that a
single monolithic library should be the only option, and thats clearly the less
flexible one.

> It is a distribution choice to exploit this capability. But it is an
> upstream problem if this capability is broken.
> 
Its not broken.  In what way do you think soname versioning is broken in DPDK?
And in what way is it broken that the only solution is to merge all the
libraries into a single monolithic one?

> By shipping multiple shared libraries, DPDK isn't breaking this
> capability per se. But if the upstream expectation is that it's no
> additional work for distributions because the multiple libraries can
> just be bundled together into a single distribution package, then _this_
> is what breaks the capability.
> 
> Instead DPDK needs to acknowledge that splitting libraries _does_ cause
> additional packaging work for any distribution that wants to use the
> multiple co-installed ABI feature of shared libraries as they are
> designed.
> 

Very well, allowing multiple separate libraries causes some extra work for
packaging.  Specifically it requires that distributions carry a patch that
instantiate a specific library ABI major version number that is incremented ni
lock step for every library in a given build (which is admittedly not what
upstream currently does).  I don't see that as overly hard to do, but to each
their own.

However, the solution there is to propose a patch that defines a single ABI
variable in the makefile structure that is applied to every library on a symbol
version bump.  The answer is _not_ to somehow entangle that with the idea that
we have to have a single monolithic library.  Their separate issues, and you
can solve the problem that you are complaining about without throwing the
proverbial baby out with the bathwater.

> Then, it becomes for upstream a question of the trade-off: does the
> benefit of split libraries outweigh the extra work this creates on
> packagers? To understand this, first I need to understand the rationale
> for shipping multiple shared libaries specifically in DPDK, and I feel
> that you (well, Red Hat) have yet to present a case.
>
Some of the reasons I've mentioned above.  Regardless however, the solution
your advocating to the problem you describe is orthogonal to the complaints
you're making there.  If your goal is to allow multiple ABI versions in a given
package, then propose that ABI versions be incremented monolithically in the
upstream build

[dpdk-dev] [PATCH] doc: add fm10k driver

[Mcnamara, John]

> -Original Message-
> From: Chen, Jing D
> Sent: Wednesday, December 9, 2015 8:25 AM
> To: dev at dpdk.org
> Cc: Mcnamara, John; Chen, Jing D
> Subject: [PATCH] doc: add fm10k driver
> 
> From: "Chen Jing D(Mark)" 
> 
> This documentation covers introdutions and limitations on Intel
> FM1 series products.

Hi Mark,

Thanks for that. 

The docs build cleanly but there is one whitespace warning on merge.

Minor comments below.



> @@ -0,0 +1,54 @@
> +..  BSD LICENSE
> +Copyright(c) 2010-2015 Intel Corporation. All rights reserved.

The year should be 2015 only and this line shouldn't be indented in relation
to the next lines.



> +FM10K Poll Mode Driver
> +==
> +The FM10K poll mode driver library provides support for Intel FM1
> +family of 40GbE/100GbE adapters.

The DPDK Documentation Guidelines say to leave a blank line after section
headers (here and with the other sections): 

> +FM10K Poll Mode Driver
> +==
>
> +The FM10K poll mode driver library provides support for Intel FM1
> +family of 40GbE/100GbE adapters.

 See:  http://dpdk.org/doc/guides/contributing/documentation.html#rst-guidelines


> +The FM10K poll mode driver library provides support for Intel FM1
> +family of 40GbE/100GbE adapters.

Might be worth introducing the common FM10K name here as well:

The FM10K poll mode driver library provides support for the Intel FM1
(FM10K) family of 40GbE/100GbE adapters.

> +Intel FM1 family of NICs integrate an hardware switch and multiple
> +host interfaces. FM10K PMD driver only manages host interfaces. For the

The doc uses FM1 in some places and FM10K in others. It should use one
or the other consistently.



> +switch component, another switch driver has to be loaded prior to FM10K
> PMD driver.
> +The switch driver either can be acquired by Intel support or from below
> link:
> +https://github.com/match-interface

Better to add an actual link like:

The switch driver can be acquired for Intel support or from the
`Match Interface `_ project.

Also should that be to: https://github.com/match-interface/match



> +
> +CRC strip
> +FM1 family always strip CRC for every packets coming into host
> interface.


Limitations
---

Switch manager
~~

The Intel FM1 family of NICs integrate a hardware switch and multiple host

Etc.

> +Max packet length
> +FM1 family support maximum of 15K jumbo frame. The value is fixed
> +and can't be changed. So, even (struct
> +rte_eth_conf).rxmode.max_rx_pkt_len is set to a value other than 15364,
> the frames with 15364 byte still can reach to host interface.

This isn't clear (to me). Maybe something like:

The FM1 family of NICS support a maximum of a 15K jumbo frame. The value
is fixed and cannot be changed. So, even when the ``rxmode.max_rx_pkt_len``
member of ``struct rte_eth_conf`` is set to a value lower than 15364, frames
up to 15364 bytes can still reach the host interface.


Regards,

John.
-- 

[dpdk-dev] fix mbuf->port for eth_af_packet

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Krauz, Pavel
> Sent: Wednesday, December 9, 2015 2:10 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] fix mbuf->port for eth_af_packet
> 
> Hello,
> Here goes patch for DPDK 2.2.0.rc3 that fixes reported port number in mbuf
> when eth_af_packet PMD is used.

Hi Pavel,

Thanks for that. Could you resubmit the patch with a signoff line and in a
git diff format. See the draft Contributors Guide:

   http://dpdk.org/dev/patchwork/patch/9019/

Regards,

John.
-- 

[dpdk-dev] [PATCH v5] examples/vhost: fix strict aliasing error on gcc 4.4.7

[Pablo de Lara]

From: "De Lara Guarch, Pablo" 

Fixes following error on gcc 4.4.7:

make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
  CC main.o
cc1: warnings being treated as errors
/tmp/dpdk-tmp/examples/vhost/main.c: In function ?new_device?:
/tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
dereferencing pointer ?mbuf.486? does break strict-aliasing rules
/tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
...
/tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
/tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
dereferencing pointer ?({anonymous})? does break strict-aliasing rules
/tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
make[1]: *** [main.o] Error 1

Fixes: d19533e8 ("examples/vhost: copy old vhost example")

Reported-by: Qian Xu 
Signed-off-by: Pablo de Lara 
---
Changes in v5:
- Revert to v3 and fix the title

Changes in v4:
- Simplify patch, just casting to void *, without using new variables

Changes in v3:
- Remove even more unnecessary castings

Changes in v2:
- Remove unnecessary casting

 examples/vhost/main.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index dc3a012..b30f1bd 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -1449,7 +1449,8 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
uint64_t buff_addr, phys_addr;
struct vhost_virtqueue *vq;
struct vring_desc *desc;
-   struct rte_mbuf *mbuf = NULL;
+   void *obj = NULL;
+   struct rte_mbuf *mbuf;
struct vpool *vpool;
hpa_type addr_type;
struct vhost_dev *vdev = (struct vhost_dev *)dev->priv;
@@ -1500,7 +1501,8 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
}
} while (unlikely(phys_addr == 0));

-   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
+   rte_ring_sc_dequeue(vpool->ring, &obj);
+   mbuf = obj;
if (unlikely(mbuf == NULL)) {
LOG_DEBUG(VHOST_DATA,
"(%"PRIu64") in attach_rxmbuf_zcp: "
@@ -1517,7 +1519,7 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
"size required: %d\n",
dev->device_fh, desc->len, desc_idx, vpool->buf_size);
put_desc_to_used_list_zcp(vq, desc_idx);
-   rte_ring_sp_enqueue(vpool->ring, (void *)mbuf);
+   rte_ring_sp_enqueue(vpool->ring, obj);
return;
}

@@ -1789,7 +1791,8 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
rte_mbuf *m,
 {
struct mbuf_table *tx_q;
struct rte_mbuf **m_table;
-   struct rte_mbuf *mbuf = NULL;
+   void *obj = NULL;
+   struct rte_mbuf *mbuf;
unsigned len, ret, offset = 0;
struct vpool *vpool;
uint16_t vlan_tag = (uint16_t)vlan_tags[(uint16_t)dev->device_fh];
@@ -1801,7 +1804,8 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
rte_mbuf *m,

/* Allocate an mbuf and populate the structure. */
vpool = &vpool_array[MAX_QUEUES + vmdq_rx_q];
-   rte_ring_sc_dequeue(vpool->ring, (void **)&mbuf);
+   rte_ring_sc_dequeue(vpool->ring, &obj);
+   mbuf = obj;
if (unlikely(mbuf == NULL)) {
struct vhost_virtqueue *vq = dev->virtqueue[VIRTIO_TXQ];
RTE_LOG(ERR, VHOST_DATA,
-- 
2.5.0

[dpdk-dev] [PATCH v5] examples/vhost: fix strict aliasing error on gcc 4.4.7

[Xie, Huawei]

On 12/9/2015 10:27 PM, De Lara Guarch, Pablo wrote:
> From: "De Lara Guarch, Pablo" 
>
> Fixes following error on gcc 4.4.7:
>
> make: Entering directory `/tmp/dpdk-tmp/examples/vhost'
>   CC main.o
> cc1: warnings being treated as errors
> /tmp/dpdk-tmp/examples/vhost/main.c: In function ?new_device?:
> /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
> dereferencing pointer ?mbuf.486? does break strict-aliasing rules
> /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> ...
> /tmp/dpdk-tmp/examples/vhost/main.c:1503: note: initialized from here
> /tmp/dpdk-tmp/x86_64-native-linuxapp-gcc/include/rte_ring.h:740: error:
> dereferencing pointer ?({anonymous})? does break strict-aliasing rules
> /tmp/dpdk-tmp/examples/vhost/main.c:1804: note: initialized from here
> make[1]: *** [main.o] Error 1
>
> Fixes: d19533e8 ("examples/vhost: copy old vhost example")
>
> Reported-by: Qian Xu 
> Signed-off-by: Pablo de Lara 
Acked-by: Huawei Xie 

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Wiles, Keith]

I am having a problem with ?make install T=? command as I was using it before. 
I would normally build a x86_64-native-linuxapp-gcc, clang and icc or a 
different config all together. Currently the ?make install T=? gives a warning 
message at the end of the build plus creates the x86_64-native-linuxapp-XXX 
directory. If I use the suggested ?make config T=? command this command create 
a directory ?build? with a .config file. The problem is this method does not 
allow me to have multiple builds at the same time.

What is the suggested method to have multiple builds without installing  into 
the local file system?

Regards,
Keith

[dpdk-dev] Buildroot support for DPDK 2.2.0-rc3

[Jan Viktorin]

Hello,

I've posted a new patch set with DPDK support into the Buildroot project:

http://lists.busybox.net/pipermail/buildroot/2015-December/146564.html

Patchwork:

https://patchwork.ozlabs.org/patch/554673/
https://patchwork.ozlabs.org/patch/554674/
https://patchwork.ozlabs.org/patch/554675/

After I integrate the new DPDK install rules and fix some minor issues,
I assume that it will be accepted upstream there. Buildroot is useful
at least for cross toolchain generation.

Regards
Jan

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

[dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application guide

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bernard Iremonger
> Sent: Wednesday, December 9, 2015 12:36 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application
> guide
> 
> correct sample console commands
> 
> Fixes: d0dff9ba445e ("doc: sample application user guide"
> Fixes: 9bc23cb8209c ("doc: add vhost-user to sample guide")
> Fixes: 43866bf71d58 ("doc: fix vhost sample parameter")
> Signed-off-by: Bernard Iremonger 

Hi Bernard,

Thanks for that. One comment (in several places):


>  .. code-block:: console
> 
> -user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir 
> /mnt/huge -- -p 0x1 --dev-basename usvhost
> +user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 
> 1024 --huge-dir /mnt/huge -- -p 0x1 --dev-basename usvhost

These long lines in code blocks don't render correctly in the PDF docs. The 
Documentation Guidelines suggest using a commandline line continuation
to maintain functionality within an 80 char doc limit:

   
http://dpdk.org/doc/guides/contributing/documentation.html#code-and-literal-block-sections

So something like this:

user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 
--huge-dir /mnt/huge -- -p 0x1 --dev-basename usvhost

Could be written as:

user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 \
 --huge-dir /mnt/huge -- -p 0x1 --dev-basename usvhost

Or: 

user at target:~$ ./build/app/vhost-switch -c f -n 4 \
--socket-mem 1024 \
--huge-dir /mnt/huge \
-- -p 0x1 --dev-basename usvhost

Regards,

John.
-- 

[dpdk-dev] fix mbuf->port for eth_af_packet

[Krauz, Pavel]

Hello,
Here goes the patch again in the correct format.
Thanks & b.r.
Pavel

[dpdk-dev] Buildroot support for DPDK 2.2.0-rc3

[Santosh Shukla]

Its encouraging.

Could you pl. post buildroot how-to patch to dpdk-dev mailing list, after
your work gets accepted in buildroot.

Thanks

On Wed, Dec 9, 2015 at 8:10 PM, Jan Viktorin 
wrote:

> Hello,
>
> I've posted a new patch set with DPDK support into the Buildroot project:
>
> http://lists.busybox.net/pipermail/buildroot/2015-December/146564.html
>
> Patchwork:
>
> https://patchwork.ozlabs.org/patch/554673/
> https://patchwork.ozlabs.org/patch/554674/
> https://patchwork.ozlabs.org/patch/554675/
>
> After I integrate the new DPDK install rules and fix some minor issues,
> I assume that it will be accepted upstream there. Buildroot is useful
> at least for cross toolchain generation.
>
> Regards
> Jan
>
> --
>Jan Viktorin  E-mail: Viktorin at RehiveTech.com
>System Architect  Web:www.RehiveTech.com
>RehiveTech
>Brno, Czech Republic
>

[dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue with 128-byte cache line targets

[Jerin Jacob]

On Wed, Dec 09, 2015 at 01:44:44PM +, Ananyev, Konstantin wrote:

Hi Konstantin,

>
> Hi Jerin,
>
> > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> > Sent: Tuesday, December 08, 2015 5:49 PM
> > To: Ananyev, Konstantin
> > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com; Richardson, Bruce; 
> > olivier.matz at 6wind.com; Dumitrescu, Cristian
> > Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource 
> > issue with 128-byte cache line targets
> >
> > On Tue, Dec 08, 2015 at 04:07:46PM +, Ananyev, Konstantin wrote:
> > > >
> > > > Hi Konstantin,
> > > >
> > > > > Hi Jerin,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> > > > > > Sent: Sunday, December 06, 2015 3:59 PM
> > > > > > To: dev at dpdk.org
> > > > > > Cc: thomas.monjalon at 6wind.com; Richardson, Bruce; olivier.matz 
> > > > > > at 6wind.com; Dumitrescu, Cristian; Ananyev, Konstantin;
> > Jerin
> > > > > > Jacob
> > > > > > Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache 
> > > > > > resource issue with 128-byte cache line targets
> > > > > >
> > > > > > No need to split mbuf structure to two cache lines for 128-byte 
> > > > > > cache line
> > > > > > size targets as it can fit on a single 128-byte cache line.
> > > > > >
> > > > > > Signed-off-by: Jerin Jacob 
> > > > > > ---
> > > > > >  app/test/test_mbuf.c  | 4 
> > > > > > 
> > > > > >  lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 4 
> > > > > > 
> > > > > >  lib/librte_mbuf/rte_mbuf.h| 2 
> > > > > > ++
> > > > > >  3 files changed, 10 insertions(+)
> > > > > >
> > > > > > diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> > > > > > index b32bef6..5e21075 100644
> > > > > > --- a/app/test/test_mbuf.c
> > > > > > +++ b/app/test/test_mbuf.c
> > > > > > @@ -930,7 +930,11 @@ test_failing_mbuf_sanity_check(void)
> > > > > >  static int
> > > > > >  test_mbuf(void)
> > > > > >  {
> > > > > > +#if RTE_CACHE_LINE_SIZE == 64
> > > > > > RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE 
> > > > > > * 2);
> > > > > > +#elif RTE_CACHE_LINE_SIZE == 128
> > > > > > +   RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != 
> > > > > > RTE_CACHE_LINE_SIZE);
> > > > > > +#endif
> > > > > >
> > > > > > /* create pktmbuf pool if it does not exist */
> > > > > > if (pktmbuf_pool == NULL) {
> > > > > > diff --git 
> > > > > > a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h 
> > > > > > b/lib/librte_eal/linuxapp/eal/include/exec-
> > > > > > env/rte_kni_common.h
> > > > > > index bd1cc09..e724af7 100644
> > > > > > --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > > > > > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > > > > > @@ -121,8 +121,12 @@ struct rte_kni_mbuf {
> > > > > > uint32_t pkt_len;   /**< Total pkt len: sum of all segment 
> > > > > > data_len. */
> > > > > > uint16_t data_len;  /**< Amount of data in segment buffer. 
> > > > > > */
> > > > > >
> > > > > > +#if RTE_CACHE_LINE_SIZE == 64
> > > > > > /* fields on second cache line */
> > > > > > char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_SIZE)));
> > > > > > +#elif RTE_CACHE_LINE_SIZE == 128
> > > > > > +   char pad3[24];
> > > > > > +#endif
> > > > > > void *pool;
> > > > > > void *next;
> > > > > >  };
> > > > > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > > > > > index f234ac9..0bf55e0 100644
> > > > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > > @@ -813,8 +813,10 @@ struct rte_mbuf {
> > > > > >
> > > > > > uint16_t vlan_tci_outer;  /**< Outer VLAN Tag Control 
> > > > > > Identifier (CPU order) */
> > > > > >
> > > > > > +#if RTE_CACHE_LINE_SIZE == 64
> > > > > > /* second cache line - fields only used in slow path or on TX */
> > > > > > MARKER cacheline1 __rte_cache_aligned;
> > > > > > +#endif
> > > > >
> > > > > I suppose you'll need to keep same space reserved for first 64B even 
> > > > > on systems with 128B cache-line.
> > > > > Otherwise we can endup with different mbuf format for systems with 
> > > > > 128B cache-line.
> > > >
> > > > Just to understand, Is there any issue in mbuf format being different
> > > > across the systems. I think, we are not sending the mbuf over the wire
> > > > or sharing with different system etc. right?
> > >
> > > No, we don't have to support that.
> > > At least I am not aware about such cases.
> > >
> > > >
> > > > Yes, I do understand the KNI dependency with mbuf.
> > >
> > > Are you asking about what will be broken (except KNI) if mbuf layout IA 
> > > and ARM would be different?
> > > Probably nothing right now, except vector RX/TX.
> > > But they are not supported on ARM anyway, and if someone will implement 
> > > them in future, it
> > > might 

[dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application guide

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bernard Iremonger
> Sent: Wednesday, December 9, 2015 12:36 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application
> guide
> 
> correct sample console commands
> 
> Fixes: d0dff9ba445e ("doc: sample application user guide"
> Fixes: 9bc23cb8209c ("doc: add vhost-user to sample guide")
> Fixes: 43866bf71d58 ("doc: fix vhost sample parameter")
> Signed-off-by: Bernard Iremonger 
> ---
>  doc/guides/sample_app_ug/vhost.rst | 40 +++--
>
> ...
> 
>  Redistribution and use in source and binary forms, with or without @@
> -386,13 +386,13 @@ Running the Sample Code
> 
>  .. code-block:: console
> 
> -user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir /


Also, as a general note, not just to this document/patch.

I don't think the "user at target:~$" prefixes used in some DPDK
Doc commandlines is useful.

It prevents a straight copy and paste for testing, it makes the
literal block lines longer than they should be, it isn't used
consistently everywhere, it is visually distracting (in some
cases it is longer than the command being shown), and it isn't
always correct (I presume in the above case of "user at target" you
would need run the application as sudo if you are a non root
user).

Any objections to removing these as documents are updated?


John

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Thomas Monjalon]

2015-12-09 14:39, Wiles, Keith:
> I am having a problem with ?make install T=? command as I was using it 
> before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc or 
> a different config all together. Currently the ?make install T=? gives a 
> warning message at the end of the build plus creates the 
> x86_64-native-linuxapp-XXX directory. If I use the suggested ?make config T=? 
> command this command create a directory ?build? with a .config file. The 
> problem is this method does not allow me to have multiple builds at the same 
> time.
> 
> What is the suggested method to have multiple builds without installing  into 
> the local file system?

The multiple build is not supported anymore. It was only building with
the default configuration.
If you want to test various builds, I suggest to use this script:
scripts/test-build.sh
http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c

If you just want to compile, it is simple:
make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
make O=my-gcc-build

Note: the documentation was updated when doing this change.
If you think something is missing, please comment.

[dpdk-dev] fix mbuf->port for eth_af_packet

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Krauz, Pavel
> Sent: Wednesday, December 9, 2015 2:47 PM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] fix mbuf->port for eth_af_packet
> 
> Hello,
> Here goes the patch again in the correct format.
> Thanks & b.r.
> Pavel

Hi Pavel,

There wasn't a patch submitted that I can see. Maybe send a few test emails to 
yourself first to see if it works.

Also, once it is working you should send the email to the maintainer of 
af_packet and CC dev at dpdk.org. 

$ grep -B 1 af_packet MAINTAINERS 
M: John W. Linville 
F: drivers/net/af_packet/

You will also need to mark the previous patch(es) as superseded:

http://dpdk.org/dev/patchwork/project/dpdk/list/?submitter=390

John.
-- 

[dpdk-dev] Buildroot support for DPDK 2.2.0-rc3

[Jan Viktorin]

On Wed, 9 Dec 2015 20:17:44 +0530
Santosh Shukla  wrote:

> Its encouraging.
> 
> Could you pl. post buildroot how-to patch to dpdk-dev mailing list, after
> your work gets accepted in buildroot.

Yes. What exactly do you mean by "how-to patch"?

> 
> Thanks
> 
> On Wed, Dec 9, 2015 at 8:10 PM, Jan Viktorin 
> wrote:
> 
> > Hello,
> >
> > I've posted a new patch set with DPDK support into the Buildroot project:
> >
> > http://lists.busybox.net/pipermail/buildroot/2015-December/146564.html
> >
> > Patchwork:
> >
> > https://patchwork.ozlabs.org/patch/554673/
> > https://patchwork.ozlabs.org/patch/554674/
> > https://patchwork.ozlabs.org/patch/554675/
> >
> > After I integrate the new DPDK install rules and fix some minor issues,
> > I assume that it will be accepted upstream there. Buildroot is useful
> > at least for cross toolchain generation.
> >
> > Regards
> > Jan
> >
> > --
> >Jan Viktorin  E-mail: Viktorin at RehiveTech.com
> >System Architect  Web:www.RehiveTech.com
> >RehiveTech
> >Brno, Czech Republic
> >  



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

[dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application guide

[Thomas Monjalon]

2015-12-09 14:50, Mcnamara, John:
> Also, as a general note, not just to this document/patch.
> 
> I don't think the "user at target:~$" prefixes used in some DPDK
> Doc commandlines is useful.
> 
> It prevents a straight copy and paste for testing, it makes the
> literal block lines longer than they should be, it isn't used
> consistently everywhere, it is visually distracting (in some
> cases it is longer than the command being shown), and it isn't
> always correct (I presume in the above case of "user at target" you
> would need run the application as sudo if you are a non root
> user).
> 
> Any objections to removing these as documents are updated?

Generally speaking, +1 to remove extra bytes :)

[dpdk-dev] Buildroot support for DPDK 2.2.0-rc3

[Santosh Shukla]

On Wed, Dec 9, 2015 at 8:34 PM, Jan Viktorin  wrote:
>
> On Wed, 9 Dec 2015 20:17:44 +0530
> Santosh Shukla  wrote:
>
> > Its encouraging.
> >
> > Could you pl. post buildroot how-to patch to dpdk-dev mailing list, after
> > your work gets accepted in buildroot.
>
> Yes. What exactly do you mean by "how-to patch"?
>

Some readme which has example script that any user could use to build
and validate(optional though, depends upon v7/v8 both hw availability
for user) before submitting patch.

>
> >
> > Thanks
> >
> > On Wed, Dec 9, 2015 at 8:10 PM, Jan Viktorin 
> > wrote:
> >
> > > Hello,
> > >
> > > I've posted a new patch set with DPDK support into the Buildroot project:
> > >
> > > http://lists.busybox.net/pipermail/buildroot/2015-December/146564.html
> > >
> > > Patchwork:
> > >
> > > https://patchwork.ozlabs.org/patch/554673/
> > > https://patchwork.ozlabs.org/patch/554674/
> > > https://patchwork.ozlabs.org/patch/554675/
> > >
> > > After I integrate the new DPDK install rules and fix some minor issues,
> > > I assume that it will be accepted upstream there. Buildroot is useful
> > > at least for cross toolchain generation.
> > >
> > > Regards
> > > Jan
> > >
> > > --
> > >Jan Viktorin  E-mail: Viktorin at RehiveTech.com
> > >System Architect  Web:www.RehiveTech.com
> > >RehiveTech
> > >Brno, Czech Republic
> > >
>
>
>
> --
>Jan Viktorin  E-mail: Viktorin at RehiveTech.com
>System Architect  Web:www.RehiveTech.com
>RehiveTech
>Brno, Czech Republic

[dpdk-dev] fix mbuf->port for eth_af_packet

[Thomas Monjalon]

2015-12-09 15:03, Mcnamara, John:
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Krauz, Pavel
> > Hello,
> > Here goes the patch again in the correct format.
> > Thanks & b.r.
> > Pavel
> 
> Hi Pavel,
> 
> There wasn't a patch submitted that I can see. Maybe send a few test emails 
> to yourself first to see if it works.
> 
> Also, once it is working you should send the email to the maintainer of 
> af_packet and CC dev at dpdk.org. 
> 
> $ grep -B 1 af_packet MAINTAINERS 
> M: John W. Linville 
> F: drivers/net/af_packet/
> 
> You will also need to mark the previous patch(es) as superseded:
> 
> http://dpdk.org/dev/patchwork/project/dpdk/list/?submitter=390

Thanks John for reminding the guidelines.

Pavel, it seems to be your first contribution to DPDK.
If you cannot submit it properly with git, we'll manage it
manually. We just need a description of the issue and a Signed-off.
Thanks

[dpdk-dev] [PATCH 1/1] arm: set CONFIG_RTE_ARCH_STRICT_ALIGN=y for armv7 target

[Jan Viktorin]

This patch reduces number of warnings from 53 to 40. It removes the usual false
positives utilizing unaligned_uint*_t data types.

Signed-off-by: Jan Viktorin 
---
As far as I know, only a 64-bit unaligned access can be a problem for ARMv7.
I found only one such occurence:

118 struct rte_mbuf *   

119 rte_ipv4_frag_reassemble_packet(struct rte_ip_frag_tbl *tbl,

120 struct rte_ip_frag_death_row *dr, struct rte_mbuf *mb, 
uint64_t tms,
121 struct ipv4_hdr *ip_hdr)
...
133 psd = (unaligned_uint64_t *)&ip_hdr->src_addr;  

134 /* use first 8 bytes only */

135 key.src_dst[0] = psd[0];

136 key.id = ip_hdr->packet_id; 

137 key.key_len = IPV4_KEYLEN

Is this a real issue?
---
 config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index cbebd64..2482d91 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -39,6 +39,7 @@ CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
 CONFIG_RTE_ARCH_ARM_NEON=y

 CONFIG_RTE_FORCE_INTRINSICS=y
+CONFIG_RTE_ARCH_STRICT_ALIGN=y

 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
-- 
2.6.3

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Wiles, Keith]

On 12/9/15, 8:59 AM, "Thomas Monjalon"  wrote:

>2015-12-09 14:39, Wiles, Keith:
>> I am having a problem with ?make install T=? command as I was using it 
>> before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc 
>> or a different config all together. Currently the ?make install T=? gives a 
>> warning message at the end of the build plus creates the 
>> x86_64-native-linuxapp-XXX directory. If I use the suggested ?make config 
>> T=? command this command create a directory ?build? with a .config file. The 
>> problem is this method does not allow me to have multiple builds at the same 
>> time.
>> 
>> What is the suggested method to have multiple builds without installing  
>> into the local file system?
>
>The multiple build is not supported anymore. It was only building with
>the default configuration.
>If you want to test various builds, I suggest to use this script:
>   scripts/test-build.sh
>   http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c

Having a build script is great, but it give me an error on building. The script 
does not have a ?help option and the unknown option is not very usefulas it 
does not explain the two option -jX and -s in that output message. I would have 
expected a bit more help instructions on using this command and adding a -h or 
?help would be useful. 

The error I get from the following command is: './scripts/test-build.sh 
x86_64-native-linuxapp-gcc? building on a Ubuntu 15.10 with all patches. If I 
use ?make install T=x86_64-native-linuxapp-gcc? this command builds correctly 
with the warning at the end.

Custom configuration
Configuration done
Configuration done
Using local configuration
== Build lib
== Build lib/librte_compat
== Build lib/librte_eal
== Build lib/librte_net
  SYMLINK-FILE include/rte_compat.h
  SYMLINK-FILE include/rte_ip.h
  SYMLINK-FILE include/rte_tcp.h
  SYMLINK-FILE include/rte_udp.h
  SYMLINK-FILE include/rte_sctp.h
  SYMLINK-FILE include/rte_icmp.h
  SYMLINK-FILE include/rte_arp.h
== Build lib/librte_eal/common
  SYMLINK-FILE include/generic/rte_atomic.h
  SYMLINK-FILE include/generic/rte_byteorder.h
  SYMLINK-FILE include/generic/rte_cycles.h
  SYMLINK-FILE include/generic/rte_prefetch.h
  SYMLINK-FILE include/generic/rte_spinlock.h
  SYMLINK-FILE include/generic/rte_memcpy.h
  SYMLINK-FILE include/generic/rte_cpuflags.h
  SYMLINK-FILE include/generic/rte_rwlock.h
  SYMLINK-FILE include/rte_branch_prediction.h
  SYMLINK-FILE include/rte_common.h
  SYMLINK-FILE include/rte_debug.h
  SYMLINK-FILE include/rte_eal.h
  SYMLINK-FILE include/rte_errno.h
  SYMLINK-FILE include/rte_launch.h
  SYMLINK-FILE include/rte_lcore.h
  SYMLINK-FILE include/rte_log.h
  SYMLINK-FILE include/rte_memory.h
  SYMLINK-FILE include/rte_memzone.h
  SYMLINK-FILE include/rte_pci.h
  SYMLINK-FILE include/rte_pci_dev_ids.h
  SYMLINK-FILE include/rte_per_lcore.h
  SYMLINK-FILE include/rte_random.h
  SYMLINK-FILE include/rte_interrupts.h
  SYMLINK-FILE include/rte_alarm.h
  SYMLINK-FILE include/rte_string_fns.h
  SYMLINK-FILE include/rte_version.h
  SYMLINK-FILE include/rte_tailq.h
  SYMLINK-FILE include/rte_eal_memconfig.h
  SYMLINK-FILE include/rte_malloc_heap.h
  SYMLINK-FILE include/rte_hexdump.h
  SYMLINK-FILE include/rte_devargs.h
  SYMLINK-FILE include/rte_dev.h
  SYMLINK-FILE include/rte_pci_dev_feature_defs.h
  SYMLINK-FILE include/rte_pci_dev_features.h
  SYMLINK-FILE include/rte_malloc.h
  SYMLINK-FILE include/rte_keepalive.h
  SYMLINK-FILE include/rte_time.h
  SYMLINK-FILE include/rte_rwlock.h
  SYMLINK-FILE include/rte_memcpy.h
  SYMLINK-FILE include/rte_cycles.h
  SYMLINK-FILE include/rte_spinlock.h
  SYMLINK-FILE include/rte_atomic_32.h
  SYMLINK-FILE include/rte_vect.h
  SYMLINK-FILE include/rte_prefetch.h
  SYMLINK-FILE include/rte_byteorder_32.h
  SYMLINK-FILE include/rte_atomic_64.h
  SYMLINK-FILE include/rte_byteorder_64.h
  SYMLINK-FILE include/rte_cpuflags.h
  SYMLINK-FILE include/rte_rtm.h
  SYMLINK-FILE include/rte_atomic.h
  SYMLINK-FILE include/rte_byteorder.h
== Build lib/librte_eal/linuxapp
== Build lib/librte_eal/linuxapp/igb_uio
== Build lib/librte_eal/linuxapp/eal
  CC eal.o
  CC eal_hugepage_info.o
  CC eal_memory.o
  CC eal_thread.o
  CC eal_log.o
  CC eal_pci_vfio.o
  CC eal_debug.o
  CC eal_pci_uio.o
  CC eal_pci.o
  CC eal_alarm.o
  CC eal_common_lcore.o
  CC eal_common_launch.o
  CC eal_common_memzone.o
  CC eal_common_pci.o
  CC eal_lcore.o
  CC eal_pci_vfio_mp_sync.o
  CC eal_common_pci_uio.o
  CC eal_common_timer.o
  CC eal_interrupts.o
  CC eal_timer.o
  CC eal_common_memory.o
  CC eal_common_log.o
  CC eal_common_cpuflags.o
  CC eal_common_errno.o
  CC eal_common_string_fns.o
  CC eal_common_tailqs.o
  CC eal_common_hexdump.o
  CC rte_malloc.o
  SYMLINK-FILE include/exec-env/rte_interrupts.h
  SYMLINK-FILE include/exec-env/rte_dom0_common.h
  SYMLINK-FILE include/exec-env/rte_kni_common.h
  CC malloc_elem.o
  CC eal_common_devargs.o
  CC eal_common_dev.o
  CC eal_common_thread.o
  CC malloc_heap.o
  CC e

[dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application guide

[Iremonger, Bernard]

Hi John,



> Hi Bernard,
> 
> Thanks for that. One comment (in several places):
> 
> 
> >  .. code-block:: console
> >
> > -user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir
> /mnt/huge -- -p 0x1 --dev-basename usvhost
> > +user at target:~$ ./build/app/vhost-switch -c f -n 4
> > + --socket-mem 1024 --huge-dir /mnt/huge -- -p 0x1 --dev-basename
> > + usvhost
> 
> These long lines in code blocks don't render correctly in the PDF docs. The
> Documentation Guidelines suggest using a commandline line continuation to
> maintain functionality within an 80 char doc limit:
> 
>http://dpdk.org/doc/guides/contributing/documentation.html#code-and-
> literal-block-sections
> 
> So something like this:
> 
> user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 --
> huge-dir /mnt/huge -- -p 0x1 --dev-basename usvhost
> 
> Could be written as:
> 
> user at target:~$ ./build/app/vhost-switch -c f -n 4 --socket-mem 1024 \
>  --huge-dir /mnt/huge -- -p 0x1 --dev-basename usvhost
> 
> Or:
> 
> user at target:~$ ./build/app/vhost-switch -c f -n 4 \
> --socket-mem 1024 \
> --huge-dir /mnt/huge \
> -- -p 0x1 --dev-basename usvhost
> 
> Regards,
> 
> John.
> --

I will use a command line continuation character to stay within 80 character 
limit.

Regards,

Bernard.

[dpdk-dev] [PATCH 1/1] doc: correct Vhost Sample Application guide

[Iremonger, Bernard]

Hi John,


> 2015-12-09 14:50, Mcnamara, John:
> > Also, as a general note, not just to this document/patch.
> >
> > I don't think the "user at target:~$" prefixes used in some DPDK Doc
> > commandlines is useful.
> >
> > It prevents a straight copy and paste for testing, it makes the
> > literal block lines longer than they should be, it isn't used
> > consistently everywhere, it is visually distracting (in some cases it
> > is longer than the command being shown), and it isn't always correct
> > (I presume in the above case of "user at target" you would need run the
> > application as sudo if you are a non root user).
> >
> > Any objections to removing these as documents are updated?
> 
> Generally speaking, +1 to remove extra bytes :)

I will remove the "user at target:~$"  prefixes in this document.

Regards,

Bernard.

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Thomas Monjalon]

2015-12-09 15:32, Wiles, Keith:
> On 12/9/15, 8:59 AM, "Thomas Monjalon"  wrote:
> 
> >2015-12-09 14:39, Wiles, Keith:
> >> I am having a problem with ?make install T=? command as I was using it 
> >> before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc 
> >> or a different config all together. Currently the ?make install T=? gives 
> >> a warning message at the end of the build plus creates the 
> >> x86_64-native-linuxapp-XXX directory. If I use the suggested ?make config 
> >> T=? command this command create a directory ?build? with a .config file. 
> >> The problem is this method does not allow me to have multiple builds at 
> >> the same time.
> >> 
> >> What is the suggested method to have multiple builds without installing  
> >> into the local file system?
> >
> >The multiple build is not supported anymore. It was only building with
> >the default configuration.
> >If you want to test various builds, I suggest to use this script:
> > scripts/test-build.sh
> > http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c
> 
> Having a build script is great, but it give me an error on building. The 
> script does not have a ?help option and the unknown option is not very 
> usefulas it does not explain the two option -jX and -s in that output 
> message. I would have expected a bit more help instructions on using this 
> command and adding a -h or ?help would be useful. 

Please check.
There is a -h option.

> The error I get from the following command is: './scripts/test-build.sh 
> x86_64-native-linuxapp-gcc? building on a Ubuntu 15.10 with all patches. If I 
> use ?make install T=x86_64-native-linuxapp-gcc? this command builds correctly 
> with the warning at the end.
[...]
> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c: 
> In function \u2018pci_config_extended_tag\u2019:
> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:505:2:
>  error: ignoring return value of \u2018fgets\u2019, declared with attribute 
> warn_unused_result [-Werror=unused-result]
>   fgets(buf, sizeof(buf), f);
>   ^

It is a compilation error, not related to the script.

> >If you just want to compile, it is simple:
> > make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
> > make O=my-gcc-build
> 
> IMO we have gone backwards in making DPDK easy to build. I agree using ?make 
> install T=? may not be the best solution as ?install? implies we are 
> installing the code. I agree not we should not try to build multiple 
> configuration with one command, but we should be able to do ?make build 
> T=x86_64-native-linuxapp-gcc? to replace the ?make install T=? command. Now 
> the developer only needs to type one command with to build a configuration 
> and not two. If the developer includes the ?O=? option then the command 
> should create that directory and build the configuration into that directory. 
> For the 80% rule the ?O=? option should not be required.

The O= option is not required.
The new syntax is closer to the standard behaviour.
You just don't want to type "make config" because you are using a default
configuration.

> The ?make config T= O=? then ?make O=? series of commands are not required, 
> even the ?config? keyword is not required and just an extra step we do not 
> need. What does the ?config? target really add to the made other then 
> creating the ?build? directory and a config file. I believe the ?build? 
> directory should be dropped/removed all together and just require the ?T=? 
> and/or the ?O=? if they really want to define a different output directory.

Between "make config" and "make" you can modify the configuration.
In the next release, "make config" will be wrapped by a "configure" script
which will allow to configure your target in one line.
So we will end up with:
./configure
make
make install
It may be weird to you but it is standard to others.

[dpdk-dev] [PATCH] doc: add patch submit cheatsheet

[Harry van Haaren]

This patch adds the patch submission cheatsheet to
the contributers guide. Both HTML and PDF docs show
the cheatsheet on its own page.

Right clicking the SVG image in the HTML doc allows
for viewing the image on its own, useful for printing
in high quality.

The exact appearance of of the cheatsheet will depend
on the default monospace font installed.

Signed-off-by: Harry van Haaren 
---
 doc/guides/contributing/img/patch_cheatsheet.svg | 1404 ++
 doc/guides/contributing/index.rst|1 +
 2 files changed, 1405 insertions(+)
 create mode 100644 doc/guides/contributing/img/patch_cheatsheet.svg

diff --git a/doc/guides/contributing/img/patch_cheatsheet.svg 
b/doc/guides/contributing/img/patch_cheatsheet.svg
new file mode 100644
index 000..716df89
--- /dev/null
+++ b/doc/guides/contributing/img/patch_cheatsheet.svg
@@ -0,0 +1,1404 @@
+
+
+
+http://purl.org/dc/elements/1.1/";
+   xmlns:cc="http://creativecommons.org/ns#";
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
+   xmlns:svg="http://www.w3.org/2000/svg";
+   xmlns="http://www.w3.org/2000/svg";
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
+   version="1.1"
+   width="210mm"
+   height="297mm"
+   id="svg2985"
+   inkscape:version="0.48.4 r9939"
+   sodipodi:docname="patch_cheatsheet.svg">
+  
+  
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+  
+  
+
+  
+image/svg+xml
+http://purl.org/dc/dcmitype/StillImage"; />
+
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+
+
+
+  
+  
+  
+
+
+
+
+  
+  
+
+
+  
+
+
+
+
+  
+  
+  
+
+
+
+
+  
+  
+
+
+  
+
+
+
+
+  
+  
+  
+
+
+
+
+  
+  
+
+  
+  
+
+  
+  
+  
+  
+
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
+  
+
+
+  CHEATSHEET
+  PATCH SUBMIT
+
+
+
+
+
+Patch Pre-Checks
+Commit Pre-Checks
+Bugfix?
+Git send-email 
+
+
+Compile Pre-Checks
+
+  + Include warning/error
+  + Fixes line
+  + How to reproduce
+
++ Patch version ( eg: -v2 ) 
++ Patch version annotations
++ Send --to maintainer 
++ Send --cc dev at dpdk.org 
+
+  
++ build gcc icc clang 
++ make test 
++ make doc
++ make examples
++ make shared-lib
++ library ABI version
++ build 32 and 64 bits
+  
+
++ Cover letter
+git send-email -N --to  --cc dev at 
dpdk.org  --annotate [ --cover-letter --cc other at 
participants.com  -v[N]  --in-reply-to  
]
+harry.van.haaren
 at intel.com
+
+Suggestions / Updates?
+
+  + Send --in-reply-to 
+  
+
+v1.0
+
+
+
+
+
+
+
+  + Signed-off-by: 
+  + Suggested-by:
+  + Reported-by:
+  + Tested-by:
+  
++ Previous Acks
+*
+  
+  + Commit message
+
+
+Mailing List
++ Acked-by:
++ Reviewed-by:
+Nack (refuse patch)
+
+
++ Tested-by:
+
+  Previous
 Acks only when fixing typos, rebased, or checkpatch issues.
+  *
+
+
+  The
 version.map function names must be in alphabetical order.
+  *
+  *
+
+
+  
++ Rebase to git  
++ Checkpatch 
++ ABI breakage 
++ Maintainers file
++ Release notes
++ Documentation
+
+  
+**
+  
+  + Update version.map
+
+
+  + Doxygen
+  
+***
+  
+
+  
+
++
+

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

[Stephen Hemminger]

On Wed, 9 Dec 2015 14:19:58 +0100
Kamil Rytarowski  wrote:

> + /* Check if there is sysfs mounted */
> + if (stat("/sys/module", &st) != 0) {
> + RTE_LOG(DEBUG, EAL, "sysfs is not mounted! error %i (%s)\n",
> + errno, strerror(errno));
>   return -1;
>   }

This check is redundant. Remove it.
If the later "/sys/module/foo" would fail if /sys/module was not present.

> - while (!feof(fd)) {
> - n = fscanf(fd, "%29s %*[^\n]", mod_name);
> - if ((n == 1) && !strcmp(mod_name, module_name)) {
> - ret = 1;
> - break;
> - }
> +
> + /* A module might be built-in, therefore try sysfs */
> + n = snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", module_name);

[dpdk-dev] [PATCH] doc: add patch submit cheatsheet

[Thomas Monjalon]

2015-12-09 16:23, Harry van Haaren:
> This patch adds the patch submission cheatsheet to
> the contributers guide. Both HTML and PDF docs show
> the cheatsheet on its own page.

Very nice Harry!
2 comments below.

> Right clicking the SVG image in the HTML doc allows
> for viewing the image on its own, useful for printing
> in high quality.
> 
> The exact appearance of of the cheatsheet will depend
> on the default monospace font installed.
> 
> Signed-off-by: Harry van Haaren 
[...]
> +   
> style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace
>  Bold">+ Fixes line

It would be better with a colon:
Fixes: line

> + y="905.1391">git send-email -N --to  --cc dev at 
> dpdk.org

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

[Kamil Rytarowski]

W dniu 09.12.2015 o 17:38, Stephen Hemminger pisze:
> On Wed, 9 Dec 2015 14:19:58 +0100
> Kamil Rytarowski  wrote:
>
>> +/* Check if there is sysfs mounted */
>> +if (stat("/sys/module", &st) != 0) {
>> +RTE_LOG(DEBUG, EAL, "sysfs is not mounted! error %i (%s)\n",
>> +errno, strerror(errno));
>>  return -1;
>>  }
> This check is redundant. Remove it.
> If the later "/sys/module/foo" would fail if /sys/module was not present.
This check isn't redundant. It checks different thing (sysfs mounted vs 
module loaded) and formulates different error message.

Please see pci_vfio_enable():

 module_vfio_type1 = rte_eal_check_module("vfio_iommu_type1");

 /* return error directly */
 if (module_vfio_type1 == -1) {
 RTE_LOG(INFO, EAL, "Could not get loaded module 
details!\n");
 return -1;
 }

 /* return 0 if VFIO modules not loaded */
 if (module_vfio_type1 == 0) {
 RTE_LOG(INFO, EAL, "VFIO modules not all loaded, "
 "skip VFIO support...\n");
 return 0;
 }

[dpdk-dev] [PATCH] doc: add patch submit cheatsheet

[Van Haaren, Harry]

> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> It would be better with a colon:
>   Fixes: line

Ok, will send a v2 with that fix.

> > git send-email -N --to 
> Why -N?

-N sets the Number of patches to send, when not sending .patch files but 
sending the latest commits of the current branch in git.

Would you prefer if the sending of .patch files was documented? I'm indifferent 
- but learned the -N way first :)

[dpdk-dev] [PATCH] doc: add patch submit cheatsheet

[Thomas Monjalon]

2015-12-09 16:47, Van Haaren, Harry:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > It would be better with a colon:
> > Fixes: line
> 
> Ok, will send a v2 with that fix.
> 
> > > git send-email -N --to 
> > Why -N?
> 
> -N sets the Number of patches to send, when not sending .patch files but 
> sending the latest commits of the current branch in git.
> 
> Would you prefer if the sending of .patch files was documented? I'm 
> indifferent - but learned the -N way first :)

No it's OK.
We just need to understand that N must be replaced by a number.
Maybe - ?

[dpdk-dev] [PATCH] doc: add patch submit cheatsheet

[Bruce Richardson]

On Wed, Dec 09, 2015 at 04:47:42PM +, Van Haaren, Harry wrote:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > It would be better with a colon:
> > Fixes: line
> 
> Ok, will send a v2 with that fix.
> 
> > > git send-email -N --to 
> > Why -N?
> 
> -N sets the Number of patches to send, when not sending .patch files but 
> sending the latest commits of the current branch in git.
> 
> Would you prefer if the sending of .patch files was documented? I'm 
> indifferent - but learned the -N way first :)

>From my point of view, yes. I think using format-patch followed by a separate
send-email is a better, and safer, workflow, as it allows multiple edits and
checks of the patches before sending.

/Bruce

[dpdk-dev] [PATCH v2 1/1] doc: correct Vhost Sample Application guide

[Bernard Iremonger]

correct sample console commands

changes in v2:
remove "user at target:~$" prefixes in command lines.
use continuation character to stay within 80 character limit.
wrap sample python code.

Fixes: d0dff9ba445e ("doc: sample application user guide"
Fixes: 9bc23cb8209c ("doc: add vhost-user to sample guide")
Fixes: 43866bf71d58 ("doc: fix vhost sample parameter")
Signed-off-by: Bernard Iremonger 
---
 doc/guides/sample_app_ug/vhost.rst | 99 --
 1 file changed, 64 insertions(+), 35 deletions(-)

diff --git a/doc/guides/sample_app_ug/vhost.rst 
b/doc/guides/sample_app_ug/vhost.rst
index ceeaf52..21b5360 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -1,6 +1,6 @@

 ..  BSD LICENSE
-Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
@@ -275,7 +275,7 @@ For vhost cuse:

 .. code-block:: console

-user at target:~$ qemu-system-x86_64 ... \
+qemu-system-x86_64 ... \
 -netdev tap,id=hostnet1,vhost=on,vhostfd= \
 -device virtio-net-pci, netdev=hostnet1,id=net1 \
 -netdev tap,id=hostnet2,vhost=on,vhostfd= \
@@ -285,7 +285,7 @@ For vhost user:

 .. code-block:: console

-user at target:~$ qemu-system-x86_64 ... \
+qemu-system-x86_64 ... \
 -chardev socket,id=char1,path= \
 -netdev type=vhost-user,id=hostnet1,chardev=char1 \
 -device virtio-net-pci,netdev=hostnet1,id=net1 \
@@ -378,7 +378,7 @@ Running the Sample Code
 .. code-block:: console

 export RTE_SDK=/path/to/rte_sdk
-cd ${RTE_SDK}/examples/vhost
+cd ${RTE_SDK}/examples/vhost/build/app

 #.  Run the vhost-switch sample code:

@@ -386,13 +386,15 @@ Running the Sample Code

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / 
mnt/huge -- -p 0x1 --dev-basename usvhost
+./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \
+ -- -p 0x1 --dev-basename usvhost

 vhost user: a socket file named usvhost will be created under current 
directory. Use its path as the socket path in guest's qemu commandline.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / 
mnt/huge -- -p 0x1 --dev-basename usvhost
+./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \
+ -- -p 0x1 --dev-basename usvhost

 .. note::

@@ -411,7 +413,8 @@ For compatibility with the QEMU wrapper script, a base name 
of "usvhost" should

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- -p 0x1 --dev-basename usvhost
+./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \
+ -- -p 0x1 --dev-basename usvhost

 **vm2vm.**
 The vm2vm parameter disable/set mode of packet switching between guests in the 
host.
@@ -424,7 +427,8 @@ which bases on the packet destination MAC address and VLAN 
tag.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir /mnt/huge 
-- --vm2vm [0,1,2]
+./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \
+ -- --vm2vm [0,1,2]

 **Mergeable Buffers.**
 The mergeable buffers parameter controls how virtio-net descriptors are used 
for virtio-net headers.
@@ -434,7 +438,8 @@ The default value is 0 or disabled since recent kernels 
virtio-net drivers show

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --mergeable [0,1]
+./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \
+ -- --mergeable [0,1]

 **Stats.**
 The stats parameter controls the printing of virtio-net device statistics.
@@ -442,7 +447,8 @@ The parameter specifies an interval second to print 
statistics, with an interval

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --stats [0,n]
+./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \
+-- --stats [0,n]

 **RX Retry.**
 The rx-retry option enables/disables enqueue retries when the guests RX queue 
is full.
@@ -452,7 +458,8 @@ This option is enabled by default.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --rx-retry [0,1]
+./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \
+ -- --rx-retry [0,1]

 **RX Retry Number.**
 The rx-retry-num option specifies the number of retries on an RX burst,
@@ -461,7 +468,8 @@ The default value is 4.

 .. code-block:: console

-user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge 
-- --rx-retry 1 --rx-retry-num 5
+./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \
+ -- --rx-retry 1 --rx-retry-num 5

 **RX Retry Delay Time.**
 Th

[dpdk-dev] [PATCH v2] doc: add patch submit cheatsheet

[Harry van Haaren]

This patch adds the patch submission cheatsheet to
the contributers guide. Both HTML and PDF docs show
the cheatsheet on its own page.

Right clicking the SVG image in the HTML doc allows
for viewing the image on its own, useful for printing
in high quality.

The exact appearance of of the cheatsheet will depend
on the default monospace font installed.

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

v2: Fixed Fixes: line, added format-patch workflow instead
of using -N for setting the number of patches during send-email.

 doc/guides/contributing/img/patch_cheatsheet.svg | 1484 ++
 doc/guides/contributing/index.rst|1 +
 2 files changed, 1485 insertions(+)
 create mode 100644 doc/guides/contributing/img/patch_cheatsheet.svg

diff --git a/doc/guides/contributing/img/patch_cheatsheet.svg 
b/doc/guides/contributing/img/patch_cheatsheet.svg
new file mode 100644
index 000..8522592
--- /dev/null
+++ b/doc/guides/contributing/img/patch_cheatsheet.svg
@@ -0,0 +1,1484 @@
+
+
+
+http://purl.org/dc/elements/1.1/";
+   xmlns:cc="http://creativecommons.org/ns#";
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
+   xmlns:svg="http://www.w3.org/2000/svg";
+   xmlns="http://www.w3.org/2000/svg";
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
+   version="1.1"
+   width="210mm"
+   height="297mm"
+   id="svg2985"
+   inkscape:version="0.48.4 r9939"
+   sodipodi:docname="patch_cheatsheet.svg">
+  
+  
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+  
+  
+
+  
+image/svg+xml
+http://purl.org/dc/dcmitype/StillImage"; />
+
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+
+
+
+  
+  
+  
+
+
+
+
+  
+  
+
+
+  
+
+
+
+
+  
+  
+  
+
+
+
+
+  
+  
+
+
+  
+
+
+
+
+  
+  
+  
+
+
+
+
+  
+  
+
+  
+  
+
+  
+  
+  
+  
+
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
+  
+
+
+  CHEATSHEET
+  PATCH SUBMIT
+
+
+
+
+
+Patch Pre-Checks
+Commit Pre-Checks
+Bugfix?
+Git send-email 
+
+
+Compile Pre-Checks
+
+  + Include warning/error
+  + Fixes: line
+  + How to reproduce
+
+
+  
++ build gcc icc clang 
++ make test doc 
++ make examples
++ make shared-lib
++ library ABI version
++ build 32 and 64 bits
+  
+
+git send-email *.patch --annotate --to 
  --cc dev at dpdk.org [ --cc other at 
participants.com  --cover-letter -v[N] --in-reply-to  ]
+harry.van.haaren
 at intel.com
+
+Suggestions / Updates?
+
+  + Patch version ( eg: -v2 ) 
+  + Patch version annotations
+  + Send --to maintainer 
+  + Send --cc dev at dpdk.org 
+  + Cover letter
+  
++ Send --in-reply-to 
+
+  
+
+v1.0
+
+
+
+
+
+
+
+  + Signed-off-by: 
+  + Suggested-by:
+  + Reported-by:
+  + Tested-by:
+  
++ Previous Acks
+*
+  
+  + Commit message
+
+
+Mailing List
++ Acked-by:
++ Reviewed-by:
+Nack (refuse patch)
+
+
++ Tested-by:
+
+  Previous
 Acks only when fixing typos, rebased, or checkpatch issues.
+  *
+
+
+  The
 version.map function names must be in alphabetical order.
+  *
+  *
+
+
+  
++ Rebase to git  
++ Checkpatch 
++ ABI breakage 
++ Maintainers file
++ Release notes
++ Documentation
+
+  
+**
+  
+ 

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Wiles, Keith]

On 12/9/15, 10:19 AM, "Thomas Monjalon"  wrote:

>2015-12-09 15:32, Wiles, Keith:
>> On 12/9/15, 8:59 AM, "Thomas Monjalon"  wrote:
>> 
>> >2015-12-09 14:39, Wiles, Keith:
>> >> I am having a problem with ?make install T=? command as I was using it 
>> >> before. I would normally build a x86_64-native-linuxapp-gcc, clang and 
>> >> icc or a different config all together. Currently the ?make install T=? 
>> >> gives a warning message at the end of the build plus creates the 
>> >> x86_64-native-linuxapp-XXX directory. If I use the suggested ?make config 
>> >> T=? command this command create a directory ?build? with a .config file. 
>> >> The problem is this method does not allow me to have multiple builds at 
>> >> the same time.
>> >> 
>> >> What is the suggested method to have multiple builds without installing  
>> >> into the local file system?
>> >
>> >The multiple build is not supported anymore. It was only building with
>> >the default configuration.
>> >If you want to test various builds, I suggest to use this script:
>> >scripts/test-build.sh
>> >http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c
>> 
>> Having a build script is great, but it give me an error on building. The 
>> script does not have a ?help option and the unknown option is not very 
>> usefulas it does not explain the two option -jX and -s in that output 
>> message. I would have expected a bit more help instructions on using this 
>> command and adding a -h or ?help would be useful. 
>
>Please check.
>There is a -h option.

The -h option gives the same output as the a unknown option:

rkwiles at rkwiles-supermicro (master):~/.../intel/dpdk$ 
./scripts/test-build.sh -h
usage: test-build.sh [-jX] [-s] [config1 [config2] ...]]
rkwiles at rkwiles-supermicro (master):~/.../intel/dpdk$ 


My point was more around the content of the help as it is not very useful as to 
what the -jX or -s options are, please add more help information as ?man 
test-build.sh? does not work :-)

>
>> The error I get from the following command is: './scripts/test-build.sh 
>> x86_64-native-linuxapp-gcc? building on a Ubuntu 15.10 with all patches. If 
>> I use ?make install T=x86_64-native-linuxapp-gcc? this command builds 
>> correctly with the warning at the end.
>[...]
>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:
>>  In function \u2018pci_config_extended_tag\u2019:
>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:505:2:
>>  error: ignoring return value of \u2018fgets\u2019, declared with attribute 
>> warn_unused_result [-Werror=unused-result]
>>   fgets(buf, sizeof(buf), f);
>>   ^
>
>It is a compilation error, not related to the script.

This is strange the ?make install T=? command just works, how do you explain 
that problem.
The test-build.sh script should be do some setup then ?make config T= ; make? 
so why is this script not working?

The script should work as expected with ?./scripts/test-build.sh 
x86_64-native-linuxapp-gcc? correct?

Could be something wrong with my system, but I doubt it.

>
>> >If you just want to compile, it is simple:
>> >make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
>> >make O=my-gcc-build
>> 
>> IMO we have gone backwards in making DPDK easy to build. I agree using ?make 
>> install T=? may not be the best solution as ?install? implies we are 
>> installing the code. I agree not we should not try to build multiple 
>> configuration with one command, but we should be able to do ?make build 
>> T=x86_64-native-linuxapp-gcc? to replace the ?make install T=? command. Now 
>> the developer only needs to type one command with to build a configuration 
>> and not two. If the developer includes the ?O=? option then the command 
>> should create that directory and build the configuration into that 
>> directory. For the 80% rule the ?O=? option should not be required.
>
>The O= option is not required.
>The new syntax is closer to the standard behaviour.
>You just don't want to type "make config" because you are using a default
>configuration.

I understand the O= option is not required. I would have liked it to pick the 
closest configuration to the host system if x86-64 then pick 
x86_64-native-linuxapp-gcc GCC is the normal default compiler, if a ARM-v7 
system then pick the correct configuration or powerpc ?
If they want something else then let them use the ?T=? option. This would have 
been a nice to have feature, but not a requirement.

>
>> The ?make config T= O=? then ?make O=? series of commands are not required, 
>> even the ?config? keyword is not required and just an extra step we do not 
>> need. What does the ?config? target really add to the made other then 
>> creating the ?build? directory and a config file. I believe the ?build? 
>> directory should be dropped/removed all together and just require the ?T=? 
>> and/or the ?O=? if they really want to define a different output directory.
>
>Between "make config" and "make" you

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Wiles, Keith]

On 12/9/15, 11:31 AM, "dev on behalf of Wiles, Keith"  wrote:

>On 12/9/15, 10:19 AM, "Thomas Monjalon"  wrote:

BTW, I am not overly concerned about the build system per say I just wish I had 
put my $0.02 worth in before the change. We can leave as it is now.

The test-build.sh script build does appear to be a real problem. I would like 
to understand why it does not work. Adding a better help message should be an 
easy fix for someone that wrote the script or I can make the changes, just let 
me know.

>
>>2015-12-09 15:32, Wiles, Keith:
>>> On 12/9/15, 8:59 AM, "Thomas Monjalon"  wrote:
>>> 
>>> >2015-12-09 14:39, Wiles, Keith:
>>> >> I am having a problem with ?make install T=? command as I was using it 
>>> >> before. I would normally build a x86_64-native-linuxapp-gcc, clang and 
>>> >> icc or a different config all together. Currently the ?make install T=? 
>>> >> gives a warning message at the end of the build plus creates the 
>>> >> x86_64-native-linuxapp-XXX directory. If I use the suggested ?make 
>>> >> config T=? command this command create a directory ?build? with a 
>>> >> .config file. The problem is this method does not allow me to have 
>>> >> multiple builds at the same time.
>>> >> 
>>> >> What is the suggested method to have multiple builds without installing  
>>> >> into the local file system?
>>> >
>>> >The multiple build is not supported anymore. It was only building with
>>> >the default configuration.
>>> >If you want to test various builds, I suggest to use this script:
>>> >   scripts/test-build.sh
>>> >   http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c
>>> 
>>> Having a build script is great, but it give me an error on building. The 
>>> script does not have a ?help option and the unknown option is not very 
>>> usefulas it does not explain the two option -jX and -s in that output 
>>> message. I would have expected a bit more help instructions on using this 
>>> command and adding a -h or ?help would be useful. 
>>
>>Please check.
>>There is a -h option.
>
>The -h option gives the same output as the a unknown option:
>
>rkwiles at rkwiles-supermicro (master):~/.../intel/dpdk$ 
>./scripts/test-build.sh -h
>usage: test-build.sh [-jX] [-s] [config1 [config2] ...]]
>rkwiles at rkwiles-supermicro (master):~/.../intel/dpdk$ 
>
>
>My point was more around the content of the help as it is not very useful as 
>to what the -jX or -s options are, please add more help information as ?man 
>test-build.sh? does not work :-)
>
>>
>>> The error I get from the following command is: './scripts/test-build.sh 
>>> x86_64-native-linuxapp-gcc? building on a Ubuntu 15.10 with all patches. If 
>>> I use ?make install T=x86_64-native-linuxapp-gcc? this command builds 
>>> correctly with the warning at the end.
>>[...]
>>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:
>>>  In function \u2018pci_config_extended_tag\u2019:
>>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:505:2:
>>>  error: ignoring return value of \u2018fgets\u2019, declared with attribute 
>>> warn_unused_result [-Werror=unused-result]
>>>   fgets(buf, sizeof(buf), f);
>>>   ^
>>
>>It is a compilation error, not related to the script.
>
>This is strange the ?make install T=? command just works, how do you explain 
>that problem.
>The test-build.sh script should be do some setup then ?make config T= ; make? 
>so why is this script not working?
>
>The script should work as expected with ?./scripts/test-build.sh 
>x86_64-native-linuxapp-gcc? correct?
>
>Could be something wrong with my system, but I doubt it.
>
>>
>>> >If you just want to compile, it is simple:
>>> >   make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
>>> >   make O=my-gcc-build
>>> 
>>> IMO we have gone backwards in making DPDK easy to build. I agree using 
>>> ?make install T=? may not be the best solution as ?install? implies we are 
>>> installing the code. I agree not we should not try to build multiple 
>>> configuration with one command, but we should be able to do ?make build 
>>> T=x86_64-native-linuxapp-gcc? to replace the ?make install T=? command. Now 
>>> the developer only needs to type one command with to build a configuration 
>>> and not two. If the developer includes the ?O=? option then the command 
>>> should create that directory and build the configuration into that 
>>> directory. For the 80% rule the ?O=? option should not be required.
>>
>>The O= option is not required.
>>The new syntax is closer to the standard behaviour.
>>You just don't want to type "make config" because you are using a default
>>configuration.
>
>I understand the O= option is not required. I would have liked it to pick the 
>closest configuration to the host system if x86-64 then pick 
>x86_64-native-linuxapp-gcc GCC is the normal default compiler, if a ARM-v7 
>system then pick the correct configuration or powerpc ?
>If they want something else then let them use the ?T=? option. This would have 
>been a

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Thomas Monjalon]

2015-12-09 17:44, Wiles, Keith:
> On 12/9/15, 11:31 AM, "dev on behalf of Wiles, Keith"  dpdk.org on behalf of keith.wiles at intel.com> wrote:
> 
> >On 12/9/15, 10:19 AM, "Thomas Monjalon"  wrote:
> 
> BTW, I am not overly concerned about the build system per say I just wish I 
> had put my $0.02 worth in before the change. We can leave as it is now.
> 
> The test-build.sh script build does appear to be a real problem. I would like 
> to understand why it does not work.

No your compilation error is a real problem.
The script enables some options which probably trigger the problem.
It is a script to test some compilation options.
Please check before doing some wrong assumptions. You are burning my time.

> Adding a better help message should be an easy fix for someone that wrote the 
> script or I can make the changes, just let me know.

I will improve the help message.

[dpdk-dev] building LIBRTE_PMD_XENVIRT in 32bit triggers some errors

[Martinx - ジェームズ]

On 4 December 2015 at 21:56, Martinx - ?  
wrote:
>
> On 2 December 2015 at 12:05, Christian Ehrhardt
>  wrote:
> > Hi,
> > just FYI - building LIBRTE_PMD_XENVIRT in 32bit triggers some errors.
> >
> > I don't know if that part of the tree is actively maintained - It is
> > default off, in the config template config/common_linuxapp.
> >
> > I'm not even entirely sure if  LIBRTE_PMD_XENVIRT is still required.
> > I guess in the Dom0 you can go with uio-pci-generic these days, not
> > sure about para-virtual guests.
> >
> > Anyway I thought it might be worth to at least report.
> >
> > == Build drivers/net/xenvirt
> > gcc -Wp,-MD,./.rte_eth_xenvirt.o.d.tmp -m32 -pthread -fPIC
> > -march=native -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2
> > -DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3
> > -DRTE_MACHINE_CPUFLAG_SSE4_1 -DRTE_MACHINE_CPUFLAG_SSE4_2
> > -DRTE_MACHINE_CPUFLAG_AES -DRTE_MACHINE_CPUFLAG_PCLMULQDQ
> > -DRTE_MACHINE_CPUFLAG_AVX
> > -DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSE3,RTE_CPUFLAG_SSSE3,RTE_CPUFLAG_SSE4_1,RTE_CPUFLAG_SSE4_2,RTE_CPUFLAG_AES,RTE_CPUFLAG_PCLMULQDQ,RTE_CPUFLAG_AVX
> >  -I/home/ubuntu/dpdk-2.2.0-rc2/build/include -include
> > /home/ubuntu/dpdk-2.2.0-rc2/build/include/rte_config.h -O3 -W -Wall
> > -Werror -Wstrict-prototypes -Wmissing-prototypes
> > -Wmissing-declarations -Wold-style-definition -Wpointer-arith
> > -Wcast-align -Wnested-externs -Wcast-qual -Wformat-nonliteral
> > -Wformat-security -Wundef -Wwrite-strings   -o rte_eth_xenvirt.o -c
> > /home/ubuntu/dpdk-2.2.0-rc2/drivers/net/xenvirt/rte_eth_xenvirt.c
> > In file included from
> > /home/ubuntu/dpdk-2.2.0-rc2/drivers/net/xenvirt/rte_eth_xenvirt.c:61:0:
> > /home/ubuntu/dpdk-2.2.0-rc2/drivers/net/xenvirt/virtqueue.h: In
> > function ?virtqueue_enqueue_recv_refill?:
> > /home/ubuntu/dpdk-2.2.0-rc2/drivers/net/xenvirt/virtqueue.h:201:15:
> > error: cast from pointer to integer of different size
> > [-Werror=pointer-to-int-cast]
> >(uint64_t) ((uint64_t)cookie->buf_addr + RTE_PKTMBUF_HEADROOM -
> > sizeof(struct virtio_net_hdr));
> >^
> > In file included from
> > /home/ubuntu/dpdk-2.2.0-rc2/drivers/net/xenvirt/rte_eth_xenvirt.c:51:0:
> > /home/ubuntu/dpdk-2.2.0-rc2/drivers/net/xenvirt/virtqueue.h: In
> > function ?virtqueue_enqueue_xmit?:
> > /home/ubuntu/dpdk-2.2.0-rc2/build/include/rte_mbuf.h:1617:3: error:
> > cast from pointer to integer of different size
> > [-Werror=pointer-to-int-cast]
> >   ((t)((char *)(m)->buf_addr + (m)->data_off + (o)))
> >^
> > /home/ubuntu/dpdk-2.2.0-rc2/build/include/rte_mbuf.h:1631:32: note: in
> > expansion of macro ?rte_pktmbuf_mtod_offset?
> >  #define rte_pktmbuf_mtod(m, t) rte_pktmbuf_mtod_offset(m, t, 0)
> > ^
> > /home/ubuntu/dpdk-2.2.0-rc2/drivers/net/xenvirt/virtqueue.h:58:2:
> > note: in expansion of macro ?rte_pktmbuf_mtod?
> >   rte_pktmbuf_mtod(mb, uint64_t)
> >   ^
> > /home/ubuntu/dpdk-2.2.0-rc2/drivers/net/xenvirt/virtqueue.h:241:24:
> > note: in expansion of macro ?RTE_MBUF_DATA_DMA_ADDR?
> >   start_dp[idx].addr  = RTE_MBUF_DATA_DMA_ADDR(cookie);
> > ^
> > cc1: all warnings being treated as errors
> > /home/ubuntu/dpdk-2.2.0-rc2/mk/internal/rte.compile-pre.mk:126: recipe
> > for target 'rte_eth_xenvirt.o' failed
> > make[4]: *** [rte_eth_xenvirt.o] Error 1
> > /home/ubuntu/dpdk-2.2.0-rc2/mk/rte.subdir.mk:61: recipe for target
> > 'xenvirt' failed
> > make[3]: *** [xenvirt] Error 2
> > /home/ubuntu/dpdk-2.2.0-rc2/mk/rte.subdir.mk:61: recipe for target 'net' 
> > failed
> > make[2]: *** [net] Error 2
> > /home/ubuntu/dpdk-2.2.0-rc2/mk/rte.sdkbuild.mk:93: recipe for target
> > 'drivers' failed
> > make[1]: *** [drivers] Error 2
> > /home/ubuntu/dpdk-2.2.0-rc2/mk/rte.sdkroot.mk:124: recipe for target
> > 'all' failed
> > make: *** [all] Error 2
> >
> > Christian Ehrhardt
> > Software Engineer, Ubuntu Server
> > Canonical Ltd
>
> Hey guys,
>
>  Is there an easy / fast fix available for this bug?
>
>  DPDK 2.2 with Xen on 32-bit is broken now...
>
>  If not, there will be no way to enable Xen for next Ubuntu LTS, which
> is very sad...
>
>  I have a great Xen project planned for Ubuntu 16.04 + DPDK + Xen with
> DPDK Apps running on PV domUs!
>
> Thanks!
> Thiago

Hey guys,

 Sorry to insist on this subject but, the time for releasing DPDK 2.2
is near and DPDK build with Xen 32-bit is broken.

 If DPDK doesn't fix this, there will be no way to enable XenVirt
support for next Ubuntu LTS 16.04, which is a shame...

 I'm planning to use DPDK on Xen domUs (PVM, HVM, XenServer and on
Amazon EC2) powered exclusively by a supported version of Ubuntu but,
it is broken now...

 So, please, can someone take a look into this?:-P

 Thanks in advance!

Cheers!
Thiago

[dpdk-dev] [PATCH] vfio: support iommu group zero

[Stephen Hemminger]

The current implementation of VFIO will not with the new no-IOMMU mode
in 4.4 kernel. The original code assumed that IOMMU group zero would
never be used. Group numbers are assigned starting at zero, and up
until now the group numbers came from the hardware which is likely
to use group 0 for system devices that are not used with DPDK.

The fix is to allow 0 as a valid group and rearrange code
to split the return value from the group value.

Signed-off-by: Stephen Hemminger 
---
Why was this ignored? It was originally sent on 26 Oct 15 back
when IOMMU discussion was lively.

 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c 
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 0e6c48a..74f91ba 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -499,14 +499,15 @@ pci_vfio_get_group_fd(int iommu_group_no)
 }

 /* parse IOMMU group number for a PCI device
- * returns -1 for errors, 0 for non-existent group */
+ * returns 1 on success, -1 for errors, 0 for non-existent group
+ */
 static int
-pci_vfio_get_group_no(const char *pci_addr)
+pci_vfio_get_group_no(const char *pci_addr, int *iommu_group_no)
 {
char linkname[PATH_MAX];
char filename[PATH_MAX];
char *tok[16], *group_tok, *end;
-   int ret, iommu_group_no;
+   int ret;

memset(linkname, 0, sizeof(linkname));
memset(filename, 0, sizeof(filename));
@@ -533,13 +534,13 @@ pci_vfio_get_group_no(const char *pci_addr)
errno = 0;
group_tok = tok[ret - 1];
end = group_tok;
-   iommu_group_no = strtol(group_tok, &end, 10);
+   *iommu_group_no = strtol(group_tok, &end, 10);
if ((end != group_tok && *end != '\0') || errno != 0) {
RTE_LOG(ERR, EAL, "  %s error parsing IOMMU number!\n", 
pci_addr);
return -1;
}

-   return iommu_group_no;
+   return 1;
 }

 static void
@@ -581,16 +582,15 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
loc->domain, loc->bus, loc->devid, loc->function);

/* get group number */
-   iommu_group_no = pci_vfio_get_group_no(pci_addr);
-
-   /* if 0, group doesn't exist */
-   if (iommu_group_no == 0) {
+   ret = pci_vfio_get_group_no(pci_addr, &iommu_group_no);
+   if (ret == 0) {
RTE_LOG(WARNING, EAL, "  %s not managed by VFIO driver, 
skipping\n",
-   pci_addr);
+   pci_addr);
return 1;
}
+
/* if negative, something failed */
-   else if (iommu_group_no < 0)
+   if (ret < 0)
return -1;

/* get the actual group fd */
-- 
2.1.4

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Thomas Monjalon]

2015-12-09 17:31, Wiles, Keith:
> On 12/9/15, 10:19 AM, "Thomas Monjalon"  wrote:
> >Between "make config" and "make" you can modify the configuration.
> >In the next release, "make config" will be wrapped by a "configure" script
> >which will allow to configure your target in one line.
> >So we will end up with:
> > ./configure
> > make
> > make install
> >It may be weird to you but it is standard to others.
> 
> I understand the above configure steps and yes it is nice to have, the only 
> problem is we do not have a real automake-autolib configuration system.
> 
> Personally I would not use automake-autolib as it requires more system 
> resources and different version cause different problems plus M4 maybe a 
> great language, but not very friendly. The current DPDK build system just 
> requires make and a shell, which is very common plus very simple to install. 
> If cross-compiling it will be harder to get all of the tools in place to 
> support a real automake system on a embedded environment. Cross-compiling has 
> its own problems to address.

I said "make config" will be wrapped by a "configure" script.
Does it sound like using autotools? No

[dpdk-dev] [PATCH 6/6] virtio: arm/arm64: memory mapped IO support in pmd driver

[Stephen Hemminger]

On Thu, 10 Dec 2015 00:29:30 +0530
Santosh Shukla  wrote:

> On Tue, Dec 8, 2015 at 6:23 PM, Santosh Shukla  wrote:
> >
> >
> > On Mon, Dec 7, 2015 at 10:38 PM, Stephen Hemminger
> >  wrote:
> >>
> >> On Fri,  4 Dec 2015 23:05:19 +0530
> >> Santosh Shukla  wrote:
> >>
> >> >
> >> > +#ifdef RTE_EXEC_ENV_LINUXAPP
> >> > +/* start address of first pci_iobar slot (user-space virtual-addres) */
> >> > +void *ioport_map;
> >> > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> > +
> >> > +#include 
> >> > +#define DEV_NAME "/dev/igb_ioport"
> >> > +
> >> > +/* Keeping pci_ioport_size = 4k.
> >> > + * So maximum mmaped pci_iobar supported =
> >> > + * (ioport_size/pci_dev->mem_resource[0].len)
> >> > + *
> >> > + * note: kernel could allow maximum 32 virtio-net-pci interface, that
> >> > mean
> >> > + * maximum 32 PCI_IOBAR(s) where each PCI_IOBAR_LEN=0x20, so
> >> > virtio_map_ioport()
> >> > + * func by theory gonna support 4k/0x20 ==> 128 PCI_IOBAR(s), more than
> >> > + * max-virtio-net-pci interface.
> >> > + */
> >> > +#define PAGE_SIZE4096
> >> > +#define PCI_IOPORT_SIZE  PAGE_SIZE
> >> > +#define PCI_IOPORT_MAX   128 /* 4k / 0x20 */
> >> > +
> >> > +int ioport_map_cnt;
> >> > +#endif /* ARM, ARM64 */
> >> > +#endif /* RTE_EXEC_ENV_LINUXAPP */
> >>
> >> These variables should be static.
> >>
> >
> > (Sorry for delayed follow, Was travelling..)
> > Right,
> >
> >>
> >> Also, it is should be possible to extract the I/O bar stuff in a generic
> >> way through sysfs
> >> and not depend on a character device. The long term goal for DPDK
> >> acceptance is to
> >> eliminate (or at least reduce to a minumum) any requirement for special
> >> kernel drivers.
> >
> >
> > I agree. Existing implementation does read pci_iobar for start address and
> > size, But for non-x86 arch, we need someway to map pci_iobar and thats-why
> > thought of adding device file for a purpose, as archs like arm lack iopl()
> > privileged io syscall support, However iopl() too quite native driver design
> > assumption.
> >
> > I have few idea in my mind such that - Right now I am updating ioport_mapped
> > addr {kernel-virtual-addr-io-memory} to /sys/bus/pci/pci_bus_/xxx/map
> > field, instead of mapping their, I'll try to map to uio's pci interface and
> > then use existing pci_map_resource() api to mmap kernel-virtual-io-address
> > to user-space-virtual-ioaddr. We'll come back on this.
> >
> 
> 
> Spent sometime digging dpdk's uio/pci source code, Intent was to map
> pci ioport region via uio-way. In order to achieve that I tried to
> hack the virtio-net-pci pmd driver. Right now in virtio-net-pci case,
> It creates two sysfs entry for pci bars: resource0 /1.
> 
> Resource0; is ioport region
> Resource1; is iomem region.
> 
> By appending a RTE_PCI_DRV_NEED_MAPPING flag to drv_flag and passing
> hw->io_base = resource1 type pci.mem_resource[slot].addr; where slot
> =1. Resource1 is IORESOURCE_MEM type so uio/pci driver able to mmap.
> That way I could get the valid user-space virtual address. However
> this hack did not worked for me because at qemu side: virtio-pxe.rom
> has virtio_headers located at ioport pci region and guest driver
> writing at iomem region, that's why driver init failed. Note that
> default driver doesn't use resource1 memory.
> 
> This made me think that either I had to add dependent code in kernel
> or something similar proposed in this patch.
> It is because:
> - uio driver and dependent user-space pci api's in dpdk mmaps
> IORESOURCE_MEM types address only {refer igbuio_setup_bars() and in
> particular function pci_parse_sysfs_resource()}.
> - That mmap in userspace backed by arch specific api
> pci_mmap_page_range() in kernel.
> - pci_mmap_page_range() does not support mmaping to IO_RESOURCE_IO type 
> memory.
> - Having said that, we need routine or a way to to map pci_iobar
> region from kernel virtual-address to user-space virtual address.

There a couple of gotcha's with this. It turns out the iomem region
is not mappable on some platforms. I think GCE was one of them.

[dpdk-dev] [PATCH 6/6] virtio: arm/arm64: memory mapped IO support in pmd driver

[Stephen Hemminger]

On Thu, 10 Dec 2015 00:49:08 +0530
Santosh Shukla  wrote:

> On Thu, Dec 10, 2015 at 12:34 AM, Stephen Hemminger
>  wrote:
> > On Thu, 10 Dec 2015 00:29:30 +0530
> > Santosh Shukla  wrote:
> >
> >> On Tue, Dec 8, 2015 at 6:23 PM, Santosh Shukla  
> >> wrote:
> >> >
> >> >
> >> > On Mon, Dec 7, 2015 at 10:38 PM, Stephen Hemminger
> >> >  wrote:
> >> >>
> >> >> On Fri,  4 Dec 2015 23:05:19 +0530
> >> >> Santosh Shukla  wrote:
> >> >>
> >> >> >
> >> >> > +#ifdef RTE_EXEC_ENV_LINUXAPP
> >> >> > +/* start address of first pci_iobar slot (user-space virtual-addres) 
> >> >> > */
> >> >> > +void *ioport_map;
> >> >> > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> >> > +
> >> >> > +#include 
> >> >> > +#define DEV_NAME "/dev/igb_ioport"
> >> >> > +
> >> >> > +/* Keeping pci_ioport_size = 4k.
> >> >> > + * So maximum mmaped pci_iobar supported =
> >> >> > + * (ioport_size/pci_dev->mem_resource[0].len)
> >> >> > + *
> >> >> > + * note: kernel could allow maximum 32 virtio-net-pci interface, that
> >> >> > mean
> >> >> > + * maximum 32 PCI_IOBAR(s) where each PCI_IOBAR_LEN=0x20, so
> >> >> > virtio_map_ioport()
> >> >> > + * func by theory gonna support 4k/0x20 ==> 128 PCI_IOBAR(s), more 
> >> >> > than
> >> >> > + * max-virtio-net-pci interface.
> >> >> > + */
> >> >> > +#define PAGE_SIZE4096
> >> >> > +#define PCI_IOPORT_SIZE  PAGE_SIZE
> >> >> > +#define PCI_IOPORT_MAX   128 /* 4k / 0x20 */
> >> >> > +
> >> >> > +int ioport_map_cnt;
> >> >> > +#endif /* ARM, ARM64 */
> >> >> > +#endif /* RTE_EXEC_ENV_LINUXAPP */
> >> >>
> >> >> These variables should be static.
> >> >>
> >> >
> >> > (Sorry for delayed follow, Was travelling..)
> >> > Right,
> >> >
> >> >>
> >> >> Also, it is should be possible to extract the I/O bar stuff in a generic
> >> >> way through sysfs
> >> >> and not depend on a character device. The long term goal for DPDK
> >> >> acceptance is to
> >> >> eliminate (or at least reduce to a minumum) any requirement for special
> >> >> kernel drivers.
> >> >
> >> >
> >> > I agree. Existing implementation does read pci_iobar for start address 
> >> > and
> >> > size, But for non-x86 arch, we need someway to map pci_iobar and 
> >> > thats-why
> >> > thought of adding device file for a purpose, as archs like arm lack 
> >> > iopl()
> >> > privileged io syscall support, However iopl() too quite native driver 
> >> > design
> >> > assumption.
> >> >
> >> > I have few idea in my mind such that - Right now I am updating 
> >> > ioport_mapped
> >> > addr {kernel-virtual-addr-io-memory} to /sys/bus/pci/pci_bus_/xxx/map
> >> > field, instead of mapping their, I'll try to map to uio's pci interface 
> >> > and
> >> > then use existing pci_map_resource() api to mmap 
> >> > kernel-virtual-io-address
> >> > to user-space-virtual-ioaddr. We'll come back on this.
> >> >
> >>
> >>
> >> Spent sometime digging dpdk's uio/pci source code, Intent was to map
> >> pci ioport region via uio-way. In order to achieve that I tried to
> >> hack the virtio-net-pci pmd driver. Right now in virtio-net-pci case,
> >> It creates two sysfs entry for pci bars: resource0 /1.
> >>
> >> Resource0; is ioport region
> >> Resource1; is iomem region.
> >>
> >> By appending a RTE_PCI_DRV_NEED_MAPPING flag to drv_flag and passing
> >> hw->io_base = resource1 type pci.mem_resource[slot].addr; where slot
> >> =1. Resource1 is IORESOURCE_MEM type so uio/pci driver able to mmap.
> >> That way I could get the valid user-space virtual address. However
> >> this hack did not worked for me because at qemu side: virtio-pxe.rom
> >> has virtio_headers located at ioport pci region and guest driver
> >> writing at iomem region, that's why driver init failed. Note that
> >> default driver doesn't use resource1 memory.
> >>
> >> This made me think that either I had to add dependent code in kernel
> >> or something similar proposed in this patch.
> >> It is because:
> >> - uio driver and dependent user-space pci api's in dpdk mmaps
> >> IORESOURCE_MEM types address only {refer igbuio_setup_bars() and in
> >> particular function pci_parse_sysfs_resource()}.
> >> - That mmap in userspace backed by arch specific api
> >> pci_mmap_page_range() in kernel.
> >> - pci_mmap_page_range() does not support mmaping to IO_RESOURCE_IO type 
> >> memory.
> >> - Having said that, we need routine or a way to to map pci_iobar
> >> region from kernel virtual-address to user-space virtual address.
> >
> > There a couple of gotcha's with this. It turns out the iomem region
> > is not mappable on some platforms. I think GCE was one of them.
> 
> afaik, In linux kernel if arch supports pci_mmap_page_range then iomem
> region should map, right? I am confused by reading your reply, also I
> am not aware of GCE? which platform is GCE, please suggest.

I think it was Google Compute Environment that reported an memory region
which was huge and not accessible, they have there own vhost.

[dpdk-dev] [PATCH 5/6] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init()

[Jan Viktorin]

On Fri,  4 Dec 2015 23:05:18 +0530
Santosh Shukla  wrote:

> iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
> 
> Signed-off-by: Santosh Shukla 
> ---
Acked-by: Jan Viktorin 

[dpdk-dev] [PATCH] vhost: don't stall if guest is slow

[Thomas Monjalon]

2015-12-08 11:12, Yuanhan Liu:
> On Tue, Dec 08, 2015 at 03:30:43AM +0100, Thomas Monjalon wrote:
> > 2015-12-08 10:23, Yuanhan Liu:
> > > On Mon, Dec 07, 2015 at 04:50:21PM -0800, Stephen Hemminger wrote:
> > > > When guest is booting (or any othertime guest is busy) it is possible
> > > > for the small receive ring (256) to get full. If this happens the
> > > > vhost library should just return normally. It's current behavior
> > > > of logging just creates massive log spew/overflow which could even
> > > > act as a DoS attack against host.
> > > > 
> > > > Reported-by: Nathan Law 
> > > > Signed-off-by: Stephen Hemminger 
> > > 
> > > Acked-by: Yuanhan Liu 
> > 
> > Yuanhan, please what is your opinion about the balance benefit/risk
> > of this patch for 2.2?
> 
> Thomas,
> 
> I agree with Stephen that such log is not necessary as it's a fair
> normal case. However, I see no too much benefit/risk for 2.2: it
> just removes a debug log after all.

Applied, thanks

[dpdk-dev] building LIBRTE_PMD_XENVIRT in 32bit triggers some errors

[Thomas Monjalon]

2015-12-09 15:54, Martinx - ?:
>  Sorry to insist on this subject but, the time for releasing DPDK 2.2
> is near and DPDK build with Xen 32-bit is broken.
> 
>  If DPDK doesn't fix this, there will be no way to enable XenVirt
> support for next Ubuntu LTS 16.04, which is a shame...
> 
>  I'm planning to use DPDK on Xen domUs (PVM, HVM, XenServer and on
> Amazon EC2) powered exclusively by a supported version of Ubuntu but,
> it is broken now...
> 
>  So, please, can someone take a look into this?:-P
> 
>  Thanks in advance!

Sorry, this area has no maintainer:
http://dpdk.org/browse/dpdk/tree/MAINTAINERS#n169

In such case, it may be logic to remove the dead code.
If someone wants to make it alive, he's welcome!

[dpdk-dev] [PATCH] mk: fix install with minimal shell

[Thomas Monjalon]

2015-12-09 09:03, Thomas Monjalon:
> Some shells like dash do not support the syntax {}:
>   {mk,scripts}: No such file or directory
> 
> Reported-by: Thiago Martins 
> Reported-by: Piotr Bartosiewicz 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] virtio: fix wrong queue index for VIRTIO_PCI_QUEUE_SEL

[Thomas Monjalon]

2015-12-08 11:05, Yuanhan Liu:
> We should provide VIRTIO_PCI_QUEUE_SEL with vq->vq_queue_idx,
> but not vq->queue_id.
> 
> vq->queue_id is the queue id from rte_eth_rx/tx_queue_setup(),
> which always starts from 0 no matter which queue it is. However,
> for virtio, even number is for RX queue, and odd number is for
> TX queue.
> 
> Fixes: 5382b188fb8a ("virtio: add queue release")
> 
> Cc: Bernard Iremonger 

Bernard was not CC'ed.

> Signed-off-by: Yuanhan Liu 

Applied, thanks

[dpdk-dev] [PATCH] librte_hash: Fix compile errors on IBM POWER

[Thomas Monjalon]

2015-12-09 10:10, Jerin Jacob:
> On Wed, Dec 09, 2015 at 12:11:47PM +0800, Chao Zhu wrote:
> > This patch fixes the compile errors caused by lacking of "size_t" 
> > definition in rte_hash.h. The
> > compile error exists on IBM POWER and ARM (see jerin.jacob at 
> > caviumnetworks.com's message).
> 
> remove relative references from git log,
> 
> - compile error exists on IBM POWER and ARM (see jerin.jacob at 
> caviumnetworks.com's message).
> + compile error exists on IBM POWER and ARM64 GCC 5.2
> 
> > 
> > The errors are like:
> > In file included from /tmp/dpdk/app/test/test_hash_scaling.c:35:0:
> > /tmp/dpdk/build/include/rte_hash.h:70:70: error: unknown type name ?size_t?
> >  typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, 
> > size_t key_len);
> >   ^
> > /tmp/dpdk/build/include/rte_hash.h:120:48: error: unknown type name 
> > ?rte_hash_cmp_eq_t?
> >  void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func);
> 
> add fixes:
> 
> Fixes: 95da2f8e9c61 ("hash: customize compare function")
> 
> with above changes,
> 
> Acked-by: Jerin Jacob 

Applied, thanks

[dpdk-dev] [PATCH] bnx2x: check sc->state to prevent double init

[Thomas Monjalon]

2015-12-08 09:48, Chas Williams:
> If the link is up, then the driver cannot be stopped and started
> successfully.  Instead of checking the link status, use the driver's
> state.
> 
> Signed-off-by: Chas Williams <3chas3 at gmail.com>

Applied, thanks

[dpdk-dev] [PATCH 2/3] vmxnet3: don't clear vf_table on restart

[Yong Wang]

On 12/3/15, 5:05 PM, "Stephen Hemminger"  wrote:



>From: "Charles (Chas) Williams" 
>
>From: Charles (Chas) Williams 
>
>During an MTU change, the adapter is restarted. If hardware VLAN offload
>is in use, this existing filter table would also be cleared. Instead,
>setup the shadow table once during device initialization and just update
>during restart.
>
>Signed-off-by: Charles (Chas) Williams 
>Signed-off-by: Stephen Hemminger 
>---

Acked-by: Yong Wang 

> drivers/net/vmxnet3/vmxnet3_ethdev.c | 23 ---
> 1 file changed, 8 insertions(+), 15 deletions(-)
>
>diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
>b/drivers/net/vmxnet3/vmxnet3_ethdev.c
>index c363bf6..2d7bf13 100644
>--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
>+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
>@@ -89,8 +89,8 @@ static void vmxnet3_dev_info_get(struct rte_eth_dev *dev,
> static int vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev,
>  uint16_t vid, int on);
> static void vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
>-static void vmxnet3_dev_vlan_offload_set_clear(struct rte_eth_dev *dev,
>-  int mask, int clear);
>+static void vmxnet3_dev_vlan_offload_update(struct rte_eth_dev *dev,
>+  int mask);
> 
> #if PROCESS_SYS_EVENTS == 1
> static void vmxnet3_process_events(struct vmxnet3_hw *);
>@@ -294,6 +294,9 @@ eth_vmxnet3_dev_init(struct rte_eth_dev *eth_dev)
>   /* Put device in Quiesce Mode */
>   VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD, VMXNET3_CMD_QUIESCE_DEV);
> 
>+  /* allow untagged pkts */
>+  VMXNET3_SET_VFTABLE_ENTRY(hw->shadow_vfta, 0);
>+
>   return 0;
> }
> 
>@@ -518,7 +521,7 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
>   if (dev->data->dev_conf.rxmode.hw_vlan_filter)
>   mask |= ETH_VLAN_FILTER_MASK;
> 
>-  vmxnet3_dev_vlan_offload_set_clear(dev, mask, 1);
>+  vmxnet3_dev_vlan_offload_update(dev, mask);
> 
>   PMD_INIT_LOG(DEBUG,
>"Writing MAC Address : %02x:%02x:%02x:%02x:%02x:%02x",
>@@ -835,8 +838,7 @@ vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev, 
>uint16_t vid, int on)
> }
> 
> static void
>-vmxnet3_dev_vlan_offload_set_clear(struct rte_eth_dev *dev,
>- int mask, int clear)
>+vmxnet3_dev_vlan_offload_update(struct rte_eth_dev *dev, int mask)
> {
>   struct vmxnet3_hw *hw = dev->data->dev_private;
>   Vmxnet3_DSDevRead *devRead = &hw->shared->devRead;
>@@ -851,17 +853,8 @@ vmxnet3_dev_vlan_offload_set_clear(struct rte_eth_dev 
>*dev,
>  VMXNET3_CMD_UPDATE_FEATURE);
> 
>   if (mask & ETH_VLAN_FILTER_MASK) {
>-  if (clear) {
>-  memset(hw->shadow_vfta, 0,
>- VMXNET3_VFT_TABLE_SIZE);
>-  /* allow untagged pkts */
>-  VMXNET3_SET_VFTABLE_ENTRY(hw->shadow_vfta, 0);
>-  }
>   memcpy(vf_table, hw->shadow_vfta, VMXNET3_VFT_TABLE_SIZE);
>   } else {
>-  /* allow any pkts -- no filtering */
>-  if (clear)
>-  memset(hw->shadow_vfta, 0xff, VMXNET3_VFT_TABLE_SIZE);
>   memset(vf_table, 0xff, VMXNET3_VFT_TABLE_SIZE);
>   }
> 
>@@ -872,7 +865,7 @@ vmxnet3_dev_vlan_offload_set_clear(struct rte_eth_dev *dev,
> static void
> vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask)
> {
>-  vmxnet3_dev_vlan_offload_set_clear(dev, mask, 0);
>+  vmxnet3_dev_vlan_offload_update(dev, mask);
> }
> 
> #if PROCESS_SYS_EVENTS == 1
>-- 
>2.1.4
>

[dpdk-dev] [PATCH 2/2] ethtool: fix dead code

[Thomas Monjalon]

2015-12-08 16:58, Remy Horton:
> Beat me to it.. :)
> 
> On 08/12/2015 16:51, Stephen Hemminger wrote:
> > Remove dead code, and print better return for other errors.
> >
> > Signed-off-by: Stephen Hemminger 
> 
> Acked-by: Remy Horton 

Series applied, thanks

[dpdk-dev] [PATCH 3/3] vmxnet3: fix vlan_offload_set

[Yong Wang]

On 12/3/15, 5:05 PM, "Stephen Hemminger"  wrote:


>From: Nachiketa Prachanda 
>
>vmxnet3_dev_vlan_offload_set(dev, mask) was incorrectly treating the
>mask parameter as the bitmask for vlan_strip and vlan_filter, whereas
>the mask indicates only what has changed - the values for
>vlan_stripping and vlan_filter needs to be taken from dev_conf.rxmode.
>
>Signed-off-by: Nachiketa Prachanda 
>Signed-off-by: Stephen Hemminger 
>---
> drivers/net/vmxnet3/vmxnet3_ethdev.c | 45 ++--
> 1 file changed, 28 insertions(+), 17 deletions(-)
>
>diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
>b/drivers/net/vmxnet3/vmxnet3_ethdev.c
>index 2d7bf13..40c4537 100644
>--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
>+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
>@@ -90,7 +90,7 @@ static int vmxnet3_dev_vlan_filter_set(struct rte_eth_dev 
>*dev,
>  uint16_t vid, int on);
> static void vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
> static void vmxnet3_dev_vlan_offload_update(struct rte_eth_dev *dev,
>-  int mask);
>+  int mask, int changed);
> 
> #if PROCESS_SYS_EVENTS == 1
> static void vmxnet3_process_events(struct vmxnet3_hw *);
>@@ -521,7 +521,7 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
>   if (dev->data->dev_conf.rxmode.hw_vlan_filter)
>   mask |= ETH_VLAN_FILTER_MASK;
> 
>-  vmxnet3_dev_vlan_offload_update(dev, mask);
>+  vmxnet3_dev_vlan_offload_update(dev, mask, mask);
> 
>   PMD_INIT_LOG(DEBUG,
>"Writing MAC Address : %02x:%02x:%02x:%02x:%02x:%02x",
>@@ -838,34 +838,45 @@ vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev, 
>uint16_t vid, int on)
> }
> 
> static void
>-vmxnet3_dev_vlan_offload_update(struct rte_eth_dev *dev, int mask)
>+vmxnet3_dev_vlan_offload_update(struct rte_eth_dev *dev, int mask, int 
>changed)
> {
>   struct vmxnet3_hw *hw = dev->data->dev_private;
>   Vmxnet3_DSDevRead *devRead = &hw->shared->devRead;
>   uint32_t *vf_table = devRead->rxFilterConf.vfTable;
> 
>-  if (mask & ETH_VLAN_STRIP_MASK)
>-  devRead->misc.uptFeatures |= UPT1_F_RXVLAN;
>-  else
>-  devRead->misc.uptFeatures &= ~UPT1_F_RXVLAN;
>-
>-  VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD,
>- VMXNET3_CMD_UPDATE_FEATURE);
>+  if (changed & ETH_VLAN_STRIP_MASK) {
>+  if (mask & ETH_VLAN_STRIP_MASK)
>+  devRead->misc.uptFeatures |= UPT1_F_RXVLAN;
>+  else
>+  devRead->misc.uptFeatures &= ~UPT1_F_RXVLAN;
> 
>-  if (mask & ETH_VLAN_FILTER_MASK) {
>-  memcpy(vf_table, hw->shadow_vfta, VMXNET3_VFT_TABLE_SIZE);
>-  } else {
>-  memset(vf_table, 0xff, VMXNET3_VFT_TABLE_SIZE);
>+  VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD,
>+ VMXNET3_CMD_UPDATE_FEATURE);
>   }
> 
>-  VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD,
>- VMXNET3_CMD_UPDATE_VLAN_FILTERS);
>+  if (changed & ETH_VLAN_FILTER_MASK) {
>+  if (mask & ETH_VLAN_FILTER_MASK)
>+  memcpy(vf_table, hw->shadow_vfta, 
>VMXNET3_VFT_TABLE_SIZE);
>+  else
>+  memset(vf_table, 0xff, VMXNET3_VFT_TABLE_SIZE);
>+
>+  VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD,
>+ VMXNET3_CMD_UPDATE_VLAN_FILTERS);
>+  }
> }
> 
> static void
> vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask)
> {
>-  vmxnet3_dev_vlan_offload_update(dev, mask);
>+  int hw_mask = 0;
>+
>+  if (dev->data->dev_conf.rxmode.hw_vlan_strip)
>+  hw_mask |= ETH_VLAN_STRIP_MASK;
>+
>+  if (dev->data->dev_conf.rxmode.hw_vlan_filter)
>+  hw_mask |= ETH_VLAN_FILTER_MASK;
>+
>+  vmxnet3_dev_vlan_offload_update(dev, hw_mask, mask);

I don?t see a need to have a separate function for _update. You can singly 
merge its implementation with vmxnet3_dev_vlan_offload_set, which seems to be 
clearer and easier to follow IMO.

> }
> 
> #if PROCESS_SYS_EVENTS == 1
>-- 
>2.1.4
>

[dpdk-dev] [PATCH] examples/ip_pipeline: Fix compile issue with strict-aliasing

[Thomas Monjalon]

> > Compile ip_pipeline in CentOS 6.5 with kernel 2.6.32-431 GCC 4.4.7, will 
> > lead
> > below error:
> > 
> > pipeline_routing_be.c: In function
> > ?pipeline_routing_msg_req_arp_add_handler?:
> > pipeline_routing_be.c:1817: error: dereferencing pointer ?({anonymous})?
> > does break strict-aliasing rules
> > 
> > This because the code break strict-aliasing rule.
> > The patch solve this issue.
> > 
> > Fixes: 0ae7275810f1 (examples/ip_pipeline: add more functions to routing
> > pipeline)
> > 
> > Signed-off-by: Michael Qiu 
> 
> Acked-by: Jasvinder Singh 

Applied, thanks

[dpdk-dev] [PATCH v2 1/1] example/ip_pipeline: fix memcpy issue

[Thomas Monjalon]

> > The source and destination both are the arrays of cmdline_parse_ctx_t.
> > So the goal is to copy elements size of cmdline_parse_ctx_t not
> > cmdline_parse_ctx_t*.
> > 
> > Coverity issue: 120412
> > Fixes: b4aee0fb9c6d ("examples/ip_pipeline: reconfigure thread binding
> > dynamically")
> > 
> > Fixes: ea0908c4ab89 ("examples/ip_pipeline: add master pipeline")
> > Fixes: eb32fe7c5574 ("examples/ip_pipeline: rework initialization
> > parameters")
> > 
> > Signed-off-by: Piotr Azarewicz 
> 
> Acked-by: John McNamara 

Applied (and merged with Stephen's patch), thanks

[dpdk-dev] [PATCH] ip_pipeline: fix build errors on different linux kernels

[Thomas Monjalon]

2015-12-09 11:12, Jasvinder Singh:
> This patch fixes build errors on linux kernels such as
> SuSE 11-SP2/3(64 bits), etc.
> 
> Error Log:
>   error: implicit declaration of function 'WIFEXITED'
>   error: implicit declaration of function 'WEXITSTATUS'
> 
> Fixes: ed0b2d020159 ("examples/ip_pipeline: add more ports")
> 
> Signed-off-by: Jasvinder Singh 
> Acked-by: Cristian Dumitrescu 

Applied, thanks