[dpdk-dev] [PATCH 10/16] vhost: export vid as the only interface to applications

[Thomas Monjalon]

2016-05-10 10:29, Yuanhan Liu:
> On Tue, May 10, 2016 at 10:13:18AM -0700, Rich Lane wrote:
> > ps. Could you push git branches somewhere for these larger vhost patch 
> > series?
> > That would make it a lot easier to test than getting patches individually 
> > from
> > patchwork.
> 
> Yes, indeeded. And I have a tree on dpdk.org, but that is mainly for
> holding patches for the mainline. I'm thinking I may could add a new
> branch there, say staging, just for testing. Thomas, will it work for
> you? Or, should I push it to github?

You are free to create the branches you like on dpdk.org.

[dpdk-dev] [PATCH 2/2 RFC] scripts: high light bad patterns

[Yuanhan Liu]

I got a report like following:

Wrong headline lowercase:
xxx: move vhost device ctx to cuse

It takes a bit while (by checking the code) that it's "ctx" triggers
the warning. It could be spotted very quickly if "tx" is high lighted.
This patch adds such support.

Signed-off-by: Yuanhan Liu 
---
 scripts/check-git-log.sh | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
index b7ea1be..153f378 100755
--- a/scripts/check-git-log.sh
+++ b/scripts/check-git-log.sh
@@ -55,7 +55,7 @@ tags=$(git log --format='%b' $range | grep -i -e 'by *:' -e 
'fix.*:')
 fixes=$(git log --format='%h %s' $range | grep -i ': *fix' | cut -d' ' -f1)

 # check headline format (spacing, no punctuation, no code)
-bad=$(echo "$headlines" | grep \
+bad=$(echo "$headlines" | grep --color=always \
-e '' \
-e '^ ' \
-e ' $' \
@@ -69,7 +69,7 @@ bad=$(echo "$headlines" | grep \
 [ -z "$bad" ] || printf "Wrong headline format:\n$bad\n"

 # check headline label for common typos
-bad=$(echo "$headlines" | grep \
+bad=$(echo "$headlines" | grep --color=always \
-e '^example[:/]' \
-e '^apps/' \
-e '^testpmd' \
@@ -79,14 +79,14 @@ bad=$(echo "$headlines" | grep \
 [ -z "$bad" ] || printf "Wrong headline label:\n$bad\n"

 # check headline lowercase for first words
-bad=$(echo "$headlines" | grep \
+bad=$(echo "$headlines" | grep --color=always \
-e '^.*[A-Z].*:' \
-e ': *[A-Z]' \
| sed 's,^,\t,')
 [ -z "$bad" ] || printf "Wrong headline uppercase:\n$bad\n"

 # check headline uppercase (Rx/Tx, VF, L2, MAC, Linux, ARM...)
-bad=$(echo "$headlines" | grep -E \
+bad=$(echo "$headlines" | grep -E --color=always \
-e '\<(rx|tx|RX|TX)\>' \
-e '\<[pv]f\>' \
-e '\' \
-- 
1.9.0

[dpdk-dev] [PATCH 1/2] scripts: fix false positive warning

[Yuanhan Liu]

It reports an false positive warning when the commit subject includes
the word "ctx", as it matches following regexp:

 -e 'rx\|tx\|RX\|TX'

Fixes: edbeb7d962e9 ("scripts: check commit formatting")

Signed-off-by: Yuanhan Liu 
---
 scripts/check-git-log.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
index ce6c15e..b7ea1be 100755
--- a/scripts/check-git-log.sh
+++ b/scripts/check-git-log.sh
@@ -86,8 +86,8 @@ bad=$(echo "$headlines" | grep \
 [ -z "$bad" ] || printf "Wrong headline uppercase:\n$bad\n"

 # check headline uppercase (Rx/Tx, VF, L2, MAC, Linux, ARM...)
-bad=$(echo "$headlines" | grep \
-   -e 'rx\|tx\|RX\|TX' \
+bad=$(echo "$headlines" | grep -E \
+   -e '\<(rx|tx|RX|TX)\>' \
-e '\<[pv]f\>' \
-e '\' \
-e ':.*\' \
-- 
1.9.0

[dpdk-dev] [PATCH 0/2] check-git-log fix and enhancement

[Yuanhan Liu]

Patch 1 fix a false positive warning; patch 2 helps to spot bad content
clearly.

---
Yuanhan Liu (2):
  scripts: fix false positive warning
  scripts: high light bad patterns

 scripts/check-git-log.sh | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
1.9.0

[dpdk-dev] [PATCH v2 11/11] app/test: do not dump PCI devices in blacklist test

[Jan Viktorin]

Dumping of devices in a unittest is useless. Instead, test whether the test
has been set up well - i.e. there are no devices.

Signed-off-by: Jan Viktorin 
---
 app/test/test_pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 3c6c955..942fa09 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -150,8 +150,8 @@ test_pci_blacklist(void)
 {
struct rte_devargs_list save_devargs_list;

-   printf("Dump all devices\n");
-   rte_eal_pci_dump(stdout);
+   TEST_ASSERT(TAILQ_EMPTY(_driver_list),
+   "pci_driver_list not empty");

rte_eal_pci_register(_driver);
rte_eal_pci_register(_driver2);
-- 
2.8.0

[dpdk-dev] [PATCH v2 10/11] app/test: scan PCI bus using a fake sysfs

[Jan Viktorin]

Scan the PCI bus by providing a fake sysfs with a PCI device. The fake sysfs
is a packed file hierarchy linked into the test.

Signed-off-by: Jan Viktorin 
---
 app/test/Makefile  |   1 +
 app/test/test_pci.c|  58 +++--
 .../bus/pci/devices/:01:00.0/class |   1 +
 .../bus/pci/devices/:01:00.0/config| Bin 0 -> 64 bytes
 .../devices/:01:00.0/consistent_dma_mask_bits  |   1 +
 .../bus/pci/devices/:01:00.0/device|   1 +
 .../bus/pci/devices/:01:00.0/dma_mask_bits |   1 +
 .../bus/pci/devices/:01:00.0/enable|   1 +
 .../bus/pci/devices/:01:00.0/irq   |   1 +
 .../bus/pci/devices/:01:00.0/modalias  |   1 +
 .../bus/pci/devices/:01:00.0/msi_bus   |   1 +
 .../bus/pci/devices/:01:00.0/numa_node |   1 +
 .../bus/pci/devices/:01:00.0/resource  |  13 +
 .../bus/pci/devices/:01:00.0/sriov_numvfs  |   1 +
 .../bus/pci/devices/:01:00.0/sriov_totalvfs|   1 +
 .../bus/pci/devices/:01:00.0/subsystem_device  |   1 +
 .../bus/pci/devices/:01:00.0/subsystem_vendor  |   1 +
 .../bus/pci/devices/:01:00.0/uevent|   6 +++
 .../bus/pci/devices/:01:00.0/vendor|   1 +
 19 files changed, 89 insertions(+), 3 deletions(-)
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/class
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/config
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/consistent_dma_mask_bits
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/device
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/dma_mask_bits
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/enable
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/irq
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/modalias
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/msi_bus
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/numa_node
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/resource
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/sriov_numvfs
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/sriov_totalvfs
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/subsystem_device
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/subsystem_vendor
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/uevent
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/vendor

diff --git a/app/test/Makefile b/app/test/Makefile
index de5fa50..1c6c29e 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -73,6 +73,7 @@ SRCS-y += test_resource.c
 $(eval $(call linked_resource,test_resource_c,resource.c))
 $(eval $(call linked_tar_resource,test_resource_tar,test_resource.c))
 SRCS-y += test_pci.c
+$(eval $(call linked_tar_resource,test_pci_sysfs,test_pci_sysfs))
 SRCS-y += test_prefetch.c
 SRCS-y += test_byteorder.c
 SRCS-y += test_per_lcore.c
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index df12bb2..3c6c955 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -43,6 +43,7 @@
 #include 

 #include "test.h"
+#include "resource.h"

 /* Generic maximum number of drivers to have room to allocate all drivers */
 #define NUM_MAX_DRIVERS 256
@@ -215,37 +216,88 @@ static int test_pci_sysfs(void)
return 0;
 }

-/* real drivers (not used for testing) */
+/* real devices & drivers (not used for testing) */
 struct pci_driver_list real_pci_driver_list =
TAILQ_HEAD_INITIALIZER(real_pci_driver_list);
+struct pci_device_list real_pci_device_list =
+   TAILQ_HEAD_INITIALIZER(real_pci_device_list);
+
+REGISTER_LINKED_RESOURCE(test_pci_sysfs);

 static int
 test_pci_setup(void)
 {
+   struct rte_pci_device *dev;
struct rte_pci_driver *dr;
+   const struct resource *r;
+   int ret;
+
+   r = resource_find("test_pci_sysfs");
+   TEST_ASSERT_NOT_NULL(r, "missing resource test_pci_sysfs");
+
+   ret = resource_untar(r);
+   TEST_ASSERT_SUCCESS(ret, "failed to untar %s", r->name);
+
+   ret = setenv("SYSFS_PCI_DEVICES", "test_pci_sysfs/bus/pci/devices", 1);
+   TEST_ASSERT_SUCCESS(ret, "failed to setenv");

-   /* Unregister original driver list */
+   /* Unregister original devices & drivers lists */
while (!TAILQ_EMPTY(_driver_list)) {
dr = TAILQ_FIRST(_driver_list);
rte_eal_pci_unregister(dr);
TAILQ_INSERT_TAIL(_pci_driver_list, dr, next);
}

+   while (!TAILQ_EMPTY(_device_list)) {
+   dev = TAILQ_FIRST(_device_list);
+   TAILQ_REMOVE(_device_list, 

[dpdk-dev] [PATCH v2 08/11] app/test: convert current pci_test into a single test case

[Jan Viktorin]

The current test_pci is just a single test case that tests the blacklisting
of devices. Rename it to test_pci_blacklist and call it from the test_pci.

Signed-off-by: Jan Viktorin 
---
 app/test/test_pci.c | 85 +
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 9d53ba5..2e2fd70 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -144,51 +144,14 @@ static void free_devargs_list(void)
}
 }

-/* real drivers (not used for testing) */
-struct pci_driver_list real_pci_driver_list =
-   TAILQ_HEAD_INITIALIZER(real_pci_driver_list);
-
 static int
-test_pci_setup(void)
-{
-   struct rte_pci_driver *dr;
-
-   /* Unregister original driver list */
-   while (!TAILQ_EMPTY(_driver_list)) {
-   dr = TAILQ_FIRST(_driver_list);
-   rte_eal_pci_unregister(dr);
-   TAILQ_INSERT_TAIL(_pci_driver_list, dr, next);
-   }
-
-   return 0;
-}
-
-static int
-test_pci_cleanup(void)
-{
-   struct rte_pci_driver *dr;
-
-   /* Restore original driver list */
-   while (!TAILQ_EMPTY(_pci_driver_list)) {
-   dr = TAILQ_FIRST(_pci_driver_list);
-   TAILQ_REMOVE(_pci_driver_list, dr, next);
-   rte_eal_pci_register(dr);
-   }
-
-   return 0;
-}
-
-int
-test_pci(void)
+test_pci_blacklist(void)
 {
struct rte_devargs_list save_devargs_list;

printf("Dump all devices\n");
rte_eal_pci_dump(stdout);

-   if (test_pci_setup())
-   return -1;
-
rte_eal_pci_register(_driver);
rte_eal_pci_register(_driver2);

@@ -224,6 +187,52 @@ test_pci(void)
rte_eal_pci_unregister(_driver);
rte_eal_pci_unregister(_driver2);

+   return 0;
+}
+
+/* real drivers (not used for testing) */
+struct pci_driver_list real_pci_driver_list =
+   TAILQ_HEAD_INITIALIZER(real_pci_driver_list);
+
+static int
+test_pci_setup(void)
+{
+   struct rte_pci_driver *dr;
+
+   /* Unregister original driver list */
+   while (!TAILQ_EMPTY(_driver_list)) {
+   dr = TAILQ_FIRST(_driver_list);
+   rte_eal_pci_unregister(dr);
+   TAILQ_INSERT_TAIL(_pci_driver_list, dr, next);
+   }
+
+   return 0;
+}
+
+static int
+test_pci_cleanup(void)
+{
+   struct rte_pci_driver *dr;
+
+   /* Restore original driver list */
+   while (!TAILQ_EMPTY(_pci_driver_list)) {
+   dr = TAILQ_FIRST(_pci_driver_list);
+   TAILQ_REMOVE(_pci_driver_list, dr, next);
+   rte_eal_pci_register(dr);
+   }
+
+   return 0;
+}
+
+int
+test_pci(void)
+{
+   if (test_pci_setup())
+   return -1;
+
+   if (test_pci_blacklist())
+   return -1;
+
if (test_pci_cleanup())
return -1;

-- 
2.8.0

[dpdk-dev] [PATCH v2 07/11] app/test: extract test_pci_setup and test_pci_cleanup

[Jan Viktorin]

Signed-off-by: Jan Viktorin 
---
 app/test/test_pci.c | 47 ++-
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index cf82373..9d53ba5 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -148,21 +148,46 @@ static void free_devargs_list(void)
 struct pci_driver_list real_pci_driver_list =
TAILQ_HEAD_INITIALIZER(real_pci_driver_list);

+static int
+test_pci_setup(void)
+{
+   struct rte_pci_driver *dr;
+
+   /* Unregister original driver list */
+   while (!TAILQ_EMPTY(_driver_list)) {
+   dr = TAILQ_FIRST(_driver_list);
+   rte_eal_pci_unregister(dr);
+   TAILQ_INSERT_TAIL(_pci_driver_list, dr, next);
+   }
+
+   return 0;
+}
+
+static int
+test_pci_cleanup(void)
+{
+   struct rte_pci_driver *dr;
+
+   /* Restore original driver list */
+   while (!TAILQ_EMPTY(_pci_driver_list)) {
+   dr = TAILQ_FIRST(_pci_driver_list);
+   TAILQ_REMOVE(_pci_driver_list, dr, next);
+   rte_eal_pci_register(dr);
+   }
+
+   return 0;
+}
+
 int
 test_pci(void)
 {
struct rte_devargs_list save_devargs_list;
-   struct rte_pci_driver *dr = NULL;

printf("Dump all devices\n");
rte_eal_pci_dump(stdout);

-   /* Unregister all previous drivers */
-   while (!TAILQ_EMPTY(_driver_list)) {
-   dr = TAILQ_FIRST(_driver_list);
-   rte_eal_pci_unregister(dr);
-   TAILQ_INSERT_TAIL(_pci_driver_list, dr, next);
-   }
+   if (test_pci_setup())
+   return -1;

rte_eal_pci_register(_driver);
rte_eal_pci_register(_driver2);
@@ -199,12 +224,8 @@ test_pci(void)
rte_eal_pci_unregister(_driver);
rte_eal_pci_unregister(_driver2);

-   /* Restore original driver list */
-   while (!TAILQ_EMPTY(_pci_driver_list)) {
-   dr = TAILQ_FIRST(_pci_driver_list);
-   TAILQ_REMOVE(_pci_driver_list, dr, next);
-   rte_eal_pci_register(dr);
-   }
+   if (test_pci_cleanup())
+   return -1;

return 0;
 }
-- 
2.8.0

[dpdk-dev] [PATCH v2 06/11] app/test: use linked list to store PCI drivers

[Jan Viktorin]

The test unregisters all real drivers before starting into an array. This
inflexiable as we can use a linked list for this purpose.

Signed-off-by: Jan Viktorin 
---
 app/test/test_pci.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 0ed357e..cf82373 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -144,21 +144,24 @@ static void free_devargs_list(void)
}
 }

+/* real drivers (not used for testing) */
+struct pci_driver_list real_pci_driver_list =
+   TAILQ_HEAD_INITIALIZER(real_pci_driver_list);
+
 int
 test_pci(void)
 {
struct rte_devargs_list save_devargs_list;
struct rte_pci_driver *dr = NULL;
-   struct rte_pci_driver *save_pci_driver_list[NUM_MAX_DRIVERS];
-   unsigned i, num_drivers = 0;

printf("Dump all devices\n");
rte_eal_pci_dump(stdout);

/* Unregister all previous drivers */
-   TAILQ_FOREACH(dr, _driver_list, next) {
+   while (!TAILQ_EMPTY(_driver_list)) {
+   dr = TAILQ_FIRST(_driver_list);
rte_eal_pci_unregister(dr);
-   save_pci_driver_list[num_drivers++] = dr;
+   TAILQ_INSERT_TAIL(_pci_driver_list, dr, next);
}

rte_eal_pci_register(_driver);
@@ -197,8 +200,11 @@ test_pci(void)
rte_eal_pci_unregister(_driver2);

/* Restore original driver list */
-   for (i = 0; i < num_drivers; i++)
-   rte_eal_pci_register(save_pci_driver_list[i]);
+   while (!TAILQ_EMPTY(_pci_driver_list)) {
+   dr = TAILQ_FIRST(_pci_driver_list);
+   TAILQ_REMOVE(_pci_driver_list, dr, next);
+   rte_eal_pci_register(dr);
+   }

return 0;
 }
-- 
2.8.0

[dpdk-dev] [PATCH v2 05/11] app/test: support resources archived by tar

[Jan Viktorin]

When a more complex resource (a file hierarchy) is needed, packing every single
file as a single resource would be very ineffective. For that purpose, it is
possible to pack the files into a tar archive, extract it before test from the
resource and finally clean up all the created files.

This patch introduces functions resource_untar and resource_rm_by_tar to
perform those tasks. An example of using those functions is included as a test.

A new dependency is required to build the app/test: libarchive.

Signed-off-by: Jan Viktorin 
---
v2:
* mentioned the libarchive dependency in commit log
* resource_rm_by_tar is prevented to loop infinitely
* introduced Makefile macro linked_tar_resource
---
 app/test/Makefile|   9 +++
 app/test/resource.c  | 195 +++
 app/test/resource.h  |  13 
 app/test/test_resource.c |  29 +++
 4 files changed, 246 insertions(+)

diff --git a/app/test/Makefile b/app/test/Makefile
index cfe68a6..de5fa50 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -51,6 +51,13 @@ $(1).res.o: $(2)
/dev/stdin $$@ < $$<
 endef

+define linked_tar_resource
+$(1).tar: $(2)
+   tar -C $$(dir $$<) -cf $$@ $$(notdir $$<)
+
+$(call linked_resource,$(1),$(1).tar)
+endef
+
 #
 # library name
 #
@@ -64,6 +71,7 @@ SRCS-y += test.c
 SRCS-y += resource.c
 SRCS-y += test_resource.c
 $(eval $(call linked_resource,test_resource_c,resource.c))
+$(eval $(call linked_tar_resource,test_resource_tar,test_resource.c))
 SRCS-y += test_pci.c
 SRCS-y += test_prefetch.c
 SRCS-y += test_byteorder.c
@@ -183,6 +191,7 @@ CFLAGS += $(WERROR_FLAGS)
 CFLAGS += -D_GNU_SOURCE

 LDLIBS += -lm
+LDLIBS += -larchive

 # Disable VTA for memcpy test
 ifeq ($(CC), gcc)
diff --git a/app/test/resource.c b/app/test/resource.c
index acb63c1..668fc52 100644
--- a/app/test/resource.c
+++ b/app/test/resource.c
@@ -33,6 +33,8 @@

 #include 
 #include 
+#include 
+#include 
 #include 
 #include 

@@ -95,6 +97,199 @@ int resource_fwrite_file(const struct resource *r, const 
char *fname)
return ret;
 }

+static int do_copy(struct archive *r, struct archive *w)
+{
+   const void *buf;
+   size_t len;
+   off_t off;
+   int ret;
+
+   while (1) {
+   ret = archive_read_data_block(r, , , );
+   if (ret == ARCHIVE_RETRY)
+   continue;
+
+   if (ret == ARCHIVE_EOF)
+   return 0;
+
+   if (ret != ARCHIVE_OK)
+   return ret;
+
+   do {
+   ret = archive_write_data_block(w, buf, len, off);
+   if (ret != ARCHIVE_OK && ret != ARCHIVE_RETRY)
+   return ret;
+   } while (ret != ARCHIVE_OK);
+   }
+}
+
+int resource_untar(const struct resource *res)
+{
+   struct archive *r;
+   struct archive *w;
+   struct archive_entry *e;
+   void *p;
+   int flags = 0;
+   int ret;
+
+   p = malloc(resource_size(res));
+   if (p == NULL)
+   rte_panic("Failed to malloc %zu B\n", resource_size(res));
+
+   memcpy(p, res->begin, resource_size(res));
+
+   r = archive_read_new();
+   if (r == NULL) {
+   free(p);
+   return -1;
+   }
+
+   archive_read_support_format_all(r);
+   archive_read_support_filter_all(r);
+
+   w = archive_write_disk_new();
+   if (w == NULL) {
+   archive_read_free(r);
+   free(p);
+   return -1;
+   }
+
+   flags |= ARCHIVE_EXTRACT_PERM;
+   flags |= ARCHIVE_EXTRACT_FFLAGS;
+   archive_write_disk_set_options(w, flags);
+   archive_write_disk_set_standard_lookup(w);
+
+   ret = archive_read_open_memory(r, p, resource_size(res));
+   if (ret != ARCHIVE_OK)
+   goto fail;
+
+   while (1) {
+   ret = archive_read_next_header(r, );
+   if (ret == ARCHIVE_EOF)
+   break;
+   if (ret != ARCHIVE_OK)
+   goto fail;
+
+   ret = archive_write_header(w, e);
+   if (ret == ARCHIVE_EOF)
+   break;
+   if (ret != ARCHIVE_OK)
+   goto fail;
+
+   if (archive_entry_size(e) == 0)
+   continue;
+
+   ret = do_copy(r, w);
+   if (ret != ARCHIVE_OK)
+   goto fail;
+
+   ret = archive_write_finish_entry(w);
+   if (ret != ARCHIVE_OK)
+   goto fail;
+   }
+
+   archive_write_free(w);
+   archive_read_free(r);
+   free(p);
+   return 0;
+
+fail:
+   archive_write_free(w);
+   archive_read_free(r);
+   free(p);
+   rte_panic("Failed: %s\n", archive_error_string(r));
+   return -1;
+}
+
+int resource_rm_by_tar(const struct resource *res)
+{
+   struct archive *r;
+  

[dpdk-dev] [PATCH v2 04/11] app/test: add functions to create files from resources

[Jan Viktorin]

A resource can be written into the target filesystem by calling resource_fwrite
or resource_fwrite_file. Such file can be created before a test is started and
removed after the test finishes.

Signed-off-by: Jan Viktorin 
---
 app/test/resource.c  | 35 +++
 app/test/resource.h  | 14 ++
 app/test/test_resource.c | 10 ++
 3 files changed, 59 insertions(+)

diff --git a/app/test/resource.c b/app/test/resource.c
index 30513db..acb63c1 100644
--- a/app/test/resource.c
+++ b/app/test/resource.c
@@ -31,6 +31,7 @@
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */

+#include 
 #include 
 #include 
 #include 
@@ -60,6 +61,40 @@ const struct resource *resource_find(const char *name)
return NULL;
 }

+int resource_fwrite(const struct resource *r, FILE *f)
+{
+   const size_t goal = resource_size(r);
+   size_t total = 0;
+
+   while (total < goal) {
+   size_t wlen = fwrite(r->begin + total, 1, goal - total, f);
+   if (wlen == 0) {
+   perror(__func__);
+   return -1;
+   }
+
+   total += wlen;
+   }
+
+   return 0;
+}
+
+int resource_fwrite_file(const struct resource *r, const char *fname)
+{
+   FILE *f;
+   int ret;
+
+   f = fopen(fname, "w");
+   if (f == NULL) {
+   perror(__func__);
+   return -1;
+   }
+
+   ret = resource_fwrite(r, f);
+   fclose(f);
+   return ret;
+}
+
 void resource_register(struct resource *r)
 {
TAILQ_INSERT_TAIL(_list, r, next);
diff --git a/app/test/resource.h b/app/test/resource.h
index c44aae9..3253d86 100644
--- a/app/test/resource.h
+++ b/app/test/resource.h
@@ -45,6 +45,7 @@
  */

 #include 
+#include 
 #include 

 #include 
@@ -75,6 +76,19 @@ size_t resource_size(const struct resource *r);
 const struct resource *resource_find(const char *name);

 /**
+ * Write the raw data of the resource to the given file.
+ * @return 0 on success
+ */
+int resource_fwrite(const struct resource *r, FILE *f);
+
+/**
+ * Write the raw data of the resource to the given file given by name.
+ * The name is relative to the current working directory.
+ * @return 0 on success
+ */
+int resource_fwrite_file(const struct resource *r, const char *fname);
+
+/**
  * Register a resource in the global list of resources.
  * Not intended for direct use, please check the REGISTER_RESOURCE
  * macro.
diff --git a/app/test/test_resource.c b/app/test/test_resource.c
index b397fa8..3d1bf00 100644
--- a/app/test/test_resource.c
+++ b/app/test/test_resource.c
@@ -65,6 +65,7 @@ REGISTER_LINKED_RESOURCE(test_resource_c);
 static int test_resource_c(void)
 {
const struct resource *r;
+   FILE *f;

r = resource_find("test_resource_c");
TEST_ASSERT_NOT_NULL(r, "No test_resource_c found");
@@ -72,6 +73,15 @@ static int test_resource_c(void)
"Found resource %s, expected test_resource_c",
r->name);

+   TEST_ASSERT_SUCCESS(resource_fwrite_file(r, "test_resource.c"),
+   "Failed to to write file %s", r->name);
+
+   f = fopen("test_resource.c", "r");
+   TEST_ASSERT_NOT_NULL(f,
+   "Missing extracted file resource.c");
+   fclose(f);
+   remove("test_resource.c");
+
return 0;
 }

-- 
2.8.0

[dpdk-dev] [PATCH v2 03/11] app/test: support resources externally linked

[Jan Viktorin]

To include resources from other source that the C source code we can take
advantage of the objcopy behaviour, i.e. packing of an arbitrary file as an
object file that is linked to the target program.

A linked object file is always accessible as a pair

extern const char beg_;
extern const char end_;
(extern const char siz_;)

A unit test that packs the resource.c source file is included.

Signed-off-by: Jan Viktorin 
---
v2:
* macro resource renamed to linked_resource and documented
* the linking principle is better explained now
---
 app/test/Makefile| 19 +++
 app/test/resource.h  | 10 ++
 app/test/test_resource.c | 18 ++
 3 files changed, 47 insertions(+)

diff --git a/app/test/Makefile b/app/test/Makefile
index 7fbdd18..cfe68a6 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -33,6 +33,24 @@ include $(RTE_SDK)/mk/rte.vars.mk

 ifeq ($(CONFIG_RTE_APP_TEST),y)

+# Define an externally linked resource. A linked resource is an arbitrary
+# file that is linked into the test binary. The application refers to this
+# resource by name. The linked generates identifiers beg_ and end_
+# for referencing by the C code.
+#
+# Parameters: , 
+define linked_resource
+SRCS-y += $(1).res.o
+$(1).res.o: $(2)
+   $(OBJCOPY) -I binary -B $(RTE_OBJCOPY_ARCH) -O $(RTE_OBJCOPY_TARGET) \
+   --rename-section \
+   .data=.rodata,alloc,load,data,contents,readonly  \
+   --redefine-sym _binary__dev_stdin_start=beg_$(1) \
+   --redefine-sym _binary__dev_stdin_end=end_$(1)   \
+   --redefine-sym _binary__dev_stdin_size=siz_$(1)  \
+   /dev/stdin $$@ < $$<
+endef
+
 #
 # library name
 #
@@ -45,6 +63,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := commands.c
 SRCS-y += test.c
 SRCS-y += resource.c
 SRCS-y += test_resource.c
+$(eval $(call linked_resource,test_resource_c,resource.c))
 SRCS-y += test_pci.c
 SRCS-y += test_prefetch.c
 SRCS-y += test_byteorder.c
diff --git a/app/test/resource.h b/app/test/resource.h
index ae4f547..c44aae9 100644
--- a/app/test/resource.h
+++ b/app/test/resource.h
@@ -82,6 +82,16 @@ const struct resource *resource_find(const char *name);
 void resource_register(struct resource *r);

 /**
+ * Definition of a resource linked externally (by means of the used toolchain).
+ * Only the base name of the resource is expected. The name refers to the
+ * linked pointers beg_ and end_ provided externally.
+ */
+#define REGISTER_LINKED_RESOURCE(n) \
+extern const char beg_ ##n; \
+extern const char end_ ##n; \
+REGISTER_RESOURCE(n, _ ##n, _ ##n); \
+
+/**
  * Definition of a resource described by its name, and pointers begin, end.
  */
 #define REGISTER_RESOURCE(n, b, e) \
diff --git a/app/test/test_resource.c b/app/test/test_resource.c
index 69391ad..b397fa8 100644
--- a/app/test/test_resource.c
+++ b/app/test/test_resource.c
@@ -60,11 +60,29 @@ static int test_resource_dpdk(void)
return 0;
 }

+REGISTER_LINKED_RESOURCE(test_resource_c);
+
+static int test_resource_c(void)
+{
+   const struct resource *r;
+
+   r = resource_find("test_resource_c");
+   TEST_ASSERT_NOT_NULL(r, "No test_resource_c found");
+   TEST_ASSERT(!strcmp(r->name, "test_resource_c"),
+   "Found resource %s, expected test_resource_c",
+   r->name);
+
+   return 0;
+}
+
 static int test_resource(void)
 {
if (test_resource_dpdk())
return -1;

+   if (test_resource_c())
+   return -1;
+
return 0;
 }

-- 
2.8.0

[dpdk-dev] [PATCH v2 02/11] mk: define objcopy-specific target and arch

[Jan Viktorin]

The program objcopy uses non-standard conventions to name the target and arch.
Define the values for supported architectures.

FIXME: tile and ppc_64 are not present.

Signed-off-by: Jan Viktorin 
---
 mk/arch/arm/rte.vars.mk | 5 +
 mk/arch/arm64/rte.vars.mk   | 5 +
 mk/arch/i686/rte.vars.mk| 5 +
 mk/arch/x86_64/rte.vars.mk  | 5 +
 mk/arch/x86_x32/rte.vars.mk | 5 +
 5 files changed, 25 insertions(+)

diff --git a/mk/arch/arm/rte.vars.mk b/mk/arch/arm/rte.vars.mk
index bd85140..2f8cf7c 100644
--- a/mk/arch/arm/rte.vars.mk
+++ b/mk/arch/arm/rte.vars.mk
@@ -37,3 +37,8 @@ CPU_LDFLAGS ?=
 CPU_ASFLAGS ?= -felf

 export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS
+
+RTE_OBJCOPY_TARGET = elf32-littlearm
+RTE_OBJCOPY_ARCH = arm
+
+export RTE_OBJCOPY_TARGET RTE_OBJCOPY_ARCH
diff --git a/mk/arch/arm64/rte.vars.mk b/mk/arch/arm64/rte.vars.mk
index 32e3a5f..c168426 100644
--- a/mk/arch/arm64/rte.vars.mk
+++ b/mk/arch/arm64/rte.vars.mk
@@ -56,3 +56,8 @@ CPU_LDFLAGS ?=
 CPU_ASFLAGS ?= -felf

 export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS
+
+RTE_OBJCOPY_TARGET = elf64-littleaarch64
+RTE_OBJCOPY_ARCH = aarch64
+
+export RTE_OBJCOPY_TARGET RTE_OBJCOPY_ARCH
diff --git a/mk/arch/i686/rte.vars.mk b/mk/arch/i686/rte.vars.mk
index 8ba9a23..6a25312 100644
--- a/mk/arch/i686/rte.vars.mk
+++ b/mk/arch/i686/rte.vars.mk
@@ -57,3 +57,8 @@ CPU_LDFLAGS ?= -melf_i386
 CPU_ASFLAGS ?= -felf

 export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS
+
+RTE_OBJCOPY_TARGET = elf32-i386
+RTE_OBJCOPY_ARCH = i386
+
+export RTE_OBJCOPY_TARGET RTE_OBJCOPY_ARCH
diff --git a/mk/arch/x86_64/rte.vars.mk b/mk/arch/x86_64/rte.vars.mk
index b986f04..83723c8 100644
--- a/mk/arch/x86_64/rte.vars.mk
+++ b/mk/arch/x86_64/rte.vars.mk
@@ -57,3 +57,8 @@ CPU_LDFLAGS ?=
 CPU_ASFLAGS ?= -felf64

 export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS
+
+RTE_OBJCOPY_TARGET = elf64-x86-64
+RTE_OBJCOPY_ARCH = i386:x86-64
+
+export RTE_OBJCOPY_TARGET RTE_OBJCOPY_ARCH
diff --git a/mk/arch/x86_x32/rte.vars.mk b/mk/arch/x86_x32/rte.vars.mk
index 3103dfc..676f316 100644
--- a/mk/arch/x86_x32/rte.vars.mk
+++ b/mk/arch/x86_x32/rte.vars.mk
@@ -61,3 +61,8 @@ ifneq ($(shell echo | $(CC) $(CPU_CFLAGS) -E - 2>/dev/null 
1>/dev/null && echo 0
 endif

 export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS
+
+RTE_OBJCOPY_TARGET = elf32-x86-64
+RTE_OBJCOPY_ARCH = i386:x86-64
+
+export RTE_OBJCOPY_TARGET RTE_OBJCOPY_ARCH
-- 
2.8.0

[dpdk-dev] [PATCH v2 01/11] app/test: introduce resources for tests

[Jan Viktorin]

Certain internal mechanisms of DPDK access different file system structures
(e.g. /sys/bus/pci/devices). It is difficult to test those cases automatically
by a unit test when such path is not hard-coded and there is no simple way how
to distribute fake ones with the current testing environment.

This patch adds a possibility to declare a resource embedded in the test binary
itself. The structure resource cover the generic situation - it provides a name
for lookup and pointers to the embedded data blob. A resource is registered
in a constructor by the macro REGISTER_RESOURCE.

Some initial tests of simple resources is included.

Signed-off-by: Jan Viktorin 
---
v2:
* added comments
* resource_size is not inline anymore
* REGISTER_RESOURCE is a single macro now
* fixed double constructor declaration
* __resource_register renamed to resource_register
* less number of underscores...
---
 app/test/Makefile|  2 +
 app/test/resource.c  | 66 
 app/test/resource.h  | 98 
 app/test/test_resource.c | 75 
 4 files changed, 241 insertions(+)
 create mode 100644 app/test/resource.c
 create mode 100644 app/test/resource.h
 create mode 100644 app/test/test_resource.c

diff --git a/app/test/Makefile b/app/test/Makefile
index a4907d5..7fbdd18 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -43,6 +43,8 @@ APP = test
 #
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := commands.c
 SRCS-y += test.c
+SRCS-y += resource.c
+SRCS-y += test_resource.c
 SRCS-y += test_pci.c
 SRCS-y += test_prefetch.c
 SRCS-y += test_byteorder.c
diff --git a/app/test/resource.c b/app/test/resource.c
new file mode 100644
index 000..30513db
--- /dev/null
+++ b/app/test/resource.c
@@ -0,0 +1,66 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 RehiveTech. 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 RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "resource.h"
+
+struct resource_list resource_list = TAILQ_HEAD_INITIALIZER(resource_list);
+
+size_t resource_size(const struct resource *r)
+{
+   return r->end - r->begin;
+}
+
+const struct resource *resource_find(const char *name)
+{
+   struct resource *r;
+
+   TAILQ_FOREACH(r, _list, next) {
+   RTE_VERIFY(r->name);
+
+   if (!strcmp(r->name, name))
+   return r;
+   }
+
+   return NULL;
+}
+
+void resource_register(struct resource *r)
+{
+   TAILQ_INSERT_TAIL(_list, r, next);
+}
diff --git a/app/test/resource.h b/app/test/resource.h
new file mode 100644
index 000..ae4f547
--- /dev/null
+++ b/app/test/resource.h
@@ -0,0 +1,98 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 RehiveTech. 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 

[dpdk-dev] [PATCH v2 00/11] Include resources in tests

[Jan Viktorin]

Hello,

another round. The code now looks better. Brief introduction:

This patch set introduces a mechanism to include a resource (in general a blob)
into the test binary. This allows to make tests less dependent on the target
testing environment. The first use case is testing of PCI bus scan by changing
the hard-coded path (/sys/bus/pci/devices) to something different and provide
a fake tree of devices with the test.

(CC: B. Richardson (accidently avoided in v1).)
---
v1:
* included 5 patches improving the PCI tests
* fixed using of non-existing RTE_INIT macro

v2:
* Makefile macro resource renamed to linked_resource
* introduced macro linked_tar_resource
* added more comments
* clarified relation between REGISTER_LINKED_RESOURCE and the Makefile
* untar is checked to not loop infinitely
* improved commit messages
* objcopy params extracted to a separated patcha (missing tile and ppc)
* few random bits (usually suggested by T. Monjalon)
* included a note about the new dependency libarchive in the particular commit

Jan Viktorin (11):
  app/test: introduce resources for tests
  mk: define objcopy-specific target and arch
  app/test: support resources externally linked
  app/test: add functions to create files from resources
  app/test: support resources archived by tar
  app/test: use linked list to store PCI drivers
  app/test: extract test_pci_setup and test_pci_cleanup
  app/test: convert current pci_test into a single test case
  eal/pci: replace SYSFS_PCI_DEVICES with pci_get_sysfs_path()
  app/test: scan PCI bus using a fake sysfs
  app/test: do not dump PCI devices in blacklist test

 app/test/Makefile  |  31 +++
 app/test/resource.c| 296 +
 app/test/resource.h| 135 ++
 app/test/test_pci.c| 148 +--
 .../bus/pci/devices/:01:00.0/class |   1 +
 .../bus/pci/devices/:01:00.0/config| Bin 0 -> 64 bytes
 .../devices/:01:00.0/consistent_dma_mask_bits  |   1 +
 .../bus/pci/devices/:01:00.0/device|   1 +
 .../bus/pci/devices/:01:00.0/dma_mask_bits |   1 +
 .../bus/pci/devices/:01:00.0/enable|   1 +
 .../bus/pci/devices/:01:00.0/irq   |   1 +
 .../bus/pci/devices/:01:00.0/modalias  |   1 +
 .../bus/pci/devices/:01:00.0/msi_bus   |   1 +
 .../bus/pci/devices/:01:00.0/numa_node |   1 +
 .../bus/pci/devices/:01:00.0/resource  |  13 +
 .../bus/pci/devices/:01:00.0/sriov_numvfs  |   1 +
 .../bus/pci/devices/:01:00.0/sriov_totalvfs|   1 +
 .../bus/pci/devices/:01:00.0/subsystem_device  |   1 +
 .../bus/pci/devices/:01:00.0/subsystem_vendor  |   1 +
 .../bus/pci/devices/:01:00.0/uevent|   6 +
 .../bus/pci/devices/:01:00.0/vendor|   1 +
 app/test/test_resource.c   | 132 +
 drivers/net/szedata2/rte_eth_szedata2.c|   2 +-
 drivers/net/virtio/virtio_pci.c|   2 +-
 lib/librte_eal/bsdapp/eal/rte_eal_version.map  |   6 +
 lib/librte_eal/common/eal_common_pci.c |  13 +
 lib/librte_eal/common/include/rte_pci.h|   2 +-
 lib/librte_eal/linuxapp/eal/eal_pci.c  |   6 +-
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c  |   7 +-
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   2 +-
 lib/librte_eal/linuxapp/eal/rte_eal_version.map|   6 +
 mk/arch/arm/rte.vars.mk|   5 +
 mk/arch/arm64/rte.vars.mk  |   5 +
 mk/arch/i686/rte.vars.mk   |   5 +
 mk/arch/x86_64/rte.vars.mk |   5 +
 mk/arch/x86_x32/rte.vars.mk|   5 +
 36 files changed, 820 insertions(+), 26 deletions(-)
 create mode 100644 app/test/resource.c
 create mode 100644 app/test/resource.h
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/class
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/config
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/consistent_dma_mask_bits
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/device
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/dma_mask_bits
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/enable
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/irq
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/modalias
 create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/msi_bus
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/numa_node
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/resource
 create mode 100644 
app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/sriov_numvfs
 create mode 

[dpdk-dev] [PATCH] qede: fix icc build error

[Harish Patil]

Hi Ferruh,

>fix errors:
>icc: command line warning #10006: ignoring unknown option
>'-Wno-unused-value'
>icc: command line warning #10006: ignoring unknown option
>'-Wno-format-nonliteral'
>icc: command line warning #10006: ignoring unknown option
>'-Wno-shift-negative-value'
>qede/base/ecore_dev.c(1643): error #188: enumerated type mixed with
>another type
>return 0;
>   ^
>
>Signed-off-by: Ferruh Yigit 
>---
> drivers/net/qede/Makefile | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile
>index 47e01be..d0c1361 100644
>--- a/drivers/net/qede/Makefile
>+++ b/drivers/net/qede/Makefile
>@@ -27,7 +27,6 @@ OS_TYPE := $(shell uname -s)
> # CFLAGS
> #
> CFLAGS_BASE_DRIVER = -Wno-unused-parameter
>-CFLAGS_BASE_DRIVER += -Wno-unused-value
> CFLAGS_BASE_DRIVER += -Wno-sign-compare
> CFLAGS_BASE_DRIVER += -Wno-missing-prototypes
> CFLAGS_BASE_DRIVER += -Wno-cast-qual
>@@ -35,12 +34,16 @@ CFLAGS_BASE_DRIVER += -Wno-unused-function
> CFLAGS_BASE_DRIVER += -Wno-unused-variable
> CFLAGS_BASE_DRIVER += -Wno-strict-aliasing
> CFLAGS_BASE_DRIVER += -Wno-missing-prototypes
>+
>+ifneq ($(CONFIG_RTE_TOOLCHAIN_ICC),y)
>+CFLAGS_BASE_DRIVER += -Wno-unused-value

This change is not for the actual build error but to mask the warning:

icc: command line warning #10006: ignoring unknown option
'-Wno-unused-value?, right?


If so, what about for Wno-format-nonliteral and Wno-shift-negative-value?

> CFLAGS_BASE_DRIVER += -Wno-format-nonliteral
> ifeq ($(OS_TYPE),Linux)
> ifeq ($(shell clang -Wno-shift-negative-value -Werror -E - < /dev/null >
>/dev/null 2>&1; echo $$?),0)
> CFLAGS_BASE_DRIVER += -Wno-shift-negative-value
> endif
> endif
>+endif
> 
> ifneq (,$(filter gcc gcc48,$(CC)))
> CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
>@@ -57,7 +60,7 @@ ifeq ($(shell clang -Wno-pointer-bool-conversion
>-Werror -E - < /dev/null > /dev
> CFLAGS_BASE_DRIVER += -Wno-pointer-bool-conversion
> endif
> else
>-#icc flags
>+CFLAGS_BASE_DRIVER += -wd188 #188: enumerated type mixed with another
>type
> endif
> 
> #
>-- 
>2.5.5
>
>
Looks good. 
I hope its retested against gcc/clang also to make sure the change doesn?t
cause build errors.

Acked-by: Harish Patil 

[dpdk-dev] [PATCH v1] igu_uio: fix IOMMU domain issue

[Zhe Tao]

Problem:
The following  operations will cause the igb_uio based DPDK
operation failed.
--Any device assignment through the kvm_assign_device interface,
this can be the pci-assign method in QEMU
--VFIO group attachment operation(attach to the container)
this can happens in  vfio-pci assignment in QEMU

Root cause:
For the two operation above finally will call the intel_iommu_attach_device
(e.g. for vfio/ vfio_group_set_container->
vfio_iommu_type1_attach_group->intel_iommu_attach_device)
If we use iommu=pt in the grub which means intel iommu driver will create a
static identity domain for all the PCI device,
Which will set the translation type into passthrough for all the context
entry for all the PCI devices,
But once we close QEMU process, e.g. the VFIO framework will invoke the
detach group operation and finally will call the intel_iommu_detach_device
which will clean the context entry.
(now the IOMMU entry for this device is not availablei)

For AMD iommu driver it handle this detach action right which will restore the
pt_domain (the same as static identity domain for intel) to the
corresponding entry.

Solution:
Add a work around in igb_uio driver which map one single page.
Because all the DMA related alloc and map
actions will cause the intel IOMMU driver to reload the SI domain to the context
entry, that's why the kernel driver never meets such problem.


Signed-off-by: Zhe Tao 
---
 lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c 
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..3fa88b0 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -327,6 +327,18 @@ igbuio_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
struct rte_uio_pci_dev *udev;
struct msix_entry msix_entry;
int err;
+   struct page *page;
+   /*
+* work around for Intel IOMMU implemation for SI doamin
+*/
+
+   page = alloc_page(GFP_ATOMIC);
+   if (!page) {
+   dev_err(>dev, "Cannot alloc page\n");
+   } else {
+   dma_map_page(>dev, page, 0, PAGE_SIZE, DMA_FROM_DEVICE);
+   __free_page(page);
+   }

udev = kzalloc(sizeof(struct rte_uio_pci_dev), GFP_KERNEL);
if (!udev)
-- 
2.1.4

[dpdk-dev] [RFC] mbuf: new flag when vlan is stripped

[Olivier Matz]

The behavior of PKT_RX_VLAN_PKT was not very well defined, resulting in
PMDs not advertising the same flags in similar conditions.

Following discussion in http://dpdk.org/ml/archives/dev/2016-April/037837.html,
introduce 2 new flags PKT_RX_VLAN_STRIPPED and PKT_RX_QINQ_STRIPPED
that are better defined:

  PKT_RX_VLAN_STRIPPED: a vlan has been stripped by the hardware and its
  tci is saved in mbuf->vlan_tci. This can only happen if vlan stripping
  is enabled in the RX configuration of the PMD.

For now, the old flag PKT_RX_VLAN_PKT is kept but marked as deprecated.
It should be removed from applications and PMDs in a future revision.

This patch also try to fix the drivers. For PKT_RX_VLAN_PKT:

- e1000, enic, i40e, mlx5, nfp, vmxnet3: done, PKT_RX_VLAN_PKT already
  had the same meaning than PKT_RX_VLAN_STRIPPED, minor update is
  required.
- fm10k: done, PKT_RX_VLAN_PKT already had the same meaning than
  PKT_RX_VLAN_STRIPPED, and vlan stripping is always enabled on fm10k.
- ixgbe: modification done for standard mode (vector does not support
  vlan stripping)
- the other drivers do not support vlan stripping.

For PKT_RX_QINQ_PKT, it was only supported on i40e, and the meaning was
already correct, so we can reuse the same value for PKT_RX_QINQ_STRIPPED.

Signed-off-by: Olivier Matz 
---

Hi,

This is a draft patch that implements what was previously discussed,
except the packet_type, which does not exist for vlan today (and I
think it is not mandatory for now, let's do it in another patch).

After doing this patch, it appeared that ixgbe was the only driver that
had a different behavior for the PKT_RX_VLAN_PKT flag. An alternative
to this patch would be to only change the behavior of the ixgbe driver,
and just document better document the PKT_RX_VLAN_PKT flags in
rte_mbuf.h without adding new flags. I think this is a better option.

Comments are welcome.


This patch is tested on ixgbe and igb (82575):

  # we use scapy to send packets like this:
  # Ether(src="00:01:02:03:04:05", 
dst="00:1B:21:AB:8F:10")/Dot1Q(vlan=0x666)/IP()/UDP()/Raw("x"*32)

  cd dpdk.org/
  make config T=x86_64-native-linuxapp-gcc
  make -j32
  mkdir -p /mnt/huge
  mount -t hugetlbfs nodev /mnt/huge
  echo 256 > 
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
  modprobe uio_pci_generic

  # test-pmd is started with vlan stripping (default)
  ./build/app/testpmd -l 2,4 -- --total-num-mbufs=65536 -i 
--port-topology=chained --enable-rx-cksum --disable-hw-vlan-filter
  # and without:
  ./build/app/testpmd -l 2,4 -- --total-num-mbufs=65536 -i 
--port-topology=chained --enable-rx-cksum --disable-hw-vlan-filter 
--disable-hw-vlan-strip

  # we run test-pmd in rxonly mode, displaying the packet information.
  set fwd rxonly
  set verbose 1
  start


  # ixgbe: the behavior of the flag PKT_RX_VLAN_PKT is kept as before,
  # and the new flag PKT_RX_VLAN_STRIPPED is introduced when vlan stripping
  # is enabled and a vlan is stripped.

  # ixgbe, before patch, with vlan stripping
  src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x0800 - length=74 - 
nb_segs=1 - VLAN tci=0x666 - (outer) L2 type: ETHER - (outer) L3 type: IPV4 - 
(outer) L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 
type: Unknown - Inner L4 type: Unknown
  PKT_RX_VLAN_PKT

  # ixgbe, before patch, without vlan stripping
  src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x8100 - length=78 - 
nb_segs=1 - VLAN tci=0x0 - (outer) L2 type: ETHER - (outer) L3 type: IPV4 - 
(outer) L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 
type: Unknown - Inner L4 type: Unknown
  PKT_RX_VLAN_PKT

  # ixgbe, after patch, with vlan stripping
  src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x0800 - length=74 - 
nb_segs=1 - VLAN tci=0x666 - (outer) L2 type: ETHER - (outer) L3 type: IPV4 - 
(outer) L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 
type: Unknown - Inner L4 type: Unknown
 - Receive queue=0x0
  PKT_RX_VLAN_PKT
  PKT_RX_VLAN_STRIPPED

  # ixgbe, after patch, without vlan stripping
  src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x8100 - length=78 - 
nb_segs=1 - (outer) L2 type: ETHER - (outer) L3 type: IPV4 - (outer) L4 type: 
UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - 
Inner L4 type: Unknown
 - Receive queue=0x0
  PKT_RX_VLAN_PKT


  # igb: the new flag PKT_RX_VLAN_STRIPPED is added in addition to 
PKT_RX_VLAN_PKT.

  # igb: before patch, with vlan stripping
  src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x8100 - length=78 - 
nb_segs=1 - (outer) L2 type: ETHER - (outer) L3 type: IPV4 - (outer) L4 type: 
UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - 
Inner L4 type: Unknown
 - Receive queue=0x0

  # igb: before patch, without vlan stripping
  src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x0800 - length=74 - 
nb_segs=1 - VLAN tci=0x666 - (outer) L2 type: ETHER - (outer) L3 type: 

[dpdk-dev] [PATCH] vhost: add support for dynamic vhost PMD creation

[Ferruh Yigit]

On 5/9/2016 10:31 PM, Yuanhan Liu wrote:
> On Thu, May 05, 2016 at 07:11:09PM +0100, Ferruh Yigit wrote:
>> Add rte_eth_from_vhost() API to create vhost PMD dynamically from
>> applications.
> 
> This sounds a good idea to me. It could be better if you name a good
> usage of it though.
> 
>>
>> Signed-off-by: Ferruh Yigit 
>> ---
>>  drivers/net/vhost/rte_eth_vhost.c   | 117 
>> 
>>  drivers/net/vhost/rte_eth_vhost.h   |  19 +
>>  drivers/net/vhost/rte_pmd_vhost_version.map |   7 ++
>>  3 files changed, 143 insertions(+)
>>
>> diff --git a/drivers/net/vhost/rte_eth_vhost.c 
>> b/drivers/net/vhost/rte_eth_vhost.c
>> index 310cbef..c860ab8 100644
>> --- a/drivers/net/vhost/rte_eth_vhost.c
>> +++ b/drivers/net/vhost/rte_eth_vhost.c
>> @@ -796,6 +796,123 @@ error:
>>  return -1;
>>  }
>>  
>> +static int
>> +rte_eth_from_vhost_create(const char *name, char *iface_name,
> 
> It's not a public function, so don't name it with prefix "rte_".
> 
>> +const unsigned int numa_node, struct rte_mempool *mb_pool)
>> +{
>> +struct rte_eth_dev_data *data = NULL;
>> +struct rte_eth_dev *eth_dev = NULL;
>> +struct pmd_internal *internal = NULL;
>> +struct internal_list *list;
>> +int nb_queues = 1;
>> +uint16_t nb_rx_queues = nb_queues;
>> +uint16_t nb_tx_queues = nb_queues;
>> +struct vhost_queue *vq;
>> +int i;
>> +
>> +int port_id = eth_dev_vhost_create(name, iface_name, nb_queues,
>> +numa_node);
>> +
>> +if (port_id < 0)
>> +return -1;
>> +
>> +eth_dev = _eth_devices[port_id];
>> +data = eth_dev->data;
>> +internal = data->dev_private;
>> +list = find_internal_resource(internal->iface_name);
>> +
>> +data->rx_queues = rte_zmalloc_socket(name,
>> +sizeof(void *) * nb_rx_queues, 0, numa_node);
>> +if (data->rx_queues == NULL)
>> +goto error;
>> +
>> +data->tx_queues = rte_zmalloc_socket(name,
>> +sizeof(void *) * nb_tx_queues, 0, numa_node);
>> +if (data->tx_queues == NULL)
>> +goto error;
>> +
>> +for (i = 0; i < nb_rx_queues; i++) {
>> +vq = rte_zmalloc_socket(NULL, sizeof(struct vhost_queue),
>> +RTE_CACHE_LINE_SIZE, numa_node);
>> +if (vq == NULL) {
>> +RTE_LOG(ERR, PMD,
>> +"Failed to allocate memory for rx queue\n");
>> +goto error;
>> +}
>> +vq->mb_pool = mb_pool;
>> +vq->virtqueue_id = i * VIRTIO_QNUM + VIRTIO_TXQ;
>> +data->rx_queues[i] = vq;
>> +}
> 
> I would invoke eth_rx_queue_setup() here, to remove the duplicated
> effort of queue allocation and initiation.
> 
>> +
>> +for (i = 0; i < nb_tx_queues; i++) {
>> +vq = rte_zmalloc_socket(NULL, sizeof(struct vhost_queue),
>> +RTE_CACHE_LINE_SIZE, numa_node);
>> +if (vq == NULL) {
>> +RTE_LOG(ERR, PMD,
>> +"Failed to allocate memory for tx queue\n");
>> +goto error;
>> +}
>> +vq->mb_pool = mb_pool;
> 
> Tx queue doesn't need a mbuf pool. And, ditto, call eth_tx_queue_setup()
> instead.
> 
> 
>> +int
>> +rte_eth_from_vhost(const char *name, char *iface_name,
>> +const unsigned int numa_node, struct rte_mempool *mb_pool)
> 
> That would make this API be very limited. Assume we want to extend
> vhost pmd in future, we could easily do that by adding few more
> vdev options: you could reference my patch[0] to add client and
> reconnect option. But here you hardcode all stuff that are needed
> so far to create a vhost-pmd eth device; adding something new
> would imply an API breakage in future.
> 
> So, let the vdev options as the argument of this API? That could
> be friendly for future extension without breaking the API.
> 
> [0]: http://dpdk.org/dev/patchwork/patch/12608/
> 
>> +/**
>> + * API to create vhost PMD
>> + *
>> + * @param name
>> + *  Vhost device name
>> + * @param iface_name
>> + *  Vhost interface name
>> + * @param numa_node
>> + *  Socket id
>> + * @param mb_pool
>> + *  Memory pool
>> + *
>> + * @return
>> + *  - On success, port_id.
>> + *  - On failure, a negative value.
>> + */
> 
> Hmmm, too simple.
> 
>   --yliu
> 

Hi Yuanhan,

Thank you for the review, I will send new version of the patch with
above issues addressed.

Thanks,
ferruh

[dpdk-dev] [PATCH] vhost: fix buffer not null terminated

[Daniel Mrzyglod]

Fix issue reported by Coverity.
Coverity ID 124556

If the buffer is treated as a null terminated string in later operations,
a buffer overflow or over-read may occur.

In vhost_set_ifname: The string buffer may not have a null terminator if
the source string's length is equal to the buffer size

Fixes: 54292e9520e0 ("vhost: support ifname for vhost-user")

Signed-off-by: Daniel Mrzyglod 
---
 lib/librte_vhost/virtio-net.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index d870ad9..f4695af 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -320,6 +320,7 @@ vhost_set_ifname(struct vhost_device_ctx ctx,
sizeof(dev->ifname) : if_len;

strncpy(dev->ifname, if_name, len);
+   dev->ifname[sizeof(dev->ifname) - 1] = '\0';
 }


-- 
2.5.5

[dpdk-dev] [PATCH] sched: fix useless call

[Ferruh Yigit]

On 5/10/2016 11:11 AM, Daniel Mrzyglod wrote:
> Fix issue reported by Coverity.
> Coverity ID 13338
> 
> A function call that seems to have an intended effect has no actual effect
> on the logic of the program.
> 
> In rte_sched_port_free: A function is called that is only useful for its
> return value, and this value is ignored.
> 
> Fixes: de3cfa2c9823 ("sched: initial import")
> 
> Signed-off-by: Daniel Mrzyglod 
> ---
>  lib/librte_sched/rte_sched.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 1609ea8..9b962a6 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -749,7 +749,6 @@ rte_sched_port_free(struct rte_sched_port *port)
>   rte_pktmbuf_free(mbufs[i]);
>   }
>  
> - rte_bitmap_free(port->bmp);
>   rte_free(port);
>  }
>  
> 

rte_bitmap_free() just does NULL check on port->bmp.

I thought intention can be to free the "bmp", but this isn't the case:
port->bmp is actually port->bmp_array,
port->bmp_array points somewhere within port->memory,
port->memory (zero sized array) allocated and freed with "port" pointer.

So for this patch:
Acked-by: "Ferruh Yigit "


But as follow up:
rte_bitmap_free() seems only used here, and it does nothing more than
NULL check, with a misleading name, should we remove this function?


Regards,
ferruh

[dpdk-dev] [PATCH v2] examples/vm_power_manager: buffer not null terminated

[Daniel Mrzyglod]

CID30691:
If the buffer is treated as a null terminated string in later operations,
a buffer overflow or over-read may occur.

In add_vm: The string buffer may not have a null terminator if the source
string's length is equal to the buffer size

Fixes: e8ae9b662506 ("examples/vm_power: channel manager and monitor in host")

Signed-off-by: Daniel Mrzyglod 
---
 examples/vm_power_manager/channel_manager.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/examples/vm_power_manager/channel_manager.c 
b/examples/vm_power_manager/channel_manager.c
index 22c2ddd..e068ae2 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -667,6 +667,7 @@ add_vm(const char *vm_name)
return -1;
}
strncpy(new_domain->name, vm_name, sizeof(new_domain->name));
+   new_domain->name[sizeof(new_domain->name) - 1] = '\0';
new_domain->channel_mask = 0;
new_domain->num_channels = 0;

-- 
2.5.5

[dpdk-dev] [PATCH 00/15] Make VFIO support independent on PCI

[Santosh Shukla]

On Fri, Apr 29, 2016 at 7:14 PM, Jan Viktorin  
wrote:
>
> Hello,
>
> here follows several patchs extracting the general VFIO code out of the
> PCI + VFIO code base. Usually, it's just move and rename of functions.
> The most complicated ones are:
>
> * eal/linux: extract setup logic out of pci_vfio_map_resource
>
>   - separation of some setup code out of the pci_vfio_map_resource
> (which is otherwise quite PCI-speicific)
>   - it is required by the following one
>
> * eal/linux: move global vfio_cfg to eal_vfio.c
>
>   - moving the vfio_cfg global variable out of the eal_pci_vfio together with
> the functions working with this variable
>
> Some patchs make just temporary changes to avoid breakages throughout the
> patch set (dma mapping).
>
> I am not sure, how exactly is the mp_sync code intended to work. Should there
> be just a single socket connection (no matter how many bus-systems we 
> support)?
> I assume it works this way so I've generalized the eal_pci_vfio_mp_sync.
>
> The vfio initialization is moved out of the rte_eal_pci_init into EAL.
>
> The code is now prepared for adding of other infrastructures such as the SoC
> that I've introduced in [1]. I've partially done this in my workspace.
>

I haven't started reading patch set, we'll do so. But by referring to
your initiative [1] which is non-pci SoC infra, How about binding
those non-pci soc via vfio-platform-way? As because vfio-for-platform
device use-case is such non-pci accelerators in SoC. is your current
refactoring effort aligned towards vfio-platform direction?

[dpdk-dev] [PATCH v3] examples/qos_meter: fix unchecked return value

[Dumitrescu, Cristian]

> -Original Message-
> From: Mrozowicz, SlawomirX
> Sent: Monday, May 9, 2016 9:38 AM
> To: Dumitrescu, Cristian 
> Cc: dev at dpdk.org; Singh, Jasvinder ;
> Mrozowicz, SlawomirX 
> Subject: [PATCH v3] examples/qos_meter: fix unchecked return value
> 
> Fix issue reported by Coverity.
> 
> Coverity ID 30693: Unchecked return value
> check_return: Calling rte_meter_srtcm_config without checking return
> value.
> 
> Fixes: e6541fdec8b2 ("meter: initial import")
> 
> Signed-off-by: Slawomir Mrozowicz 
> ---
>  examples/qos_meter/main.c | 15 ++-
>  examples/qos_meter/main.h |  2 +-
>  2 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/examples/qos_meter/main.c b/examples/qos_meter/main.c
> index b968b00..7c69606 100644
> --- a/examples/qos_meter/main.c
> +++ b/examples/qos_meter/main.c
> @@ -133,14 +133,17 @@ struct rte_meter_trtcm_params
> app_trtcm_params[] = {
> 
>  FLOW_METER app_flows[APP_FLOWS_MAX];
> 
> -static void
> +static int
>  app_configure_flow_table(void)
>  {
>   uint32_t i, j;
> + int ret = 0;
> 
> - for (i = 0, j = 0; i < APP_FLOWS_MAX; i ++, j = (j + 1) %
> RTE_DIM(PARAMS)){
> - FUNC_CONFIG(_flows[i], [j]);
> - }
> + for (i = 0, j = 0; i < APP_FLOWS_MAX && ret == 0;
> + i ++, j = (j + 1) % RTE_DIM(PARAMS))
> + ret = FUNC_CONFIG(_flows[i], [j]);
> +
> + return ret;
>  }

This is only returns the configuration status for the last flow and leaves 
undetected an error for any other flow. Why not check the status for each flow 
and return an error on first occurrence?
For (...){ret = FUNC_CONFIG(...); if (ret) return ret;}

> 
>  static inline void
> @@ -381,7 +384,9 @@ main(int argc, char **argv)
>   rte_eth_promiscuous_enable(port_tx);
> 
>   /* App configuration */
> - app_configure_flow_table();
> + ret = app_configure_flow_table();
> + if (ret < 0)
> + rte_exit(EXIT_FAILURE, "Invalid configure flow table\n");
> 
>   /* Launch per-lcore init on every lcore */
>   rte_eal_mp_remote_launch(main_loop, NULL, CALL_MASTER);
> diff --git a/examples/qos_meter/main.h b/examples/qos_meter/main.h
> index 530bf69..54867dc 100644
> --- a/examples/qos_meter/main.h
> +++ b/examples/qos_meter/main.h
> @@ -51,7 +51,7 @@ enum policer_action
> policer_table[e_RTE_METER_COLORS][e_RTE_METER_COLORS] =
>  #if APP_MODE == APP_MODE_FWD
> 
>  #define FUNC_METER(a,b,c,d) color, flow_id=flow_id, pkt_len=pkt_len,
> time=time
> -#define FUNC_CONFIG(a,b)
> +#define FUNC_CONFIG(a, b) 0
>  #define PARAMS   app_srtcm_params
>  #define FLOW_METER int
> 
> --
> 1.9.1

[dpdk-dev] [PATCHv2 2/2] mk: Introduce NXP dpaa2 architecture based on armv8-a

[Hemant Agrawal]

This patch introduces dpaa2 machine target to address difference
in cpu parameter, number of core to 8 and no numa support
w.r.t default armv8-a machine

Signed-off-by: Hemant Agrawal 
---
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 42 ++
 mk/machine/dpaa2/rte.vars.mk  | 60 +++
 2 files changed, 102 insertions(+)
 create mode 100644 config/defconfig_arm64-dpaa2-linuxapp-gcc
 create mode 100644 mk/machine/dpaa2/rte.vars.mk

diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
new file mode 100644
index 000..66df54c
--- /dev/null
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -0,0 +1,42 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Freescale Semiconductor, Inc. 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 Freescale Semiconductor nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+
+#include "defconfig_arm64-armv8a-linuxapp-gcc"
+
+# NXP (Freescale) - Soc Architecture with WRIOP and QBMAN support
+CONFIG_RTE_MACHINE="dpaa2"
+CONFIG_RTE_ARCH_ARM_TUNE="cortex-a57+fp+simd"
+
+#
+# Compile Environment Abstraction Layer
+#
+CONFIG_RTE_MAX_LCORE=8
+CONFIG_RTE_MAX_NUMA_NODES=1
diff --git a/mk/machine/dpaa2/rte.vars.mk b/mk/machine/dpaa2/rte.vars.mk
new file mode 100644
index 000..8541633
--- /dev/null
+++ b/mk/machine/dpaa2/rte.vars.mk
@@ -0,0 +1,60 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Freescale Semiconductor, Inc. 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 Freescale Semiconductor nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#
+# machine:
+#
+#   - can define ARCH variable (overridden by cmdline value)
+#   - can define CROSS variable (overridden by cmdline value)
+#   - define MACHINE_CFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_LDFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_ASFLAGS variable (overridden by cmdline value)
+#   - can define CPU_CFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in 

[dpdk-dev] [PATCHv2 1/2] mk:disabling CONFIG_RTE_EAL_IGB_UIO for armv8a

[Hemant Agrawal]

The compilation with upstream kernel is broken with this config as enabled.

Signed-off-by: Hemant Agrawal 
---
 config/defconfig_arm64-armv8a-linuxapp-gcc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 9abeca4..a786562 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -42,6 +42,8 @@ CONFIG_RTE_FORCE_INTRINSICS=y
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y

+CONFIG_RTE_EAL_IGB_UIO=n
+
 CONFIG_RTE_IXGBE_INC_VECTOR=n
 CONFIG_RTE_LIBRTE_IVSHMEM=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n
-- 
1.9.1

[dpdk-dev] [PATCH v3] examples/qos_sched: fix bad bit shift operation

[Dumitrescu, Cristian]

> -Original Message-
> From: Mrozowicz, SlawomirX
> Sent: Tuesday, May 10, 2016 1:21 PM
> To: Dumitrescu, Cristian 
> Cc: dev at dpdk.org; Singh, Jasvinder ;
> Mrozowicz, SlawomirX 
> Subject: [PATCH v3] examples/qos_sched: fix bad bit shift operation
> 
> Fix issue reported by Coverity.
> 
> Coverity ID 30690: Bad bit shift operation
> large_shift: In expression 1ULL << i, left shifting by more than 63 bits
> has undefined behavior. The shift amount, i, is as much as 127.
> 
> Fixes: de3cfa2c9823 ("sched: initial import")
> 
> Signed-off-by: Slawomir Mrozowicz 
> ---
>  examples/qos_sched/args.c | 4 ++--
>  examples/qos_sched/main.h | 3 ++-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
> index 3e7fd08..354372d 100644
> --- a/examples/qos_sched/args.c
> +++ b/examples/qos_sched/args.c
> @@ -123,7 +123,7 @@ app_eal_core_mask(void)
>   uint64_t cm = 0;
>   struct rte_config *cfg = rte_eal_get_configuration();
> 
> - for (i = 0; i < RTE_MAX_LCORE; i++) {
> + for (i = 0; i < APP_MAX_LCORE; i++) {
>   if (cfg->lcore_role[i] == ROLE_RTE)
>   cm |= (1ULL << i);
>   }
> @@ -142,7 +142,7 @@ app_cpu_core_count(void)
>   char path[PATH_MAX];
>   uint32_t ncores = 0;
> 
> - for(i = 0; i < RTE_MAX_LCORE; i++) {
> + for (i = 0; i < APP_MAX_LCORE; i++) {
>   len = snprintf(path, sizeof(path), SYS_CPU_DIR, i);
>   if (len <= 0 || (unsigned)len >= sizeof(path))
>   continue;
> diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
> index 82aa0fa..e0517d1 100644
> --- a/examples/qos_sched/main.h
> +++ b/examples/qos_sched/main.h
> @@ -68,7 +68,8 @@ extern "C" {
> 
>  #define BURST_TX_DRAIN_US 100
> 
> -#define MAX_DATA_STREAMS (RTE_MAX_LCORE/2)
> +#define APP_MAX_LCORE 64

Please allow this parameter to be configured from Makefile:

#ifndef APP_MAX_LCORE
#define APP_MAX_LCORE 64
#endif

> +#define MAX_DATA_STREAMS (APP_MAX_LCORE/2)
>  #define MAX_SCHED_SUBPORTS   8
>  #define MAX_SCHED_PIPES  4096
> 
> --
> 1.9.1

Yep, looks good. Thanks, Slawomir!

Regards,
Cristian

[dpdk-dev] [PATCH] sched: fix useless call

[Dumitrescu, Cristian]

> -Original Message-
> From: Mrzyglod, DanielX T
> Sent: Tuesday, May 10, 2016 11:11 AM
> To: Dumitrescu, Cristian 
> Cc: dev at dpdk.org; Mrzyglod, DanielX T 
> Subject: [PATCH] sched: fix useless call
> 
> Fix issue reported by Coverity.
> Coverity ID 13338
> 
> A function call that seems to have an intended effect has no actual effect
> on the logic of the program.
> 
> In rte_sched_port_free: A function is called that is only useful for its
> return value, and this value is ignored.
> 
> Fixes: de3cfa2c9823 ("sched: initial import")
> 
> Signed-off-by: Daniel Mrzyglod 
> ---
>  lib/librte_sched/rte_sched.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 1609ea8..9b962a6 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -749,7 +749,6 @@ rte_sched_port_free(struct rte_sched_port *port)
>   rte_pktmbuf_free(mbufs[i]);
>   }
> 
> - rte_bitmap_free(port->bmp);
>   rte_free(port);
>  }
> 
> --
> 2.5.5

NAK.

This needs to be flagged out as a false positive to Coverity.

As previously discussed on this email list, the rte_bitmap_free() is an API 
function that works as a placeholder for any resource freeing that needs to be 
done for the bitmap. The API function should not be removed and also the call 
to this function from the rte_sched_port_free() should not be removed either.

Thanks,
Cristian

[dpdk-dev] [PATCH 3/6] vhost: add reconnect ability

[Loftus, Ciara]

> On Tue, May 10, 2016 at 09:00:45AM +, Xie, Huawei wrote:
> > On 5/10/2016 4:42 PM, Michael S. Tsirkin wrote:
> > > On Tue, May 10, 2016 at 08:07:00AM +, Xie, Huawei wrote:
> > >> On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote:
> > >>> On Tue, May 10, 2016 at 07:24:10AM +, Xie, Huawei wrote:
> >  On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
> > > On Mon, May 09, 2016 at 04:47:02PM +, Xie, Huawei wrote:
> > >> On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
> > >>> +static void *
> > >>> +vhost_user_client_reconnect(void *arg)
> > >>> +{
> > >>> +   struct reconnect_info *reconn = arg;
> > >>> +   int ret;
> > >>> +
> > >>> +   RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");
> > >>> +   while (1) {
> > >>> +   ret = connect(reconn->fd, (struct sockaddr
> *)>un,
> > >>> +   sizeof(reconn->un));
> > >>> +   if (ret == 0)
> > >>> +   break;
> > >>> +   sleep(1);
> > >>> +   }
> > >>> +
> > >>> +   vhost_user_add_connection(reconn->fd, reconn->vsocket);
> > >>> +   free(reconn);
> > >>> +
> > >>> +   return NULL;
> > >>> +}
> > >>> +
> > >> We could create hundreds of vhost-user ports in OVS. Wihout
> connections
> > >> with QEMU established, those ports are just inactive. This works
> fine in
> > >> server mode.
> > >> With client modes, do we need to create hundreds of vhost
> threads? This
> > >> would be too interruptible.
> > >> How about we create only one thread and do the reconnections
> for all the
> > >> unconnected socket?
> > > Yes, good point and good suggestion. Will do it in v2.
> >  Hi Michael:
> >  This reminds me another irrelevant issue.
> >  In OVS, currently for each vhost port, we create an unix domain
> socket,
> >  and QEMU vhost proxy connects to this socket, and we use this to
> >  identify the connection. This works fine but is our workaround,
> >  otherwise we have no way to identify the connection.
> >  Do you think if this is an issue?
> > >> Let us say vhost creates one unix domain socket, with path as
> "sockpath",
> > >> and two virtio ports in two VMS both connect to the same socket with
> the
> > >> following command line
> > >> -chardev socket,id=char0,path=sockpath
> > >> How could vhost identify the connection?
> > > getpeername(2)?
> >
> > getpeer name returns host/port? then it isn't useful.
> 
> Maybe but I'm still in the dark. Useful for what?
> 
> > The typical scenario in my mind is:
> > We create a OVS port with the name "port1", and when we receive an
> > virtio connection with ID "port1", we attach this virtio interface to
> > the OVS port "port1".
> 
> If you are going to listen on a socket, you can create ports
> and attach socket fds to it dynamically as long as you get connections.
> What is wrong with that?

Hi Michael,

I haven't reviewed the patchset fully, but to hopefully provide more clarify on 
how OVS uses vHost:

OVS with DPDK needs some way to distinguish vHost connections from one another 
so it can switch traffic to the correct port depending on how the switch is 
programmed.
At the moment this is achieved by:
1. user provides unique port name eg. 'vhost0' (this is normal behaviour in OVS 
- checks are put in place to avoid overlapping port names)
2. DPDK vHost lib creates socket called 'vhost0'
3. VM launched with vhost0 socket // -chardev 
socket,id=char0,path=/path/to/vhost0
4. OVS receives 'new_device' vhost callback, checks the name of the device 
(virtio_dev->ifname == vhost0?), if the name matches the name provided in step 
1, OVS stores the virtio_net *dev pointer
5. OVS uses *dev pointer to send and receive traffic to vhost0 via calls to 
vhost library functions eg. enqueue(*dev) / dequeue(*dev)
6. Repeat for multiple vhost devices

We need to make sure that there is still some way to distinguish devices from 
one another like in step 4. Let me know if you need any further clarification.

Thanks,
Ciara

> 
> 
> >
> > >
> > >
> > >> Workarounds:
> > >> vhost creates two unix domain sockets, with path as "sockpath1" and
> > >> "sockpath2" respectively,
> > >> and the virtio ports in two VMS respectively connect to "sockpath1" and
> > >> "sockpath2".
> > >>
> > >> If we have some name string from QEMU over vhost, as you
> mentioned, we
> > >> could create only one socket with path "sockpath".
> > >> User ensure that the names are unique, just as how they do with
> multiple
> > >> sockets.
> > >>
> > > Seems rather fragile.
> >
> > >From the scenario above, it is enough. That is also how it works today
> > in DPDK OVS implementation with multiple sockets.
> > Any other idea?
> >
> > >
> > >>> I'm sorry, I have trouble understanding what you wrote above.
> > >>> What is the issue you are trying to work around?
> > >>>
> >  Do we have plan to support identification in
> VHOST_USER_MESSAGE? With
> >  the 

[dpdk-dev] rte_malloc

[Sergio Gonzalez Monroy]

Have you tried to run the unit tests? (Run 'app/test' application, then 
'malloc_autotest')

Sergio

On 10/05/2016 16:55, Mahdi Moradmand Badie wrote:
> #!/bin/sh
> ./build/app/Mahdi_test -c 0x55 --master-lcore 0
>
> On 10 May 2016 at 11:31, Sergio Gonzalez Monroy 
>  > wrote:
>
> Forgot to ask,
>
> What's the command line you are using to run the app?
>
> Sergio
>
>
> On 10/05/2016 16:17, Mahdi Moradmand Badie wrote:
>> Thanks Sergio,
>> Yes sure,
>> I attached files, it seems so easy but doesn't work.
>> Thanks,
>>
>> On 10 May 2016 at 04:12, Sergio Gonzalez Monroy
>> > > wrote:
>>
>> Hi,
>>
>> On 09/05/2016 18:32, Mahdi Moradmand Badie wrote:
>>
>> Hello All,
>>
>> I had a problem regarding use the rte_malloc.
>> I want to know if I want to use rte_malloc instead of
>> malloc just mak
>> change like this
>> struct lcore_params *p = malloc
>> 
>> 
>> (sizeof(*p)); ==>
>> struct lcore_params *p = rte_malloc
>> 
>> (NULL,
>> sizeof(*p), 0);
>> is enough ?
>>
>>
>> Yes, malloc(sizeof(*p)) has an equivalent behavior to
>> rte_malloc(NULL, sizeof(*p), 0)
>> in the context of a DPDK application.
>>
>> Because I have problem and Segmentation fault (core
>> dumped) ??
>>
>>
>> Could you provide more details of how to reproduce or could
>> you try to
>> reproduce your problem using a very simple example like
>> examples/helloworld ?
>>
>> Sergio
>>
>> Thanks in advance,
>>
>>
>>
>>
>>
>>
>> -- 
>> M at hdi Mor at dm@nd B at die
>
>
>
>
> -- 
> M at hdi Mor at dm@nd B at die

[dpdk-dev] [PATCH 05/15] i40e/base: fixup Geneve VNI for HW use

[Bruce Richardson]

On Thu, May 05, 2016 at 04:53:34PM +0800, Helin Zhang wrote:
> The hardware doesn't layout the Geneve VNI quite the same
> as the VxLAN VNI, so it needs to adjust it before sending
> through the AQ commands as the workaround.
> 
> Signed-off-by: Helin Zhang 

Please expand out acronyms like VNI in the commit message.

/Bruce

[dpdk-dev] rte_malloc

[Sergio Gonzalez Monroy]

Forgot to ask,

What's the command line you are using to run the app?

Sergio

On 10/05/2016 16:17, Mahdi Moradmand Badie wrote:
> Thanks Sergio,
> Yes sure,
> I attached files, it seems so easy but doesn't work.
> Thanks,
>
> On 10 May 2016 at 04:12, Sergio Gonzalez Monroy 
>  > wrote:
>
> Hi,
>
> On 09/05/2016 18:32, Mahdi Moradmand Badie wrote:
>
> Hello All,
>
> I had a problem regarding use the rte_malloc.
> I want to know if I want to use rte_malloc instead of malloc
> just mak
> change like this
> struct lcore_params *p = malloc
> 
> 
> (sizeof(*p)); ==>
> struct lcore_params *p = rte_malloc
> 
> (NULL,
> sizeof(*p), 0);
> is enough ?
>
>
> Yes, malloc(sizeof(*p)) has an equivalent behavior to
> rte_malloc(NULL, sizeof(*p), 0)
> in the context of a DPDK application.
>
> Because I have problem and Segmentation fault (core dumped) ??
>
>
> Could you provide more details of how to reproduce or could you try to
> reproduce your problem using a very simple example like
> examples/helloworld ?
>
> Sergio
>
> Thanks in advance,
>
>
>
>
>
>
> -- 
> M at hdi Mor at dm@nd B at die

[dpdk-dev] [PATCH] vmxnet3: VLAN tag on end packet, not first

[Bruce Richardson]

On Tue, Apr 12, 2016 at 04:08:04PM -0700, John Guzik wrote:
> Signed-off-by: John Guzik 
> Fixes: 9fd5e98b
> 
> ---
>  drivers/net/vmxnet3/vmxnet3_rxtx.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
Applied to dpdk-next-net/rel_16_07, with corrected fixes line, maintainer ack
from V1, and updated commit message.

Thanks,
/Bruce

[dpdk-dev] [PATCH v3 2/4] ixgbe: implement vector PMD for arm architecture

[Bruce Richardson]

On Fri, May 06, 2016 at 11:55:46AM +0530, Jianbo Liu wrote:
> use ARM NEON intrinsic to implement ixgbe vPMD
> 
> Signed-off-by: Jianbo Liu 
> ---
>  drivers/net/ixgbe/Makefile  |   4 +
>  drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 561 
> 
>  2 files changed, 565 insertions(+)
>  create mode 100644 drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
> 
> diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile
> index 50bf51c..b1c7a60 100644
> --- a/drivers/net/ixgbe/Makefile
> +++ b/drivers/net/ixgbe/Makefile
> @@ -108,7 +108,11 @@ SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_rxtx.c
>  SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_ethdev.c
>  SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_fdir.c
>  SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_pf.c
> +ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
> +SRCS-$(CONFIG_RTE_IXGBE_INC_VECTOR) += ixgbe_rxtx_vec_neon.c
> +else
>  SRCS-$(CONFIG_RTE_IXGBE_INC_VECTOR) += ixgbe_rxtx_vec.c
> +endif
>  
Since you are adding ixgbe_rxtx_vec_neon.c here, it might be worthwhile adding
in an extra patch to rename ixgbe_rxtx_vec.c to ixgbe_rxtx_vec_sse.c for 
consistency.

Regards,
/Bruce

[dpdk-dev] [PATCH 10/15] vfio: extract setup logic out of pci_vfio_map_resource

[Jan Viktorin]

On Tue, 10 May 2016 14:58:26 +0200
Jan Viktorin  wrote:

> On Tue, 10 May 2016 11:53:21 +
> "Burakov, Anatoly"  wrote:
> 
> > Hi Jan,
> > 
> >   
> > >   /*
> > > -  * at this point, we know at least one port on this device is bound to
> > > VFIO,
> > > -  * so we can proceed to try and set this particular port up
> > > -  */
> > > -
> > > - /* check if the group is viable */
> > > - ret = ioctl(vfio_group_fd, VFIO_GROUP_GET_STATUS,
> > > _status);
> > > - if (ret) {
> > > - RTE_LOG(ERR, EAL, "  %s cannot get group status, "
> > > - "error %i (%s)\n", pci_addr, errno,
> > > strerror(errno));
> > > - close(vfio_group_fd);
> > > - clear_current_group();
> > > - return -1;
> > > - } else if (!(group_status.flags & VFIO_GROUP_FLAGS_VIABLE)) {
> > > - RTE_LOG(ERR, EAL, "  %s VFIO group is not viable!\n",
> > > pci_addr);
> > > - close(vfio_group_fd);
> > > - clear_current_group();
> > > - return -1;
> > > - }
> > > -
> > 
> > I think you've lost this bit when moving things around. I can't find any 
> > viability checks in eal_vfio.c  
> 
> Thanks for this catch, I'll check. I've rebased the patch set once
> because there were some changes to the original VFIO code. Hope for no
> more such rebasing.

OK. Confirmed. Fixed for v2.

Jan

> 
> Regards
> Jan
> 
> > 
> > Thanks,
> > Anatoly  
> 
> 
> 



-- 
  Jan ViktorinE-mail: Viktorin at RehiveTech.com
  System ArchitectWeb:www.RehiveTech.com
  RehiveTech
  Brno, Czech Republic

[dpdk-dev] [PATCH 0/3] [RFC] vhost: micro vhost optimization

[Yuanhan Liu]

On Tue, May 10, 2016 at 02:49:43PM -0700, Rich Lane wrote:
> I see a significant performance improvement with these patches, around 5% at 
> 64
> bytes.

Thanks for testing.

> 
> The one patch that didn't give any performance boost for me was "vhost: 
> arrange
> virtio_net fields for better cache sharing".

Yeah, same here from my test. I mean, in theory, it should give us a
tiny boost, it doesn't in real life though. And since it (should) do
no harm, I would still include this patch in this set. Maybe I should
have noted at first that no real perf gain from the 3rd patch.

--yliu

> 
> Tested-by: Rich Lane 
> 
> On Mon, May 2, 2016 at 5:46 PM, Yuanhan Liu 
> wrote:
> 
> Here is a small patch set does the micro optimization, which brings about
> 10% performance boost in my 64B packet testing, with the following topo:
> 
> ? ? pkt generator <> NIC <-> Virtio NIC
> 
> Patch 1 pre updates the used ring and update them in batch. It should be
> feasible from my understanding: there will be no issue, guest driver will
> not start processing them as far as we haven't updated the "used->idx"
> yet. I could miss something though.
> 
> Patch 2 saves one check for small packets (that can be hold in one desc
> buf and mbuf).
> 
> Patch 3 moves several frequently used fields into one cache line, for
> better cache sharing.
> 
> Note that this patch set is based on my latest vhost ABI refactoring
> patchset.
> 
> 
> ---
> Yuanhan Liu (3):
> ? vhost: pre update used ring for Tx and Rx
> ? vhost: optimize dequeue for small packets
> ? vhost: arrange virtio_net fields for better cache sharing
> 
> ?lib/librte_vhost/vhost-net.h? |? ?8 +--
> ?lib/librte_vhost/vhost_rxtx.c | 110
> --
> ?2 files changed, 68 insertions(+), 50 deletions(-)
>
> --
> 1.9.0
> 
> 
> 

[dpdk-dev] [PATCH 10/15] vfio: extract setup logic out of pci_vfio_map_resource

[Jan Viktorin]

On Tue, 10 May 2016 11:53:21 +
"Burakov, Anatoly"  wrote:

> Hi Jan,
> 
> 
> > /*
> > -* at this point, we know at least one port on this device is bound to
> > VFIO,
> > -* so we can proceed to try and set this particular port up
> > -*/
> > -
> > -   /* check if the group is viable */
> > -   ret = ioctl(vfio_group_fd, VFIO_GROUP_GET_STATUS,
> > _status);
> > -   if (ret) {
> > -   RTE_LOG(ERR, EAL, "  %s cannot get group status, "
> > -   "error %i (%s)\n", pci_addr, errno,
> > strerror(errno));
> > -   close(vfio_group_fd);
> > -   clear_current_group();
> > -   return -1;
> > -   } else if (!(group_status.flags & VFIO_GROUP_FLAGS_VIABLE)) {
> > -   RTE_LOG(ERR, EAL, "  %s VFIO group is not viable!\n",
> > pci_addr);
> > -   close(vfio_group_fd);
> > -   clear_current_group();
> > -   return -1;
> > -   }
> > -  
> 
> I think you've lost this bit when moving things around. I can't find any 
> viability checks in eal_vfio.c

Thanks for this catch, I'll check. I've rebased the patch set once
because there were some changes to the original VFIO code. Hope for no
more such rebasing.

Regards
Jan

> 
> Thanks,
> Anatoly



-- 
  Jan ViktorinE-mail: Viktorin at RehiveTech.com
  System ArchitectWeb:www.RehiveTech.com
  RehiveTech
  Brno, Czech Republic

[dpdk-dev] [PATCH 15/15] vfio: change VFIO init to be extendable

[Jan Viktorin]

Hello Anatoly,

On Tue, 10 May 2016 11:50:23 +
"Burakov, Anatoly"  wrote:

> Hi Jan,
> 
> > We can now just OR the vfio_enabled sequentially and so adding new VFIO
> > subsystems (vfio_platform) is possible.
> > 
> > Signed-off-by: Jan Viktorin 
> > ---
> >  lib/librte_eal/linuxapp/eal/eal.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
> > b/lib/librte_eal/linuxapp/eal/eal.c
> > index 92225cf..1549fe5 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal.c
> > @@ -727,12 +727,14 @@ rte_eal_iopl_init(void)  #ifdef VFIO_PRESENT  static
> > int rte_eal_vfio_setup(void)  {
> > -   if (internal_config.no_pci)
> > -   return 0;
> > +   int vfio_enabled = 0;
> > 
> > -   pci_vfio_enable();
> > +   if (!internal_config.no_pci) {
> > +   pci_vfio_enable();
> > +   vfio_enabled |= pci_vfio_is_enabled();
> > +   }  
> 
> Could there be a situation where we need to know if a particular VFIO 
> subsystem is enabled? Do you think it's worth adding (e.g. vfio_enabled |= 
> VFIO_PCI_ENABLED or something)? (I don't imply it is necessary, just asking)

Well... the semantics are quite tricky here.

There are: vfio-pci, vfio-platform and vfio-amba in the Linux Kernel. I
ignore vfio-amba because I don't know any considerable device supported
by this.

With respect to the VFIO, if you have both PCI and SoC infra enabled,
you have to check for both vfio-pci and vfio-platform.

If only PCI is there you have to check only for vfio-pci.
But, if you check for vfio-platform as well and it is not there then
the EAL init would fail without a reason (because you don't need
vfio-platform). Vice-versa for SoC.

This patch improves the check to cover those situations. Later on,
I'll just append something like:

if (!internal_config.no_soc) {
soc_vfio_enable();
vfio_enabled |= soc_vfio_is_enabled();
}

and the EAL init would be happy... I hope ;).

The thing is that we don't know which devices will bind to VFIO and we
don't know which of those devices would use vfio-pci and vfio-platform.
So, if both PCI and SoC are enabled and only vfio-platform is there we
cannot say here "failed because vfio-pci is missing".

Jan

> 
> Thanks,
> Anatoly



-- 
  Jan ViktorinE-mail: Viktorin at RehiveTech.com
  System ArchitectWeb:www.RehiveTech.com
  RehiveTech
  Brno, Czech Republic

[dpdk-dev] [PATCH 0/3] [RFC] vhost: micro vhost optimization

[Rich Lane]

I see a significant performance improvement with these patches, around 5%
at 64 bytes.

The one patch that didn't give any performance boost for me was "vhost:
arrange virtio_net fields for better cache sharing".

Tested-by: Rich Lane 

On Mon, May 2, 2016 at 5:46 PM, Yuanhan Liu 
wrote:

> Here is a small patch set does the micro optimization, which brings about
> 10% performance boost in my 64B packet testing, with the following topo:
>
> pkt generator <> NIC <-> Virtio NIC
>
> Patch 1 pre updates the used ring and update them in batch. It should be
> feasible from my understanding: there will be no issue, guest driver will
> not start processing them as far as we haven't updated the "used->idx"
> yet. I could miss something though.
>
> Patch 2 saves one check for small packets (that can be hold in one desc
> buf and mbuf).
>
> Patch 3 moves several frequently used fields into one cache line, for
> better cache sharing.
>
> Note that this patch set is based on my latest vhost ABI refactoring
> patchset.
>
>
> ---
> Yuanhan Liu (3):
>   vhost: pre update used ring for Tx and Rx
>   vhost: optimize dequeue for small packets
>   vhost: arrange virtio_net fields for better cache sharing
>
>  lib/librte_vhost/vhost-net.h  |   8 +--
>  lib/librte_vhost/vhost_rxtx.c | 110
> --
>  2 files changed, 68 insertions(+), 50 deletions(-)
>
> --
> 1.9.0
>
>

[dpdk-dev] [PATCH 00/15] Make VFIO support independent on PCI

[Jan Viktorin]

Hello Santosh,

On Tue, 10 May 2016 17:48:23 +0530
Santosh Shukla  wrote:

> On Fri, Apr 29, 2016 at 7:14 PM, Jan Viktorin  
> wrote:
> >
> > Hello,
> >
> > here follows several patchs extracting the general VFIO code out of the
> > PCI + VFIO code base. Usually, it's just move and rename of functions.
> > The most complicated ones are:
> >
> > * eal/linux: extract setup logic out of pci_vfio_map_resource
> >
> >   - separation of some setup code out of the pci_vfio_map_resource
> > (which is otherwise quite PCI-speicific)
> >   - it is required by the following one
> >
> > * eal/linux: move global vfio_cfg to eal_vfio.c
> >
> >   - moving the vfio_cfg global variable out of the eal_pci_vfio together 
> > with
> > the functions working with this variable
> >
> > Some patchs make just temporary changes to avoid breakages throughout the
> > patch set (dma mapping).
> >
> > I am not sure, how exactly is the mp_sync code intended to work. Should 
> > there
> > be just a single socket connection (no matter how many bus-systems we 
> > support)?
> > I assume it works this way so I've generalized the eal_pci_vfio_mp_sync.
> >
> > The vfio initialization is moved out of the rte_eal_pci_init into EAL.
> >
> > The code is now prepared for adding of other infrastructures such as the SoC
> > that I've introduced in [1]. I've partially done this in my workspace.

Probably, I should have written here "later, vfio-platform will be
connected to this"...

> >  
> 
> I haven't started reading patch set, we'll do so. But by referring to
> your initiative [1] which is non-pci SoC infra, How about binding
> those non-pci soc via vfio-platform-way? As because vfio-for-platform
> device use-case is such non-pci accelerators in SoC. is your current
> refactoring effort aligned towards vfio-platform direction?

Sure, vfio-platform is the way to go. However, this patch set is just a
refactoring. The goal is to be able to connect with the vfio-platform.
Without this patch set, it leads to lots of duplicated code.

Jan

-- 
  Jan ViktorinE-mail: Viktorin at RehiveTech.com
  System ArchitectWeb:www.RehiveTech.com
  RehiveTech
  Brno, Czech Republic

[dpdk-dev] [PATCH v2] enic: fix 'imissed' to count drops due to no RX buffers

[John Daley]

The enic rx_no_bufs counter is a hardware counter of packets
dropped on the interface due to no host buffers being available.
Use this counter to update the r_stats->imissed counter.  Also,
include the rx_drop enic counter in the r_stats->ierrors count.
Rx_drop plus rx_errors are the total number of packets dropped
on by the enic on the Rx interface for reasons other than no host
buffers.

Fixes: 7182d3e7d177 ("enic: expose Rx missed packets counter")
Signed-off-by: John Daley 
---
v2: improved commit message

 drivers/net/enic/enic_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 60fe765..be4e9e5 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -243,10 +243,10 @@ void enic_dev_stats_get(struct enic *enic, struct 
rte_eth_stats *r_stats)
r_stats->ibytes = stats->rx.rx_bytes_ok;
r_stats->obytes = stats->tx.tx_bytes_ok;

-   r_stats->ierrors = stats->rx.rx_errors;
+   r_stats->ierrors = stats->rx.rx_errors + stats->rx.rx_drop;
r_stats->oerrors = stats->tx.tx_errors;

-   r_stats->imissed = stats->rx.rx_drop;
+   r_stats->imissed = stats->rx.rx_no_bufs;

r_stats->rx_nombuf = stats->rx.rx_no_bufs;
 }
-- 
2.7.0

[dpdk-dev] [PATCH v3] examples/qos_sched: fix bad bit shift operation

[Slawomir Mrozowicz]

Fix issue reported by Coverity.

Coverity ID 30690: Bad bit shift operation
large_shift: In expression 1ULL << i, left shifting by more than 63 bits
has undefined behavior. The shift amount, i, is as much as 127.

Fixes: de3cfa2c9823 ("sched: initial import")

Signed-off-by: Slawomir Mrozowicz 
---
 examples/qos_sched/args.c | 4 ++--
 examples/qos_sched/main.h | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
index 3e7fd08..354372d 100644
--- a/examples/qos_sched/args.c
+++ b/examples/qos_sched/args.c
@@ -123,7 +123,7 @@ app_eal_core_mask(void)
uint64_t cm = 0;
struct rte_config *cfg = rte_eal_get_configuration();

-   for (i = 0; i < RTE_MAX_LCORE; i++) {
+   for (i = 0; i < APP_MAX_LCORE; i++) {
if (cfg->lcore_role[i] == ROLE_RTE)
cm |= (1ULL << i);
}
@@ -142,7 +142,7 @@ app_cpu_core_count(void)
char path[PATH_MAX];
uint32_t ncores = 0;

-   for(i = 0; i < RTE_MAX_LCORE; i++) {
+   for (i = 0; i < APP_MAX_LCORE; i++) {
len = snprintf(path, sizeof(path), SYS_CPU_DIR, i);
if (len <= 0 || (unsigned)len >= sizeof(path))
continue;
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 82aa0fa..e0517d1 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -68,7 +68,8 @@ extern "C" {

 #define BURST_TX_DRAIN_US 100

-#define MAX_DATA_STREAMS (RTE_MAX_LCORE/2)
+#define APP_MAX_LCORE 64
+#define MAX_DATA_STREAMS (APP_MAX_LCORE/2)
 #define MAX_SCHED_SUBPORTS 8
 #define MAX_SCHED_PIPES4096

-- 
1.9.1

[dpdk-dev] [PATCH] arm64: change rte_memcpy to inline function

[Jianbo Liu]

Other APP may call rte_memcpy by function pointer,
so change it to an inline function.

Signed-off-by: Jianbo Liu 
---
 lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h 
b/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
index 917cdc1..3abe7cd 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
@@ -78,7 +78,11 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
memcpy(dst, src, 256);
 }

-#define rte_memcpy(d, s, n)memcpy((d), (s), (n))
+static inline void *
+rte_memcpy(void *dst, const void *src, size_t n)
+{
+   return memcpy(dst, src, n);
+}

 static inline void *
 rte_memcpy_func(void *dst, const void *src, size_t n)
-- 
2.4.11

[dpdk-dev] [PATCH] qede: fix build with gcc >= 6.0

[Panu Matilainen]

With gcc >= 6.0, qede base driver fails to build with:
drivers/net/qede/base/ecore_cxt.c: In function 'ecore_cdu_init_common':
cc1: error: left shift of negative value [-Werror=shift-negative-value]

Since the base drivers are untouchable, work around by disabling
the warning.

Signed-off-by: Panu Matilainen 
---
 drivers/net/qede/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile
index 47e01be..884e173 100644
--- a/drivers/net/qede/Makefile
+++ b/drivers/net/qede/Makefile
@@ -47,6 +47,9 @@ CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
 CFLAGS_BASE_DRIVER += -Wno-missing-declarations
 CFLAGS_BASE_DRIVER += -Wno-maybe-uninitialized
 CFLAGS_BASE_DRIVER += -Wno-strict-prototypes
+ifeq ($(shell test $(GCC_VERSION) -ge 60 && echo 1), 1)
+CFLAGS_BASE_DRIVER += -Wno-shift-negative-value
+endif
 else ifeq ($(CC), clang)
 CFLAGS_BASE_DRIVER += -Wno-format-extra-args
 CFLAGS_BASE_DRIVER += -Wno-visibility
-- 
2.5.5

[dpdk-dev] [PATCH 02/20] thunderx/nicvf: add pmd skeleton

[Jerin Jacob]

On Mon, May 09, 2016 at 10:41:22AM -0700, Stephen Hemminger wrote:
> On Sat, 7 May 2016 20:46:20 +0530
> Jerin Jacob  wrote:
> 
> > +
> > +static inline struct nicvf*
> > +nicvf_pmd_priv(struct rte_eth_dev *eth_dev)
> > +{
> > +   return (struct nicvf *)eth_dev->data->dev_private;
> > +}
> 
> Cast here is unnecessary because dev_private is void *

Agree with all of your review comments in [PATCH 01/20] and [PATCH
02/20]. Will fix it in V2.

[dpdk-dev] [PATCH 0/2] l2fwd improvements

[Pattan, Reshma]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
> Sent: Tuesday, April 19, 2016 10:35 AM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Richardson, Bruce
> ; De Lara Guarch, Pablo
> ; Jerin Jacob
> 
> Subject: [dpdk-dev] [PATCH 0/2] l2fwd improvements
> 
> 
> Jerin Jacob (2):
>   examples/l2fwd: remove number of cycles per second hardcording
>   examples/l2fwd: increase mempool cache size for better performance
> 
>  examples/l2fwd/main.c | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> --
> 2.1.0

Looks ok, small typo in patch 1 subject line "hardcoding"
Acked-by: Reshma Pattan 

[dpdk-dev] [PATCH] app/testpmd: add packet data prefetch in macswap loop

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, May 03, 2016 11:20 AM
> To: Ivan Boule
> Cc: Jerin Jacob; dev at dpdk.org; De Lara Guarch, Pablo
> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: add packet data prefetch in 
> macswap loop
> 
> On Tue, May 03, 2016 at 11:50:31AM +0200, Ivan Boule wrote:
> > On 05/03/2016 11:45 AM, Bruce Richardson wrote:
> > >On Mon, May 02, 2016 at 05:29:37PM +0530, Jerin Jacob wrote:
> > >>prefetch the next packet data address in advance in macswap loop
> > >>for performance improvement.
> > >>
> > >>...
> > >>  for (i = 0; i < nb_rx; i++) {
> > >>+ if (likely(i < nb_rx - 1))
> > >>+ rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[i + 1],
> > >>+void *));
> > >
> > >At least on IA platforms, there is no issue with prefetching beyond the 
> > >end of
> > >the array, since it's only a hint to the cpu. If this is true for other 
> > >platforms,
> > >then I suggest we just drop the conditional and just always prefetch.
> >
> > This is an interesting point.
> > Bruce, are you suggesting that prefetching at an invalid [virtual] address
> > won't trigger a CPU exception?
> >
> 
> Yep. For example, adding "rte_prefetch0(NULL)" at the start of main in testpmd
> causes no ill effects when running the app.
> 

One correction - while on IA prefetch(inval_addr) wouldn't cause any functional 
problems,
it still might cause DTLB miss and can be a source of noticeable performance 
degradation.
So it is better to avoid such constructions for performance critical code.
Konstantin

[dpdk-dev] [PATCH] qede: fix icc build error

[Ferruh Yigit]

fix errors:
icc: command line warning #10006: ignoring unknown option '-Wno-unused-value'
icc: command line warning #10006: ignoring unknown option 
'-Wno-format-nonliteral'
icc: command line warning #10006: ignoring unknown option 
'-Wno-shift-negative-value'
qede/base/ecore_dev.c(1643): error #188: enumerated type mixed with another type
return 0;
   ^

Signed-off-by: Ferruh Yigit 
---
 drivers/net/qede/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/qede/Makefile b/drivers/net/qede/Makefile
index 47e01be..d0c1361 100644
--- a/drivers/net/qede/Makefile
+++ b/drivers/net/qede/Makefile
@@ -27,7 +27,6 @@ OS_TYPE := $(shell uname -s)
 # CFLAGS
 #
 CFLAGS_BASE_DRIVER = -Wno-unused-parameter
-CFLAGS_BASE_DRIVER += -Wno-unused-value
 CFLAGS_BASE_DRIVER += -Wno-sign-compare
 CFLAGS_BASE_DRIVER += -Wno-missing-prototypes
 CFLAGS_BASE_DRIVER += -Wno-cast-qual
@@ -35,12 +34,16 @@ CFLAGS_BASE_DRIVER += -Wno-unused-function
 CFLAGS_BASE_DRIVER += -Wno-unused-variable
 CFLAGS_BASE_DRIVER += -Wno-strict-aliasing
 CFLAGS_BASE_DRIVER += -Wno-missing-prototypes
+
+ifneq ($(CONFIG_RTE_TOOLCHAIN_ICC),y)
+CFLAGS_BASE_DRIVER += -Wno-unused-value
 CFLAGS_BASE_DRIVER += -Wno-format-nonliteral
 ifeq ($(OS_TYPE),Linux)
 ifeq ($(shell clang -Wno-shift-negative-value -Werror -E - < /dev/null > 
/dev/null 2>&1; echo $$?),0)
 CFLAGS_BASE_DRIVER += -Wno-shift-negative-value
 endif
 endif
+endif

 ifneq (,$(filter gcc gcc48,$(CC)))
 CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
@@ -57,7 +60,7 @@ ifeq ($(shell clang -Wno-pointer-bool-conversion -Werror -E - 
< /dev/null > /dev
 CFLAGS_BASE_DRIVER += -Wno-pointer-bool-conversion
 endif
 else
-#icc flags
+CFLAGS_BASE_DRIVER += -wd188 #188: enumerated type mixed with another type
 endif

 #
-- 
2.5.5

[dpdk-dev] [PATCH 3/6] vhost: add reconnect ability

[Michael S. Tsirkin]

On Tue, May 10, 2016 at 09:00:45AM +, Xie, Huawei wrote:
> On 5/10/2016 4:42 PM, Michael S. Tsirkin wrote:
> > On Tue, May 10, 2016 at 08:07:00AM +, Xie, Huawei wrote:
> >> On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote:
> >>> On Tue, May 10, 2016 at 07:24:10AM +, Xie, Huawei wrote:
>  On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
> > On Mon, May 09, 2016 at 04:47:02PM +, Xie, Huawei wrote:
> >> On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
> >>> +static void *
> >>> +vhost_user_client_reconnect(void *arg)
> >>> +{
> >>> + struct reconnect_info *reconn = arg;
> >>> + int ret;
> >>> +
> >>> + RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");
> >>> + while (1) {
> >>> + ret = connect(reconn->fd, (struct sockaddr 
> >>> *)>un,
> >>> + sizeof(reconn->un));
> >>> + if (ret == 0)
> >>> + break;
> >>> + sleep(1);
> >>> + }
> >>> +
> >>> + vhost_user_add_connection(reconn->fd, reconn->vsocket);
> >>> + free(reconn);
> >>> +
> >>> + return NULL;
> >>> +}
> >>> +
> >> We could create hundreds of vhost-user ports in OVS. Wihout connections
> >> with QEMU established, those ports are just inactive. This works fine 
> >> in
> >> server mode.
> >> With client modes, do we need to create hundreds of vhost threads? This
> >> would be too interruptible.
> >> How about we create only one thread and do the reconnections for all 
> >> the
> >> unconnected socket?
> > Yes, good point and good suggestion. Will do it in v2.
>  Hi Michael:
>  This reminds me another irrelevant issue.
>  In OVS, currently for each vhost port, we create an unix domain socket,
>  and QEMU vhost proxy connects to this socket, and we use this to
>  identify the connection. This works fine but is our workaround,
>  otherwise we have no way to identify the connection.
>  Do you think if this is an issue?
> >> Let us say vhost creates one unix domain socket, with path as "sockpath",
> >> and two virtio ports in two VMS both connect to the same socket with the
> >> following command line
> >> -chardev socket,id=char0,path=sockpath
> >> How could vhost identify the connection?
> > getpeername(2)?
> 
> getpeer name returns host/port? then it isn't useful.

Maybe but I'm still in the dark. Useful for what?

> The typical scenario in my mind is:
> We create a OVS port with the name "port1", and when we receive an
> virtio connection with ID "port1", we attach this virtio interface to
> the OVS port "port1".

If you are going to listen on a socket, you can create ports
and attach socket fds to it dynamically as long as you get connections.
What is wrong with that?


> 
> >
> >
> >> Workarounds:
> >> vhost creates two unix domain sockets, with path as "sockpath1" and
> >> "sockpath2" respectively,
> >> and the virtio ports in two VMS respectively connect to "sockpath1" and
> >> "sockpath2".
> >>
> >> If we have some name string from QEMU over vhost, as you mentioned, we
> >> could create only one socket with path "sockpath".
> >> User ensure that the names are unique, just as how they do with multiple
> >> sockets.
> >>
> > Seems rather fragile.
> 
> >From the scenario above, it is enough. That is also how it works today
> in DPDK OVS implementation with multiple sockets.
> Any other idea?
> 
> >
> >>> I'm sorry, I have trouble understanding what you wrote above.
> >>> What is the issue you are trying to work around?
> >>>
>  Do we have plan to support identification in VHOST_USER_MESSAGE? With
>  the identification, if vhost as server, we only need to create one
>  socket which receives multiple connections, and use the ID in the
>  message to identify the connection.
> 
>  /huawei
> >>> Sending e.g. -name string from qemu over vhost might be useful
> >>> for debugging, but I'm not sure it's a good idea to
> >>> rely on it being unique.
> >>>
> > Thanks.
> >
> > --yliu
> >
> 

[dpdk-dev] rte_malloc

[Mahdi Moradmand Badie]

No, I don't have any idea? :)

On 10 May 2016 at 12:12, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at intel.com> wrote:

> Have you tried to run the unit tests? (Run 'app/test' application, then
> 'malloc_autotest')
>
> Sergio
>
>
> On 10/05/2016 16:55, Mahdi Moradmand Badie wrote:
>
> #!/bin/sh
> ./build/app/Mahdi_test -c 0x55 --master-lcore 0
>
> On 10 May 2016 at 11:31, Sergio Gonzalez Monroy <
> sergio.gonzalez.monroy at intel.com> wrote:
>
>> Forgot to ask,
>>
>> What's the command line you are using to run the app?
>>
>> Sergio
>>
>>
>> On 10/05/2016 16:17, Mahdi Moradmand Badie wrote:
>>
>> Thanks Sergio,
>> Yes sure,
>> I attached files, it seems so easy but doesn't work.
>> Thanks,
>>
>> On 10 May 2016 at 04:12, Sergio Gonzalez Monroy <
>> sergio.gonzalez.monroy at intel.com>
>> wrote:
>>
>>> Hi,
>>>
>>> On 09/05/2016 18:32, Mahdi Moradmand Badie wrote:
>>>
 Hello All,

 I had a problem regarding use the rte_malloc.
 I want to know if I want to use rte_malloc instead of malloc just mak
 change like this
 struct lcore_params *p = malloc
 <
 http://dpdk.org/doc/api/rte__malloc_8h.html#afb7316a4ec228ed9b8ffc1864b03d85b
 >
 (sizeof(*p)); ==>
 struct lcore_params *p = rte_malloc
 <
 http://dpdk.org/doc/api/rte__malloc_8h.html#afb7316a4ec228ed9b8ffc1864b03d85b
 >(NULL,
 sizeof(*p), 0);
 is enough ?

>>>
>>> Yes, malloc(sizeof(*p)) has an equivalent behavior to rte_malloc(NULL,
>>> sizeof(*p), 0)
>>> in the context of a DPDK application.
>>>
>>> Because I have problem and Segmentation fault (core dumped) ??

>>>
>>> Could you provide more details of how to reproduce or could you try to
>>> reproduce your problem using a very simple example like
>>> examples/helloworld ?
>>>
>>> Sergio
>>>
>>> Thanks in advance,



>>>
>>
>>
>> --
>> M at hdi Mor at dm@nd B at die
>>
>>
>>
>
>
> --
> M at hdi Mor at dm@nd B at die
>
>
>


-- 
M at hdi Mor at dm@nd B at die

[dpdk-dev] [PATCH] sched: fix useless call

[Daniel Mrzyglod]

Fix issue reported by Coverity.
Coverity ID 13338

A function call that seems to have an intended effect has no actual effect
on the logic of the program.

In rte_sched_port_free: A function is called that is only useful for its
return value, and this value is ignored.

Fixes: de3cfa2c9823 ("sched: initial import")

Signed-off-by: Daniel Mrzyglod 
---
 lib/librte_sched/rte_sched.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 1609ea8..9b962a6 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -749,7 +749,6 @@ rte_sched_port_free(struct rte_sched_port *port)
rte_pktmbuf_free(mbufs[i]);
}

-   rte_bitmap_free(port->bmp);
rte_free(port);
 }

-- 
2.5.5

[dpdk-dev] [PATCHv2 1/2] mk:disabling CONFIG_RTE_EAL_IGB_UIO for armv8a

[Santosh Shukla]

On Tue, May 10, 2016 at 05:25:33PM +0530, Hemant Agrawal wrote:
> The compilation with upstream kernel is broken with this config as enabled.
>
few nits:
- 'mk:..' subject header looks incorrect, you can start with 
  config/armv8a: disable igb_uio

- Also pl. reword the description- perhaps IGB_UIO not supported for arm64
 arch so disable.

if you agress to do then patch looks okay to me, 
Reviewed-by: Santosh Shukla 

> Signed-off-by: Hemant Agrawal 
> ---
>  config/defconfig_arm64-armv8a-linuxapp-gcc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
> b/config/defconfig_arm64-armv8a-linuxapp-gcc
> index 9abeca4..a786562 100644
> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> @@ -42,6 +42,8 @@ CONFIG_RTE_FORCE_INTRINSICS=y
>  CONFIG_RTE_TOOLCHAIN="gcc"
>  CONFIG_RTE_TOOLCHAIN_GCC=y
>  
> +CONFIG_RTE_EAL_IGB_UIO=n
> +
>  CONFIG_RTE_IXGBE_INC_VECTOR=n
>  CONFIG_RTE_LIBRTE_IVSHMEM=n
>  CONFIG_RTE_LIBRTE_FM10K_PMD=n
> -- 
> 1.9.1
> 

[dpdk-dev] [PATCH 11/15] vfio: move global vfio_cfg to eal_vfio.c

[Burakov, Anatoly]

Hi Jan,

> --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
> @@ -39,10 +39,282 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "eal_filesystem.h"
>  #include "eal_vfio.h"

I believe the eal_private.h should be local include (in quotes), like in other 
places.

> +/**
> + * Setup vfio_cfg for the device indentified by its address. It
> +discovers
> + * the configured I/O MMU groups or sets a new one for the device. If a
> +new
> + * groups is assigned, the DMA mapping is performed.
> + * Returns 0 on success, a negative value on failure and a positive
> +value in
> + * case the given device cannot be managed this way.
> + */

I think it would've been good to fix the typo in the comment ("indentified") :)

Thanks,
Anatoly

[dpdk-dev] rte_malloc

[Mahdi Moradmand Badie]

#!/bin/sh
./build/app/Mahdi_test -c 0x55 --master-lcore 0

On 10 May 2016 at 11:31, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at intel.com> wrote:

> Forgot to ask,
>
> What's the command line you are using to run the app?
>
> Sergio
>
>
> On 10/05/2016 16:17, Mahdi Moradmand Badie wrote:
>
> Thanks Sergio,
> Yes sure,
> I attached files, it seems so easy but doesn't work.
> Thanks,
>
> On 10 May 2016 at 04:12, Sergio Gonzalez Monroy <
> sergio.gonzalez.monroy at intel.com> wrote:
>
>> Hi,
>>
>> On 09/05/2016 18:32, Mahdi Moradmand Badie wrote:
>>
>>> Hello All,
>>>
>>> I had a problem regarding use the rte_malloc.
>>> I want to know if I want to use rte_malloc instead of malloc just mak
>>> change like this
>>> struct lcore_params *p = malloc
>>> <
>>> http://dpdk.org/doc/api/rte__malloc_8h.html#afb7316a4ec228ed9b8ffc1864b03d85b
>>> >
>>> (sizeof(*p)); ==>
>>> struct lcore_params *p = rte_malloc
>>> <
>>> http://dpdk.org/doc/api/rte__malloc_8h.html#afb7316a4ec228ed9b8ffc1864b03d85b
>>> >(NULL,
>>> sizeof(*p), 0);
>>> is enough ?
>>>
>>
>> Yes, malloc(sizeof(*p)) has an equivalent behavior to rte_malloc(NULL,
>> sizeof(*p), 0)
>> in the context of a DPDK application.
>>
>> Because I have problem and Segmentation fault (core dumped) ??
>>>
>>
>> Could you provide more details of how to reproduce or could you try to
>> reproduce your problem using a very simple example like
>> examples/helloworld ?
>>
>> Sergio
>>
>> Thanks in advance,
>>>
>>>
>>>
>>
>
>
> --
> M at hdi Mor at dm@nd B at die
>
>
>


-- 
M at hdi Mor at dm@nd B at die

[dpdk-dev] [PATCH 10/15] vfio: extract setup logic out of pci_vfio_map_resource

[Burakov, Anatoly]

Hi Jan,


>   /*
> -  * at this point, we know at least one port on this device is bound to
> VFIO,
> -  * so we can proceed to try and set this particular port up
> -  */
> -
> - /* check if the group is viable */
> - ret = ioctl(vfio_group_fd, VFIO_GROUP_GET_STATUS,
> _status);
> - if (ret) {
> - RTE_LOG(ERR, EAL, "  %s cannot get group status, "
> - "error %i (%s)\n", pci_addr, errno,
> strerror(errno));
> - close(vfio_group_fd);
> - clear_current_group();
> - return -1;
> - } else if (!(group_status.flags & VFIO_GROUP_FLAGS_VIABLE)) {
> - RTE_LOG(ERR, EAL, "  %s VFIO group is not viable!\n",
> pci_addr);
> - close(vfio_group_fd);
> - clear_current_group();
> - return -1;
> - }
> -

I think you've lost this bit when moving things around. I can't find any 
viability checks in eal_vfio.c

Thanks,
Anatoly

[dpdk-dev] [PATCH 15/15] vfio: change VFIO init to be extendable

[Burakov, Anatoly]

Hi Jan,

> We can now just OR the vfio_enabled sequentially and so adding new VFIO
> subsystems (vfio_platform) is possible.
> 
> Signed-off-by: Jan Viktorin 
> ---
>  lib/librte_eal/linuxapp/eal/eal.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
> b/lib/librte_eal/linuxapp/eal/eal.c
> index 92225cf..1549fe5 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -727,12 +727,14 @@ rte_eal_iopl_init(void)  #ifdef VFIO_PRESENT  static
> int rte_eal_vfio_setup(void)  {
> - if (internal_config.no_pci)
> - return 0;
> + int vfio_enabled = 0;
> 
> - pci_vfio_enable();
> + if (!internal_config.no_pci) {
> + pci_vfio_enable();
> + vfio_enabled |= pci_vfio_is_enabled();
> + }

Could there be a situation where we need to know if a particular VFIO subsystem 
is enabled? Do you think it's worth adding (e.g. vfio_enabled |= 
VFIO_PCI_ENABLED or something)? (I don't imply it is necessary, just asking)

Thanks,
Anatoly

[dpdk-dev] [PATCH 3/6] vhost: add reconnect ability

[Michael S. Tsirkin]

On Tue, May 10, 2016 at 08:07:00AM +, Xie, Huawei wrote:
> On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote:
> > On Tue, May 10, 2016 at 07:24:10AM +, Xie, Huawei wrote:
> >> On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
> >>> On Mon, May 09, 2016 at 04:47:02PM +, Xie, Huawei wrote:
>  On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
> > +static void *
> > +vhost_user_client_reconnect(void *arg)
> > +{
> > +   struct reconnect_info *reconn = arg;
> > +   int ret;
> > +
> > +   RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");
> > +   while (1) {
> > +   ret = connect(reconn->fd, (struct sockaddr 
> > *)>un,
> > +   sizeof(reconn->un));
> > +   if (ret == 0)
> > +   break;
> > +   sleep(1);
> > +   }
> > +
> > +   vhost_user_add_connection(reconn->fd, reconn->vsocket);
> > +   free(reconn);
> > +
> > +   return NULL;
> > +}
> > +
>  We could create hundreds of vhost-user ports in OVS. Wihout connections
>  with QEMU established, those ports are just inactive. This works fine in
>  server mode.
>  With client modes, do we need to create hundreds of vhost threads? This
>  would be too interruptible.
>  How about we create only one thread and do the reconnections for all the
>  unconnected socket?
> >>> Yes, good point and good suggestion. Will do it in v2.
> >> Hi Michael:
> >> This reminds me another irrelevant issue.
> >> In OVS, currently for each vhost port, we create an unix domain socket,
> >> and QEMU vhost proxy connects to this socket, and we use this to
> >> identify the connection. This works fine but is our workaround,
> >> otherwise we have no way to identify the connection.
> >> Do you think if this is an issue?
> 
> Let us say vhost creates one unix domain socket, with path as "sockpath",
> and two virtio ports in two VMS both connect to the same socket with the
> following command line
> -chardev socket,id=char0,path=sockpath
> How could vhost identify the connection?

getpeername(2)?


> 
> Workarounds:
> vhost creates two unix domain sockets, with path as "sockpath1" and
> "sockpath2" respectively,
> and the virtio ports in two VMS respectively connect to "sockpath1" and
> "sockpath2".
> 
> If we have some name string from QEMU over vhost, as you mentioned, we
> could create only one socket with path "sockpath".
> User ensure that the names are unique, just as how they do with multiple
> sockets.
> 

Seems rather fragile.

> > I'm sorry, I have trouble understanding what you wrote above.
> > What is the issue you are trying to work around?
> >
> >> Do we have plan to support identification in VHOST_USER_MESSAGE? With
> >> the identification, if vhost as server, we only need to create one
> >> socket which receives multiple connections, and use the ID in the
> >> message to identify the connection.
> >>
> >> /huawei
> > Sending e.g. -name string from qemu over vhost might be useful
> > for debugging, but I'm not sure it's a good idea to
> > rely on it being unique.
> >
> >>> Thanks.
> >>>
> >>>   --yliu
> >>>
> 

[dpdk-dev] [PATCH] vhost: fix buffer not null terminated

[Yuanhan Liu]

On Tue, May 10, 2016 at 06:11:18PM +0200, Daniel Mrzyglod wrote:
> Fix issue reported by Coverity.
> Coverity ID 124556
> 
> If the buffer is treated as a null terminated string in later operations,
> a buffer overflow or over-read may occur.
> 
> In vhost_set_ifname: The string buffer may not have a null terminator if
> the source string's length is equal to the buffer size
> 
> Fixes: 54292e9520e0 ("vhost: support ifname for vhost-user")
> 
> Signed-off-by: Daniel Mrzyglod 

Applied to dpdk-next-virtio.

Thanks.

--yliu

[dpdk-dev] [PATCH v4 2/3] bnx2x: enhance stats get

[Remy Horton]

On 07/05/2016 01:14, Rasesh Mody wrote:
[..]
>>> Enhance the stats_get() routine to display drop counters under imissed
>>> counter.
>>> Added extended stats get support to provide additional info.
>>> Encorporated review comment to rename some of the stats.
[..]
> We shall split this patch into an enhancement and a bug fix.

Keep in mind that the xstats API is changing so that stats_get() no 
longer includes strings:

http://thread.gmane.org/gmane.comp.networking.dpdk.devel/37079
http://thread.gmane.org/gmane.comp.networking.dpdk.devel/37571

..Remy

[dpdk-dev] rte_malloc

[Mahdi Moradmand Badie]

Thanks Sergio,
Yes sure,
I attached files, it seems so easy but doesn't work.
Thanks,

On 10 May 2016 at 04:12, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at intel.com> wrote:

> Hi,
>
> On 09/05/2016 18:32, Mahdi Moradmand Badie wrote:
>
>> Hello All,
>>
>> I had a problem regarding use the rte_malloc.
>> I want to know if I want to use rte_malloc instead of malloc just mak
>> change like this
>> struct lcore_params *p = malloc
>> <
>> http://dpdk.org/doc/api/rte__malloc_8h.html#afb7316a4ec228ed9b8ffc1864b03d85b
>> >
>> (sizeof(*p)); ==>
>> struct lcore_params *p = rte_malloc
>> <
>> http://dpdk.org/doc/api/rte__malloc_8h.html#afb7316a4ec228ed9b8ffc1864b03d85b
>> >(NULL,
>> sizeof(*p), 0);
>> is enough ?
>>
>
> Yes, malloc(sizeof(*p)) has an equivalent behavior to rte_malloc(NULL,
> sizeof(*p), 0)
> in the context of a DPDK application.
>
> Because I have problem and Segmentation fault (core dumped) ??
>>
>
> Could you provide more details of how to reproduce or could you try to
> reproduce your problem using a very simple example like
> examples/helloworld ?
>
> Sergio
>
> Thanks in advance,
>>
>>
>>
>


-- 
M at hdi Mor at dm@nd B at die

[dpdk-dev] rte_malloc

[Mahdi Moradmand Badie]

Thanks Sergio,
Yes sure,
I attached files, it seems so easy but doesn't work.
Thanks,

On 10 May 2016 at 04:12, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at intel.com> wrote:

> Hi,
>
> On 09/05/2016 18:32, Mahdi Moradmand Badie wrote:
>
>> Hello All,
>>
>> I had a problem regarding use the rte_malloc.
>> I want to know if I want to use rte_malloc instead of malloc just mak
>> change like this
>> struct lcore_params *p = malloc
>> <
>> http://dpdk.org/doc/api/rte__malloc_8h.html#afb7316a4ec228ed9b8ffc1864b03d85b
>> >
>> (sizeof(*p)); ==>
>> struct lcore_params *p = rte_malloc
>> <
>> http://dpdk.org/doc/api/rte__malloc_8h.html#afb7316a4ec228ed9b8ffc1864b03d85b
>> >(NULL,
>> sizeof(*p), 0);
>> is enough ?
>>
>
> Yes, malloc(sizeof(*p)) has an equivalent behavior to rte_malloc(NULL,
> sizeof(*p), 0)
> in the context of a DPDK application.
>
> Because I have problem and Segmentation fault (core dumped) ??
>>
>
> Could you provide more details of how to reproduce or could you try to
> reproduce your problem using a very simple example like
> examples/helloworld ?
>
> Sergio
>
> Thanks in advance,
>>
>>
>>
>


-- 
M at hdi Mor at dm@nd B at die

[dpdk-dev] [PATCHv2 0/5] add packet capture framework

[Remy Horton]

On 10/05/2016 10:39, Reshma Pattan wrote:
[..]
> Reshma Pattan (5):
>librte_ether: protect add/remove of rxtx callbacks with spinlocks
>lib/librte_pdump: add new library for packet capturing support
>app/pdump: add pdump tool for packet capturing
>app/test-pmd: add pdump initialization uninitialization
>doc: update doc for packet capture framework

Acked-by: Remy Horton 

[dpdk-dev] Ring PMD: why are stats counters atomic?

[Mauricio Vásquez]

Hello,

Per-queue stats counters are defined as rte_atomic64_t, in the tx/rx
functions, they are atomically increased if the rings have the multiple
consumers/producer flag enabled.

According to the design principles, the application should not invoke those
functions on the same queue on different cores, then I think that atomic
increasing is not necessary.

Is there something wrong with my reasoning?, If not, I am willing to send a
patch.

Thank you very much,

Mauricio V,

[dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a

[Jerin Jacob]

On Tue, May 10, 2016 at 10:10:07AM +0800, Jianbo Liu wrote:
> On 10 May 2016 at 00:17, Jerin Jacob  
> wrote:
> > On Mon, May 09, 2016 at 11:22:15PM +0800, Jianbo Liu wrote:
> >> On 9 May 2016 at 20:11, Jerin Jacob  
> >> wrote:
> >> > On Mon, May 09, 2016 at 07:02:36PM +0800, Jianbo Liu wrote:
> >> >> On 9 May 2016 at 17:06, Jerin Jacob  
> >> >> wrote:
> >> >> > On Mon, May 09, 2016 at 07:18:22PM +0530, Hemant Agrawal wrote:
> >> >> >> This patch introduces dpaa2 machine target to address difference
> >> >> >> in cpu parameter, number of core to 8 and no numa support
> >> >> >> w.r.t default armv8-a machine
> >> >> >>
> >> >> >> Signed-off-by: Hemant Agrawal 
> >> >> >> ---
> >
> > Snip
> >
> >> >> >> +#
> >> >> >> +# Compile Environment Abstraction Layer
> >> >> >> +#
> >> >> >> +CONFIG_RTE_MAX_LCORE=8
> >> >> >> +CONFIG_RTE_MAX_NUMA_NODES=1
> >> >> >> +CONFIG_RTE_EAL_IGB_UIO=n
> >> >> >
> >> >> > I think it makes sense to move this option to generic arm64 config
> >> >> > as upstream arm64 kernel does not have support for sysfs based PCI 
> >> >> > mmap
> >> >> > resource file,(/sys/bus/pci/devices/B:D:F/resource[_wc]X) need for
> >> >> > CONFIG_RTE_EAL_IGB_UIO to work) and use VFIO for all cases.
> >> >> >
> >> >> > Any objections?
> >> >> >
> >> >> Is there any conflict to keep both?
> >> >
> >> > I would like to avoid the case like below in dpdk.org ml.
> >> > http://dpdk.org/ml/archives/dev/2016-January/031313.html
> >> >
> >> So no conflict to enable both.
> >
> > IMO, Conflict part comes secondary, It does not even work with upstream 
> > kernel.
> > Why keep the broken configuration? Two main reasons I think it makes
> > sense to disable
> > - It is broken, I don't think arm64 kernel developers likes non VFIO 
> > approach
> I don't think DPDK user is kernel developer in most cases. They maybe
> like the traditional way.

But, the traditional way is _broken_. If we create the shortcut in
dpdk.org then upstream arm64 linux kernel will never get fixed.I attempted
twice to fix it, but arm64 kernel developers like VFIO approach.
if you think it makes sense to have traditional way then can you
upstream the patch to the arm64 linux kernel and add it in common
config

Technically, with VFIO and VFIONOIOMMU way we can replace the need for
uio in both host and virtualization use cases for arm64.

> > now. So mostly likely it will be broken
> > - Trying to avoid out of tree patches wherever is possible as
> > distribution folks like to work with upstream version.
> Agree. But there is possible that people/company maintain their own kernel 
> tree.

This excactly same thing we would like to avoid in long term.

> >
> >> I'd rather keep as it is for armv8a defconfig, becasue it's the base,
> >> any change may affect existing user.
> > IMO, It makes sense to disable at armv8a defconfig otherwise all armv8
> > variants need add CONFIG_RTE_EAL_IGB_UIO=n in all the configs and its
> > arch specific issue.
> We don't have to do that.
> You didn't explictly disable this config in your current
> defconfig_arm64-thunderx-linuxapp-gcc, but you know which module to
> bind.
But not all the end users.

[dpdk-dev] [PATCH 3/6] vhost: add reconnect ability

[Michael S. Tsirkin]

On Tue, May 10, 2016 at 07:24:10AM +, Xie, Huawei wrote:
> On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
> > On Mon, May 09, 2016 at 04:47:02PM +, Xie, Huawei wrote:
> >> On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
> >>> +static void *
> >>> +vhost_user_client_reconnect(void *arg)
> >>> +{
> >>> + struct reconnect_info *reconn = arg;
> >>> + int ret;
> >>> +
> >>> + RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");
> >>> + while (1) {
> >>> + ret = connect(reconn->fd, (struct sockaddr *)>un,
> >>> + sizeof(reconn->un));
> >>> + if (ret == 0)
> >>> + break;
> >>> + sleep(1);
> >>> + }
> >>> +
> >>> + vhost_user_add_connection(reconn->fd, reconn->vsocket);
> >>> + free(reconn);
> >>> +
> >>> + return NULL;
> >>> +}
> >>> +
> >> We could create hundreds of vhost-user ports in OVS. Wihout connections
> >> with QEMU established, those ports are just inactive. This works fine in
> >> server mode.
> >> With client modes, do we need to create hundreds of vhost threads? This
> >> would be too interruptible.
> >> How about we create only one thread and do the reconnections for all the
> >> unconnected socket?
> > Yes, good point and good suggestion. Will do it in v2.
> 
> Hi Michael:
> This reminds me another irrelevant issue.
> In OVS, currently for each vhost port, we create an unix domain socket,
> and QEMU vhost proxy connects to this socket, and we use this to
> identify the connection. This works fine but is our workaround,
> otherwise we have no way to identify the connection.
> Do you think if this is an issue?

I'm sorry, I have trouble understanding what you wrote above.
What is the issue you are trying to work around?

> Do we have plan to support identification in VHOST_USER_MESSAGE? With
> the identification, if vhost as server, we only need to create one
> socket which receives multiple connections, and use the ID in the
> message to identify the connection.
> 
> /huawei

Sending e.g. -name string from qemu over vhost might be useful
for debugging, but I'm not sure it's a good idea to
rely on it being unique.

> 
> >
> > Thanks.
> >
> > --yliu
> >
> 

[dpdk-dev] [PATCH v2] i40evf: fix return value if command fails

[Jingjing Wu]

Previously, if message is sent successfully, but no response is
received, function "i40evf_execute_vf_cmd" will return without error.
The root cause is value "err" is overwritten. This patch fixes it.

Fixes: ae19955e7c86 ("i40evf: support reporting PF reset")
Signed-off-by: Jingjing Wu 
---
v2 changes:
 set default err value for each case in switch.

 drivers/net/i40e/i40e_ethdev_vf.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 90682ac..c6efa1a 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -330,8 +330,7 @@ i40evf_execute_vf_cmd(struct rte_eth_dev *dev, struct 
vf_cmd_info *args)
struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
struct i40evf_arq_msg_info info;
enum i40evf_aq_result ret;
-   int err = -1;
-   int i = 0;
+   int err, i = 0;

if (_atomic_set_cmd(vf, args->ops))
return -1;
@@ -352,19 +351,19 @@ i40evf_execute_vf_cmd(struct rte_eth_dev *dev, struct 
vf_cmd_info *args)
switch (args->ops) {
case I40E_VIRTCHNL_OP_RESET_VF:
/*no need to process in this function */
+   err = 0;
break;
case I40E_VIRTCHNL_OP_VERSION:
case I40E_VIRTCHNL_OP_GET_VF_RESOURCES:
/* for init adminq commands, need to poll the response */
+   err = -1;
do {
ret = i40evf_read_pfmsg(dev, );
if (ret == I40EVF_MSG_CMD) {
err = 0;
break;
-   } else if (ret == I40EVF_MSG_ERR) {
-   err = -1;
+   } else if (ret == I40EVF_MSG_ERR)
break;
-   }
rte_delay_ms(ASQ_DELAY_MS);
/* If don't read msg or read sys event, continue */
} while (i++ < MAX_TRY_TIMES);
@@ -373,6 +372,7 @@ i40evf_execute_vf_cmd(struct rte_eth_dev *dev, struct 
vf_cmd_info *args)

default:
/* for other adminq in running time, waiting the cmd done flag 
*/
+   err = -1;
do {
if (vf->pend_cmd == I40E_VIRTCHNL_OP_UNKNOWN) {
err = 0;
-- 
2.4.0

[dpdk-dev] [PATCH 0/6] vhost: add vhost-user client mode and reconnect ability

[Yuanhan Liu]

On Tue, May 10, 2016 at 03:23:15AM +, Xu, Qian Q wrote:
> Do we need patch qemu for the reconnect case?  

Yes, we need some support from QEMU: currently QEMU will not be able
to detect disconnection and hence will not establish the connection
when DPDK vhost restarts.

Following patchset from Marc resolves above issue.

http://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg01507.html

And note that unlike the vhost-user multiple queue support that depends
on some new vhost-uesr message from QEMU, this patchset does not depond
on QEMU.

--yliu
> 
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yuanhan Liu
> Sent: Saturday, May 07, 2016 2:40 PM
> To: dev at dpdk.org
> Cc: Xie, Huawei; Yuanhan Liu
> Subject: [dpdk-dev] [PATCH 0/6] vhost: add vhost-user client mode and 
> reconnect ability
> 
> Both the vhost-user backend (DPDK here) and frontend (QEMU) could be server, 
> as well as client. DPDK just acts as server so far. This patch set would make 
> it possible to act as both.
> 
> A new arg (flags) is introduced for API rte_vhost_driver_register(). And the 
> client mode is enabled when RTE_VHOST_USER_CLIENT is given. Note that this 
> implies an API breakage. However, since this release deals with ABI/API 
> refactoring, it should not be an issue.
> 
> With the DPDK as client, it's easier to implement the "reconnect" ability, 
> which means we could still make vhost-user work after DPDK restarts.
> 
> 
> ---
> Yuanhan Liu (6):
>   vhost: rename structs for enabling client mode
>   vhost: add vhost-user client mode
>   vhost: add reconnect ability
>   vhost: workaround stale vring base
>   examples/vhost: add client and reconnect option
>   vhost: add pmd client and reconnect option
> 
>  drivers/net/vhost/rte_eth_vhost.c|  54 +++-
>  examples/vhost/main.c|  23 +-
>  lib/librte_vhost/rte_virtio_net.h|  12 +-
>  lib/librte_vhost/vhost_user/vhost-net-user.c | 355 
> ++-
>  lib/librte_vhost/vhost_user/vhost-net-user.h |   6 -
>  lib/librte_vhost/virtio-net.c|   8 +
>  6 files changed, 313 insertions(+), 145 deletions(-)
> 
> --
> 1.9.0

[dpdk-dev] [RFC] mbuf: remove unused rx error flags

[Olivier Matz]

Following the discussions from:
http://dpdk.org/ml/archives/dev/2015-July/021721.html
http://dpdk.org/ml/archives/dev/2016-April/038143.html

The value of these flags is 0, making them useless. Today, no example
application checks them on RX, and only few drivers sets them, and
silently give wrong packets to the application, which should not happen.

This patch removes the unused flags from rte_mbuf, and their use in the
drivers. The enic driver is modified to drop bad packets, but i40e and
fm10k are kept as they are today and should be fixed to drop bad packets.

Fixes: c22265f6 ("mbuf: add new packet flags for i40e")
Signed-off-by: Olivier Matz 
---

Hi,

Here is a draft patch that removes the rx mbuf flags, as discussed.

John, I did not test the patch on the enic driver, so please review it
carefully.

Comments are welcome.

Olivier


 drivers/net/enic/enic_rx.c | 31 ++-
 drivers/net/fm10k/fm10k_rxtx.c | 16 
 drivers/net/fm10k/fm10k_rxtx_vec.c |  2 +-
 drivers/net/i40e/i40e_rxtx.c   | 15 ---
 lib/librte_mbuf/rte_mbuf.c |  4 
 lib/librte_mbuf/rte_mbuf.h |  5 +
 6 files changed, 16 insertions(+), 57 deletions(-)

diff --git a/drivers/net/enic/enic_rx.c b/drivers/net/enic/enic_rx.c
index b3ad9ea..bad802e 100644
--- a/drivers/net/enic/enic_rx.c
+++ b/drivers/net/enic/enic_rx.c
@@ -144,20 +144,15 @@ enic_cq_rx_desc_n_bytes(struct cq_desc *cqd)
 }

 static inline uint8_t
-enic_cq_rx_to_pkt_err_flags(struct cq_desc *cqd, uint64_t *pkt_err_flags_out)
+enic_cq_rx_check_err(struct cq_desc *cqd)
 {
struct cq_enet_rq_desc *cqrd = (struct cq_enet_rq_desc *)cqd;
uint16_t bwflags;
-   int ret = 0;
-   uint64_t pkt_err_flags = 0;

bwflags = enic_cq_rx_desc_bwflags(cqrd);
-   if (unlikely(enic_cq_rx_desc_packet_error(bwflags))) {
-   pkt_err_flags = PKT_RX_MAC_ERR;
-   ret = 1;
-   }
-   *pkt_err_flags_out = pkt_err_flags;
-   return ret;
+   if (unlikely(enic_cq_rx_desc_packet_error(bwflags)))
+   return 1;
+   return 0;
 }

 /*
@@ -253,7 +248,7 @@ enic_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
struct enic *enic = vnic_dev_priv(rq->vdev);
unsigned int rx_id;
struct rte_mbuf *nmb, *rxmb;
-   uint16_t nb_rx = 0;
+   uint16_t nb_rx = 0, nb_err = 0;
uint16_t nb_hold;
struct vnic_cq *cq;
volatile struct cq_desc *cqd_ptr;
@@ -269,7 +264,6 @@ enic_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
volatile struct rq_enet_desc *rqd_ptr;
dma_addr_t dma_addr;
struct cq_desc cqd;
-   uint64_t ol_err_flags;
uint8_t packet_error;

/* Check for pkts available */
@@ -293,7 +287,7 @@ enic_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
}

/* A packet error means descriptor and data are untrusted */
-   packet_error = enic_cq_rx_to_pkt_err_flags(, _err_flags);
+   packet_error = enic_cq_rx_check_err();

/* Get the mbuf to return and replace with one just allocated */
rxmb = rq->mbuf_ring[rx_id];
@@ -318,6 +312,13 @@ enic_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
rqd_ptr->address = rte_cpu_to_le_64(dma_addr);
rqd_ptr->length_type = cpu_to_le16(nmb->buf_len);

+   /* Drop incoming bad packet */
+   if (packet_error) {
+   rte_pktmbuf_free(rxmb);
+   nb_err++;
+   continue;
+   }
+
/* Fill in the rest of the mbuf */
rxmb->data_off = RTE_PKTMBUF_HEADROOM;
rxmb->nb_segs = 1;
@@ -327,10 +328,6 @@ enic_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
rxmb->pkt_len = enic_cq_rx_desc_n_bytes();
rxmb->packet_type = enic_cq_rx_flags_to_pkt_type();
enic_cq_rx_to_pkt_flags(, rxmb);
-   } else {
-   rxmb->pkt_len = 0;
-   rxmb->packet_type = 0;
-   rxmb->ol_flags = 0;
}
rxmb->data_len = rxmb->pkt_len;

@@ -342,7 +339,7 @@ enic_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
rx_pkts[nb_rx++] = rxmb;
}

-   nb_hold += nb_rx;
+   nb_hold += nb_rx + nb_err;
cq->to_clean = rx_id;

if (nb_hold > rq->rx_free_thresh) {
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index 81ed4e7..dd92a91 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -96,22 +96,6 @@ rx_desc_to_ol_flags(struct rte_mbuf *m, const union 
fm10k_rx_desc *d)

if (d->w.pkt_info & FM10K_RXD_RSSTYPE_MASK)
m->ol_flags |= PKT_RX_RSS_HASH;
-
-   if 

[dpdk-dev] [PATCHv2 5/5] doc: update doc for packet capture framework

[Reshma Pattan]

added programmers guide for librte_pdump.
added sample application guide for app/pdump application.
updated release note for packet capture framework changes.

Signed-off-by: Reshma Pattan 
---
 MAINTAINERS |   3 +
 doc/guides/prog_guide/index.rst |   1 +
 doc/guides/prog_guide/pdump_library.rst | 121 
 doc/guides/rel_notes/release_16_07.rst  |   7 ++
 doc/guides/sample_app_ug/index.rst  |   1 +
 doc/guides/sample_app_ug/pdump.rst  | 109 
 6 files changed, 242 insertions(+)
 create mode 100644 doc/guides/prog_guide/pdump_library.rst
 create mode 100644 doc/guides/sample_app_ug/pdump.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index b6a39c7..6ddc818 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -432,6 +432,9 @@ Pdump
 M: Reshma Pattan 
 F: lib/librte_pdump/
 F: app/pdump/
+F: doc/guides/prog_guide/pdump_library.rst
+F: doc/guides/sample_app_ug/pdump.rst
+

 Hierarchical scheduler
 M: Cristian Dumitrescu 
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index b862d0c..4caf969 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -71,6 +71,7 @@ Programmer's Guide
 writing_efficient_code
 profile_app
 glossary
+pdump_library


 **Figures**
diff --git a/doc/guides/prog_guide/pdump_library.rst 
b/doc/guides/prog_guide/pdump_library.rst
new file mode 100644
index 000..6af77b9
--- /dev/null
+++ b/doc/guides/prog_guide/pdump_library.rst
@@ -0,0 +1,121 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+.. _Pdump_Library:
+
+pdump Library
+=
+
+Pdump library provides framework for packet capturing on DPDK.
+
+Operation
+-
+
+Pdump library provides APIs to support packet capturing on dpdk ethernet 
devices.
+Library provides APIs to initialize the packet capture framework, 
enable/disable
+the packet capture and un initialize the packet capture framework.
+
+Pdump library works on server and client based model.
+
+Sever is responsible for enabling/disabling the packet captures.
+Clients are responsible for requesting enable/disable of the
+packet captures.
+
+As part of packet capture framework initialization, pthread and
+the server socket is created. Only one server socket is allowed on the system.
+As part of enabling/disabling the packet capture, client sockets are created
+and multiple client sockets are allowed.
+Who ever calls initialization first they will succeed with the initialization,
+next subsequent calls of initialization are not allowed. So next users can only
+request enabling/disabling the packet capture.
+
+Library provides below APIs
+
+``rte_pdump_init()``
+This API initializes the packet capture framework.
+
+``rte_pdump_enable()``
+This API enables the packet capturing on a given port and queue.
+Note: filter option in the API is place holder for future use.
+
+``rte_pdump_enable_by_deviceid()``
+This API enables the packet capturing on a given device id
+(device name or pci address) and queue.
+Note: filter option in the API is place holder for future use.
+
+``rte_pdump_disable()``
+This API disables the packet capturing on a given port and queue.
+
+``rte_pdump_disable_by_deviceid()``
+This API disables the packet capturing on a given device_id and queue.
+
+``rte_pdump_uninit()``
+This API un initializes the packet 

[dpdk-dev] [PATCHv2 4/5] app/test-pmd: add pdump initialization uninitialization

[Reshma Pattan]

call rte_pdump_init and rte_pdump_uninit for packet
capturing initialization and uninitialization.

Signed-off-by: Reshma Pattan 
---
 app/test-pmd/testpmd.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 26a174c..e131363 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -75,6 +75,7 @@
 #ifdef RTE_LIBRTE_PMD_XENVIRT
 #include 
 #endif
+#include 

 #include "testpmd.h"
 #include "mempool_osdep.h"
@@ -2018,6 +2019,8 @@ signal_handler(int signum)
if (signum == SIGINT || signum == SIGTERM) {
printf("\nSignal %d received, preparing to exit...\n",
signum);
+   /* uninitialize packet capture framework */
+   rte_pdump_uninit();
force_quit();
/* exit with the expected status */
signal(signum, SIG_DFL);
@@ -2038,6 +2041,9 @@ main(int argc, char** argv)
if (diag < 0)
rte_panic("Cannot init EAL\n");

+   /* initialize packet capture framework */
+   rte_pdump_init();
+
nb_ports = (portid_t) rte_eth_dev_count();
if (nb_ports == 0)
RTE_LOG(WARNING, EAL, "No probed ethernet devices\n");
-- 
2.5.0

[dpdk-dev] [PATCHv2 3/5] app/pdump: add pdump tool for packet capturing

[Reshma Pattan]

New tool added for packet capturing on dpdk.
This tool supports command line options.
This tool runs as secondary process by default.

Command line supports various parameters to capture
the packets.

User should pass on a)port and queue (or) b)pci address
and queue (or) c)device name and queue to capture
the packets.

Users also need to pass on either pcap file name or
any linux iface, on to which packets captured from dpdk
ports will be sent on for the users to view using tcpdump.

Users have option to capture packets either a) in RX
direction, b)(or) in TX direction c)(or) from both the
directions.

User can pass on ring_size and mempool parameters using
command line, but these are optional parameters.
These are used to create ring and mempool objects for packet
mirroring from primary application to tool. If user doesn't
provide any values, default values will be used internally
for the creation of the ring and mempool.

Signed-off-by: Reshma Pattan 
---
 MAINTAINERS|   1 +
 app/Makefile   |   1 +
 app/pdump/Makefile |  45 +++
 app/pdump/main.c   | 936 +
 4 files changed, 983 insertions(+)
 create mode 100644 app/pdump/Makefile
 create mode 100644 app/pdump/main.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 74140c7..b6a39c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -431,6 +431,7 @@ F: doc/guides/sample_app_ug/packet_ordering.rst
 Pdump
 M: Reshma Pattan 
 F: lib/librte_pdump/
+F: app/pdump/

 Hierarchical scheduler
 M: Cristian Dumitrescu 
diff --git a/app/Makefile b/app/Makefile
index 1151e09..c593efa 100644
--- a/app/Makefile
+++ b/app/Makefile
@@ -37,5 +37,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test-pipeline
 DIRS-$(CONFIG_RTE_TEST_PMD) += test-pmd
 DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_test
 DIRS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += proc_info
+DIRS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += pdump

 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/app/pdump/Makefile b/app/pdump/Makefile
new file mode 100644
index 000..96bb4af
--- /dev/null
+++ b/app/pdump/Makefile
@@ -0,0 +1,45 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+APP = dpdk_pdump
+
+CFLAGS += $(WERROR_FLAGS)
+
+# all source are stored in SRCS-y
+
+SRCS-y := main.c
+
+# this application needs libraries first
+DEPDIRS-y += lib
+
+include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/pdump/main.c b/app/pdump/main.c
new file mode 100644
index 000..5d57382
--- /dev/null
+++ b/app/pdump/main.c
@@ -0,0 +1,936 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from 

[dpdk-dev] [PATCHv2 2/5] lib/librte_pdump: add new library for packet capturing support

[Reshma Pattan]

Added new library for packet capturing support.

Added public api rte_pdump_init, applications should call
this as part of their application setup to have packet
capturing framework ready.

Added public api rte_pdump_uninit to un initialize the packet
capturing framework.

Added public apis rte_pdump_enable and rte_pdump_disable to
enable and disable packet capturing on specific port and queue.

Added public apis rte_pdump_enable_by_deviceid and
rte_pdump_disable_by_deviceid to enable and disable packet
capturing on a specific device (pci address or name) and queue.

Signed-off-by: Reshma Pattan 
---
 MAINTAINERS|   4 +
 config/common_base |   5 +
 lib/Makefile   |   1 +
 lib/librte_pdump/Makefile  |  55 +++
 lib/librte_pdump/rte_pdump.c   | 816 +
 lib/librte_pdump/rte_pdump.h   | 186 
 lib/librte_pdump/rte_pdump_version.map |  12 +
 mk/rte.app.mk  |   1 +
 8 files changed, 1080 insertions(+)
 create mode 100644 lib/librte_pdump/Makefile
 create mode 100644 lib/librte_pdump/rte_pdump.c
 create mode 100644 lib/librte_pdump/rte_pdump.h
 create mode 100644 lib/librte_pdump/rte_pdump_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 1953ea2..74140c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -428,6 +428,10 @@ F: app/test/test_reorder*
 F: examples/packet_ordering/
 F: doc/guides/sample_app_ug/packet_ordering.rst

+Pdump
+M: Reshma Pattan 
+F: lib/librte_pdump/
+
 Hierarchical scheduler
 M: Cristian Dumitrescu 
 F: lib/librte_sched/
diff --git a/config/common_base b/config/common_base
index 35d38d9..b6ec35b 100644
--- a/config/common_base
+++ b/config/common_base
@@ -472,6 +472,11 @@ CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
 CONFIG_RTE_LIBRTE_REORDER=y

 #
+# Compile the pdump library
+#
+CONFIG_RTE_LIBRTE_PDUMP=y
+
+#
 # Compile librte_port
 #
 CONFIG_RTE_LIBRTE_PORT=y
diff --git a/lib/Makefile b/lib/Makefile
index f254dba..ca7c02f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -57,6 +57,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port
 DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table
 DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline
 DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder
+DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += librte_pdump

 ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
 DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
diff --git a/lib/librte_pdump/Makefile b/lib/librte_pdump/Makefile
new file mode 100644
index 000..af81a28
--- /dev/null
+++ b/lib/librte_pdump/Makefile
@@ -0,0 +1,55 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_pdump.a
+
+CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
+CFLAGS += -D_GNU_SOURCE
+
+EXPORT_MAP := rte_pdump_version.map
+
+LIBABIVER := 1
+
+# all source are stored in SRCS-y
+SRCS-$(CONFIG_RTE_LIBRTE_PDUMP) := rte_pdump.c
+
+# install this header file
+SYMLINK-$(CONFIG_RTE_LIBRTE_PDUMP)-include := rte_pdump.h
+
+# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += lib/librte_eal
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += lib/librte_ether
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_pdump/rte_pdump.c b/lib/librte_pdump/rte_pdump.c
new file mode 100644
index 

[dpdk-dev] [PATCHv2 1/5] librte_ether: protect add/remove of rxtx callbacks with spinlocks

[Reshma Pattan]

* added spinlocks around add/remove logic of rxtx callbacks to
  avoid corruption of callback lists in multithreaded context.

* added new public api rte_eth_add_first_rx_callback to add given
  callback as head of list.

* converted rte_eth_dev_get_port_by_name to public API.

* add new fields to rte_eth_dev_info struct
  New fields nb_rx_queues and nb_tx_queues are added to
  rte_eth_dev_info structure.
  Changes to API rte_eth_dev_info_get() are done to update
  these new fields to rte_eth_dev_info object.

Signed-off-by: Reshma Pattan 
---
 lib/librte_ether/rte_ethdev.c  | 121 +
 lib/librte_ether/rte_ethdev.h  |  45 
 lib/librte_ether/rte_ether_version.map |   9 +++
 3 files changed, 132 insertions(+), 43 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a31018e..cd2bc17 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -77,6 +77,12 @@ static uint8_t nb_ports;
 /* spinlock for eth device callbacks */
 static rte_spinlock_t rte_eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;

+/* spinlock for add/remove rx callbacks */
+static rte_spinlock_t rte_eth_rx_cb_lock = RTE_SPINLOCK_INITIALIZER;
+
+/* spinlock for add/remove tx callbacks */
+static rte_spinlock_t rte_eth_tx_cb_lock = RTE_SPINLOCK_INITIALIZER;
+
 /* store statistics names and its offset in stats structure  */
 struct rte_eth_xstats_name_off {
char name[RTE_ETH_XSTATS_NAME_SIZE];
@@ -421,7 +427,7 @@ rte_eth_dev_get_name_by_port(uint8_t port_id, char *name)
return 0;
 }

-static int
+int
 rte_eth_dev_get_port_by_name(const char *name, uint8_t *port_id)
 {
int i;
@@ -1639,7 +1645,6 @@ rte_eth_dev_set_rx_queue_stats_mapping(uint8_t port_id, 
uint16_t rx_queue_id,
STAT_QMAP_RX);
 }

-
 void
 rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info)
 {
@@ -1661,6 +1666,8 @@ rte_eth_dev_info_get(uint8_t port_id, struct 
rte_eth_dev_info *dev_info)
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
dev_info->pci_dev = dev->pci_dev;
dev_info->driver_name = dev->data->drv_name;
+   dev_info->nb_rx_queues = dev->data->nb_rx_queues;
+   dev_info->nb_tx_queues = dev->data->nb_tx_queues;
 }

 int
@@ -2925,7 +2932,6 @@ rte_eth_add_rx_callback(uint8_t port_id, uint16_t 
queue_id,
rte_errno = EINVAL;
return NULL;
}
-
struct rte_eth_rxtx_callback *cb = rte_zmalloc(NULL, sizeof(*cb), 0);

if (cb == NULL) {
@@ -2936,6 +2942,7 @@ rte_eth_add_rx_callback(uint8_t port_id, uint16_t 
queue_id,
cb->fn.rx = fn;
cb->param = user_param;

+   rte_spinlock_lock(_eth_rx_cb_lock);
/* Add the callbacks in fifo order. */
struct rte_eth_rxtx_callback *tail =
rte_eth_devices[port_id].post_rx_burst_cbs[queue_id];
@@ -2948,6 +2955,42 @@ rte_eth_add_rx_callback(uint8_t port_id, uint16_t 
queue_id,
tail = tail->next;
tail->next = cb;
}
+   rte_spinlock_unlock(_eth_rx_cb_lock);
+
+   return cb;
+}
+
+void *
+rte_eth_add_first_rx_callback(uint8_t port_id, uint16_t queue_id,
+   rte_rx_callback_fn fn, void *user_param)
+{
+#ifndef RTE_ETHDEV_RXTX_CALLBACKS
+   rte_errno = ENOTSUP;
+   return NULL;
+#endif
+   /* check input parameters */
+   if (!rte_eth_dev_is_valid_port(port_id) || fn == NULL ||
+   queue_id >= rte_eth_devices[port_id].data->nb_rx_queues) {
+   rte_errno = EINVAL;
+   return NULL;
+   }
+
+   struct rte_eth_rxtx_callback *cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+
+   if (cb == NULL) {
+   rte_errno = ENOMEM;
+   return NULL;
+   }
+
+   cb->fn.rx = fn;
+   cb->param = user_param;
+
+   rte_spinlock_lock(_eth_rx_cb_lock);
+   /* Add the callbacks at fisrt position*/
+   cb->next = rte_eth_devices[port_id].post_rx_burst_cbs[queue_id];
+   rte_smp_wmb();
+   rte_eth_devices[port_id].post_rx_burst_cbs[queue_id] = cb;
+   rte_spinlock_unlock(_eth_rx_cb_lock);

return cb;
 }
@@ -2977,6 +3020,7 @@ rte_eth_add_tx_callback(uint8_t port_id, uint16_t 
queue_id,
cb->fn.tx = fn;
cb->param = user_param;

+   rte_spinlock_lock(_eth_tx_cb_lock);
/* Add the callbacks in fifo order. */
struct rte_eth_rxtx_callback *tail =
rte_eth_devices[port_id].pre_tx_burst_cbs[queue_id];
@@ -2989,6 +3033,7 @@ rte_eth_add_tx_callback(uint8_t port_id, uint16_t 
queue_id,
tail = tail->next;
tail->next = cb;
}
+   rte_spinlock_unlock(_eth_tx_cb_lock);

return cb;
 }
@@ -3007,29 +3052,24 @@ rte_eth_remove_rx_callback(uint8_t port_id, uint16_t 
queue_id,
}

struct rte_eth_dev *dev = _eth_devices[port_id];
-   struct rte_eth_rxtx_callback *cb = 

[dpdk-dev] [PATCHv2 0/5] add packet capture framework

[Reshma Pattan]

This patchset include below changes
1)Changes to librte_ether.
2)New library librte_pdump added for packet capture framework.
3)New app/pdump tool added for packet capturing.
4)Test pmd changes done to initialize packet capture framework.
5)Documentation update.

1)librte_pdump
==
To support packet capturing on dpdk ethernet devices, a new library librte_pdump
is added.Users can develop their own packet capturing application using new 
library APIs.

Operation:
--
Pdump library provides APIs to support packet capturing on dpdk ethernet 
devices.
Library provides APIs to initialize the packet capture framework, enable/disable
the packet capture and un initialize the packet capture framework.

Pdump library works on server and client based model.

Sever is responsible for enabling/disabling the packet captures.
Clients are responsible for requesting enable/disable of the
packet captures.

As part of packet capture framework initialization, pthread and
the server socket is created. Only one server socket is allowed on the system.
As part of enabling/disabling the packet capture, client sockets are created
and multiple client sockets are allowed.
Who ever calls initialization first they will succeed with the initialization,
next subsequent calls of initialization are not allowed. So next users can only
request enabling/disabling the packet capture.

Applications using below APIs need to pass port/device_id, queue, mempool and
ring parameters. Library uses user provided ring and mempool to mirror the rx/tx
packets of the port for users. Users need to deque the rings and write the 
packets
to vdev(pcap/tuntap) to view the packets using any standard tools.

Note:
Mempool and Ring should be mc/mp supportable.
Mempool mbuf size should be big enough to handle the rx/tx packets of a port.

APIs:
-
rte_pdump_init()
rte_pdump_enable()
rte_pdump_enable_by_deviceid()
rte_pdump_disable()
rte_pdump_disable_by_deviceid()
rte_pdump_uninit()

2)app/pdump tool

Tool app/pdump is based on librte_pdump for packet capturing.

This tool by default runs as secondary process, and provides the support for
the command line options for packet capture.

 ./$(RTE_TARGET)/app/pdump -- --pdump='(port= |
   device_id=),
   (queue=2), (rx-dev= |
   tx-dev= |
   rxtx-dev=),
   [ring-size=1024], [mbuf-size=2048], [total-num-mbufs=8191]'

Parameters inside the parenthesis represents the mandatory parameters.
Parameters inside the square brackets represents optional parameters.
User has to pass on packet capture parameters under --pdump parameters, 
multiples of
--pdump can be passed to capture packets on different port and queue 
combinations

Operation:
--
*Tool parse the user command line arguments,
creates the mempool, ring and the PCAP PMD vdev with 'tx_stream' as either
of the device passed in rx-dev|tx-dev|rxtx-dev parameters.

*Then calls the APIs of librte_pdump i.e. 
rte_pdump_enable()/rte_pdump_enable_by_deviceid()
to enable packet capturing on a specific port/device_id and queue by passing on
port|device_id, queue, mempool and ring info.

*Tool runs in while loop to dequeue the packets from the ring and write them to 
pcap device.

*Tool can be stopped using SIGINT, upon which tool calls
rte_pdump_disable()/rte_pdump_disable_by_deviceid() and free the allocated 
resources.

Note:
CONFIG_RTE_LIBRTE_PMD_PCAP flag should be set to yes to compile and run the 
pdump tool.

3)Test-pmd changes
==
Changes are done to test-pmd application to initialize/uninitialize the packet 
capture framework.
So app/pdump tool can be run to see packets of dpdk ports that are used by 
test-pmd.

Similarly any application which needs packet capture should call 
initialize/uninitialize apis of
librate_pdump and use pdump tool to start the capture.

4)Packet capture flow between pdump tool and librte_pdump
=
* Pdump tool (Secondary process) requests packet capture
for specific port|device_id and queue combinations.

*Library in secondary process context creates client socket and communicates
the port|device_id, queue, ring and mempool to server.

*Library initializes server in primary process 'test-pmd' context and serves 
client
request to enable ethernet rxtx call-backs for given port|device_id and queue.?

*Copy the rx/tx packets to passed mempool and enqueue the packets to ring for 
secondary process.

*Pdump tool will dequeue the packets from ring and writes them to PCAPMD vdev,
so ultimately packets will be seen on device passed in rx-dev|tx-dev|rxtx-dev.

*Once the pdump tool is terminated with SIGINT it will disable packet capturing.

*Library receives the disable packet capture request, communicate the info to 
server,
server will remove the ethernet rxtx call-backs.

*Packet capture can be seen using tcpdump command
"tcpdump -ni " (or) "tcpdump ?nr "

5)Example command line
==
sudo 

[dpdk-dev] Ring PMD: why are stats counters atomic?

[Bruce Richardson]

On Tue, May 10, 2016 at 11:13:08AM +0200, Mauricio V?squez wrote:
> Hello,
> 
> Per-queue stats counters are defined as rte_atomic64_t, in the tx/rx
> functions, they are atomically increased if the rings have the multiple
> consumers/producer flag enabled.
> 
> According to the design principles, the application should not invoke those
> functions on the same queue on different cores, then I think that atomic
> increasing is not necessary.
> 
> Is there something wrong with my reasoning?, If not, I am willing to send a
> patch.
> 
> Thank you very much,
> 
Since the rte_rings, on which the ring pmd is obviously based, have 
multi-producer
and multi-consumer support built-in, I thought it might be useful in the ring
PMD itself to allow multiple threads to access the ring queues at the same time,
if the underlying rings are marked as MP/MC safe. When doing enqueues and 
dequeue
from the ring, the stats are either incremented atomically, or non-atomically,
depending on the underlying queue type.

const uint16_t nb_rx = (uint16_t)rte_ring_dequeue_burst(r->rng,
ptrs, nb_bufs);
if (r->rng->flags & RING_F_SC_DEQ)
r->rx_pkts.cnt += nb_rx;
else
rte_atomic64_add(&(r->rx_pkts), nb_rx);

If people don't think this behaviour is worthwhile keeping, I'm ok with removing
it, since all other PMDs have the restriction that the queues are single-thread
only.

Regards,
/Bruce

[dpdk-dev] [PATCH 10/16] vhost: export vid as the only interface to applications

[Yuanhan Liu]

On Tue, May 10, 2016 at 10:13:18AM -0700, Rich Lane wrote:
> On Tue, May 10, 2016 at 9:39 AM, Yuanhan Liu 
> wrote:
> 
> Rich, would you help try by adding following line there and
> do a test? It would be great if this patch has your Tested-by :)
> 
> ? ? internal->vid = vid;
> 
> ?
> The problem is new_device has already returned before that point because
> find_internal_resource failed.

Oh. right.

> I suggest adding a cookie parameter to?rte_vhost_driver_register and passing
> the cookie to each of the vhost_ops. The PMD can use pmd_internals for the
> cookie and the whole internal_list can go away.

TBH, I don't quite like messing rte_vhost_driver_register here.

Maybe I could switch back to the old way to find_internal_resource by
ifname. In such case, I need introduce an API to expose that field
from vhost lib.

> ps. Could you push git branches somewhere for these larger vhost patch series?
> That would make it a lot easier to test than getting patches individually from
> patchwork.

Yes, indeeded. And I have a tree on dpdk.org, but that is mainly for
holding patches for the mainline. I'm thinking I may could add a new
branch there, say staging, just for testing. Thomas, will it work for
you? Or, should I push it to github?

--yliu

[dpdk-dev] [PATCH v1 1/1] enic: fix local ol_flags variable

[Piotr Azarewicz]

Expand local ol_flags field to 64-bits.

The offload flags field (ol_flags) in rte_mbuf structure is 64-bits, so
local copy of it must be 64-bits too. Moreover bit comparison between
16-bits variable and 64-bits value make no sense.

CID 13218 : Operands don't affect result (CONSTANT_EXPRESSION_RESULT)
result_independent_of_operands: ol_flags & (18014398509481984ULL /* 1ULL
<< 54 */) is always 0 regardless of the values of its operands. This
occurs as the logical operand of if.

Coverity issue: 13218
Fixes: fefed3d1e62c ("enic: new driver")

Signed-off-by: Piotr Azarewicz 
---
 drivers/net/enic/enic.h|2 +-
 drivers/net/enic/enic_ethdev.c |2 +-
 drivers/net/enic/enic_main.c   |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 09f3853..1bea120 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -191,7 +191,7 @@ extern unsigned int enic_cleanup_wq(struct enic *enic, 
struct vnic_wq *wq);
 extern void enic_send_pkt(struct enic *enic, struct vnic_wq *wq,
  struct rte_mbuf *tx_pkt, unsigned short len,
  uint8_t sop, uint8_t eop, uint8_t cq_entry,
- uint16_t ol_flags, uint16_t vlan_tag);
+ uint64_t ol_flags, uint16_t vlan_tag);

 extern void enic_post_wq_index(struct vnic_wq *wq);
 extern int enic_probe(struct enic *enic);
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 6bea940..29c5e1c 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -533,7 +533,7 @@ static uint16_t enicpmd_xmit_pkts(void *tx_queue, struct 
rte_mbuf **tx_pkts,
struct vnic_wq *wq = (struct vnic_wq *)tx_queue;
struct enic *enic = vnic_dev_priv(wq->vdev);
unsigned short vlan_id;
-   unsigned short ol_flags;
+   uint64_t ol_flags;
uint8_t last_seg, eop;
unsigned int host_tx_descs = 0;

diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 60fe765..a78d0ec 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -180,7 +180,7 @@ void enic_post_wq_index(struct vnic_wq *wq)
 void enic_send_pkt(struct enic *enic, struct vnic_wq *wq,
   struct rte_mbuf *tx_pkt, unsigned short len,
   uint8_t sop, uint8_t eop, uint8_t cq_entry,
-  uint16_t ol_flags, uint16_t vlan_tag)
+  uint64_t ol_flags, uint16_t vlan_tag)
 {
struct wq_enet_desc *desc = vnic_wq_next_desc(wq);
uint16_t mss = 0;
-- 
1.7.9.5

[dpdk-dev] [PATCH] qat: change optimization flag for Intel QuickAssist Technology

[Arek Kusztal]

From: Arkadiusz Kusztal 

Changed to -O3 optimization flag in Intel QuickAssist Technology Makefile

Signed-off-by: Arkadiusz Kusztal 
---
 drivers/crypto/qat/Makefile  | 1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 8 +---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/qat/Makefile b/drivers/crypto/qat/Makefile
index 258c2d5..ee72a61 100644
--- a/drivers/crypto/qat/Makefile
+++ b/drivers/crypto/qat/Makefile
@@ -38,6 +38,7 @@ LIBABIVER := 1

 # build flags
 CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -O3

 # external library include paths
 CFLAGS += -I$(SRCDIR)/qat_adf
diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index bcccdf4..a5210d2 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -616,10 +616,12 @@ int qat_alg_aead_session_create_content_desc_auth(struct 
qat_session *cdesc,
 * Write (the length of AAD) into bytes 16-19 of state2
 * in big-endian format. This field is 8 bytes
 */
-   *(uint32_t *)&(hash->sha.state1[
+   uint32_t *aad_len = (uint32_t *)>sha.state1[
ICP_QAT_HW_GALOIS_128_STATE1_SZ +
-   ICP_QAT_HW_GALOIS_H_SZ]) =
-   rte_bswap32(add_auth_data_length);
+   ICP_QAT_HW_GALOIS_H_SZ];
+
+   *aad_len = rte_bswap32(add_auth_data_length);
+
proto = ICP_QAT_FW_LA_GCM_PROTO;
} else if (cdesc->qat_hash_alg == ICP_QAT_HW_AUTH_ALGO_SNOW_3G_UIA2)  {
proto = ICP_QAT_FW_LA_SNOW_3G_PROTO;
-- 
2.1.0

[dpdk-dev] [PATCH 10/16] vhost: export vid as the only interface to applications

[Rich Lane]

On Tue, May 10, 2016 at 9:39 AM, Yuanhan Liu 
wrote:
>
> Rich, would you help try by adding following line there and
> do a test? It would be great if this patch has your Tested-by :)
>
> internal->vid = vid;
>

The problem is new_device has already returned before that point because
find_internal_resource failed.

I suggest adding a cookie parameter to rte_vhost_driver_register and
passing the cookie to each of the vhost_ops. The PMD can use pmd_internals
for the cookie and the whole internal_list can go away.

ps. Could you push git branches somewhere for these larger vhost patch
series? That would make it a lot easier to test than getting patches
individually from patchwork.

[dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a

[Jianbo Liu]

On 10 May 2016 at 00:17, Jerin Jacob  wrote:
> On Mon, May 09, 2016 at 11:22:15PM +0800, Jianbo Liu wrote:
>> On 9 May 2016 at 20:11, Jerin Jacob  
>> wrote:
>> > On Mon, May 09, 2016 at 07:02:36PM +0800, Jianbo Liu wrote:
>> >> On 9 May 2016 at 17:06, Jerin Jacob  
>> >> wrote:
>> >> > On Mon, May 09, 2016 at 07:18:22PM +0530, Hemant Agrawal wrote:
>> >> >> This patch introduces dpaa2 machine target to address difference
>> >> >> in cpu parameter, number of core to 8 and no numa support
>> >> >> w.r.t default armv8-a machine
>> >> >>
>> >> >> Signed-off-by: Hemant Agrawal 
>> >> >> ---
>
> Snip
>
>> >> >> +#
>> >> >> +# Compile Environment Abstraction Layer
>> >> >> +#
>> >> >> +CONFIG_RTE_MAX_LCORE=8
>> >> >> +CONFIG_RTE_MAX_NUMA_NODES=1
>> >> >> +CONFIG_RTE_EAL_IGB_UIO=n
>> >> >
>> >> > I think it makes sense to move this option to generic arm64 config
>> >> > as upstream arm64 kernel does not have support for sysfs based PCI mmap
>> >> > resource file,(/sys/bus/pci/devices/B:D:F/resource[_wc]X) need for
>> >> > CONFIG_RTE_EAL_IGB_UIO to work) and use VFIO for all cases.
>> >> >
>> >> > Any objections?
>> >> >
>> >> Is there any conflict to keep both?
>> >
>> > I would like to avoid the case like below in dpdk.org ml.
>> > http://dpdk.org/ml/archives/dev/2016-January/031313.html
>> >
>> So no conflict to enable both.
>
> IMO, Conflict part comes secondary, It does not even work with upstream 
> kernel.
> Why keep the broken configuration? Two main reasons I think it makes
> sense to disable
> - It is broken, I don't think arm64 kernel developers likes non VFIO approach
I don't think DPDK user is kernel developer in most cases. They maybe
like the traditional way.

> now. So mostly likely it will be broken
> - Trying to avoid out of tree patches wherever is possible as
> distribution folks like to work with upstream version.
Agree. But there is possible that people/company maintain their own kernel tree.

>
>> I'd rather keep as it is for armv8a defconfig, becasue it's the base,
>> any change may affect existing user.
> IMO, It makes sense to disable at armv8a defconfig otherwise all armv8
> variants need add CONFIG_RTE_EAL_IGB_UIO=n in all the configs and its
> arch specific issue.
We don't have to do that.
You didn't explictly disable this config in your current
defconfig_arm64-thunderx-linuxapp-gcc, but you know which module to
bind.

[dpdk-dev] [PATCH] mbuf: add helpers to prefetch mbuf

[Olivier MATZ]

Hi,

On 05/10/2016 12:02 AM, Wiles, Keith wrote:
>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
>> index 529debb..e3ee0b3 100644
>> --- a/lib/librte_mbuf/rte_mbuf.h
>> +++ b/lib/librte_mbuf/rte_mbuf.h
>> @@ -842,6 +842,44 @@ struct rte_mbuf {
>>  uint16_t timesync;
>> } __rte_cache_aligned;
>>
>> +/**
>> + * Prefetch the first part of the mbuf
>> + *
>> + * The first 64 bytes of the mbuf corresponds to fields that are used early
>> + * in the receive path. If the cache line of the architecture is higher than
>> + * 64B, the second part will also be prefetched.
>> + *
>> + * @param m
>> + *   The pointer to the mbuf.
>> + */
>> +static inline void
>> +rte_mbuf_prefetch_part0(struct rte_mbuf *m)
>> +{
>> +rte_prefetch0(>cacheline0);
>> +}
>> +
>> +/**
>> + * Prefetch the second part of the mbuf
>> + *
>> + * The next 64 bytes of the mbuf corresponds to fields that are used in the
>> + * transmit path. If the cache line of the architecture is higher than 64B,
>> + * this function does nothing as it is expected that the full mbuf is
>> + * already in cache.
>> + *
>> + * @param m
>> + *   The pointer to the mbuf.
>> + */
>> +static inline void
>> +rte_mbuf_prefetch_part1(struct rte_mbuf *m)
>> +{
>> +#if RTE_CACHE_LINE_SIZE == 64
>> +rte_prefetch0(>cacheline1);
>> +#else
>> +RTE_SET_USED(m);
>> +#endif
>> +}
>
> I am not super happy with the names here, but I understand that 
> rte_mbuf_prefetch_cacheline0() is a bit long. I could live with them being 
> longer if that makes more sense and adds to readability.

Naming these functions rte_mbuf_prefetch_cacheline0() and
rte_mbuf_prefetch_cacheline1() was my first intention, but
as you said, it's long, and it's also not accurate because
here we don't really deal with cache lines, and that's why
I preffered to use "part" instead.

I'm not opposed to name them part1/part2 instead of part0/part1
as Thomas suggested. Another option would be:
   - rte_mbuf_prefetch_rx_part(m)
   - rte_mbuf_prefetch_tx_part(m)

The objective is to avoid the drivers to deal with the two possible
cache line sizes with #ifdefs. So I don't think the function should
be called something_cacheline.

As a side note, I'm not really satisfied by the RTE_CACHE_LINE_MIN_SIZE
and __rte_cache_min_aligned macros and I think it would be clearer
to explicitly align to 64. If other people agree, I can submit a patch
for this too.

Any comment?

> Another idea is to have only one function for both:
>
> enum { MBUF_CACHELINE0 = 0, MBUF_CACHELINE1, MBUF_CACHELINES };   // 
> Optional enum if you want
>
> static inline void
> rte_mbuf_prefetch(struct rte_mbuf *m, unsigned cacheline) // Make sure we 
> add a comment about the constant value
> {
>   if (cacheline == MBUF_CACHELINE0)
>   rte_prefetch0(>cacheline0);
>   else if (cacheline == MBUF_CACHELINE1)
>   rte_prefetch0(>cacheline1);
>   else {
>   rte_prefetch0(>cacheline0);
>   rte_prefetch0(>cacheline1);
>   }
> }
>
> I believe if you use constant value in the call for the cacheline variable 
> then the extra code should be optimized out. If not then what about a macro 
> instead.
>
> #define rte_mbuf_prefetch(m, c)   \
>   do { \
>   if ((c) == MBUF_CACHELINE0) \
>   rte_prefetch0(&(m)->cacheline0); \
>   else if ((c) == MBUF_CACHELINE1) \
>   rte_prefetch0(&(m)->cacheline1); \
>   else { \
>   rte_prefetch0(&(m)->cacheline0); \
>   rte_prefetch0(&(m)->cacheline1); \
>   } \
>   } while((0))
>
> Call like this:
>   rte_mbuf_prefetch(m, 0);// For cacheline 0
>   rte_mbuf_prefetch(m, 1);// For cacheline 1
>   rte_mbuf_prefetch(m, 2);// For cacheline 0 and 1

In my opinion, the implementation and usage is simpler with 2
separate functions. What would be the advantage of this?

> We could have another routine:
>   rte_mbuf_prefetch_data(m, 0);   // Prefetch the first cacheline of the 
> packet data.

Well, here, I think there is no need to replace rte_prefetch0(m->data).

It's useful for mbuf structure prefetch because many drivers want
to prefetch the rx part first, then the tx part. For data, the same
function can be used whatever the cache line size.

Regards,
Olivier

[dpdk-dev] [RFC PATCH v2 1/3] rte: change xstats to use integer keys

[Remy Horton]

On 09/05/2016 14:59, David Harton (dharton) wrote:
[..]
>>   }
>>
>> -
>
> Not sure how the community feels about white-space only changes.
> Just mentioning in case some folks get excited about it.  One here and a few 
> below.

I doubt it'll be showstopper. In any case hoping to get a v3 out that 
converts the 4 other drivers that have xstats.

..Remy

[dpdk-dev] [PATCH] qat: change optimization flag for Intel QuickAssist Technology

[Jain, Deepak K]

Acked-by: Deepak Kumar JAIN 

-Original Message-
From: Kusztal, ArkadiuszX 
Sent: Tuesday, May 10, 2016 10:24 AM
To: dev at dpdk.org
Cc: Trahe, Fiona ; Griffin, John ; Jain, Deepak K ; Kusztal, ArkadiuszX 

Subject: [PATCH] qat: change optimization flag for Intel QuickAssist Technology

From: Arkadiusz Kusztal 

Changed to -O3 optimization flag in Intel QuickAssist Technology Makefile

Signed-off-by: Arkadiusz Kusztal 
---
 drivers/crypto/qat/Makefile  | 1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 8 +---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/qat/Makefile b/drivers/crypto/qat/Makefile index 
258c2d5..ee72a61 100644
--- a/drivers/crypto/qat/Makefile
+++ b/drivers/crypto/qat/Makefile
@@ -38,6 +38,7 @@ LIBABIVER := 1

 # build flags
 CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -O3

 # external library include paths
 CFLAGS += -I$(SRCDIR)/qat_adf
diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index bcccdf4..a5210d2 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -616,10 +616,12 @@ int qat_alg_aead_session_create_content_desc_auth(struct 
qat_session *cdesc,
 * Write (the length of AAD) into bytes 16-19 of state2
 * in big-endian format. This field is 8 bytes
 */
-   *(uint32_t *)&(hash->sha.state1[
+   uint32_t *aad_len = (uint32_t *)>sha.state1[
ICP_QAT_HW_GALOIS_128_STATE1_SZ +
-   ICP_QAT_HW_GALOIS_H_SZ]) =
-   rte_bswap32(add_auth_data_length);
+   ICP_QAT_HW_GALOIS_H_SZ];
+
+   *aad_len = rte_bswap32(add_auth_data_length);
+
proto = ICP_QAT_FW_LA_GCM_PROTO;
} else if (cdesc->qat_hash_alg == ICP_QAT_HW_AUTH_ALGO_SNOW_3G_UIA2)  {
proto = ICP_QAT_FW_LA_SNOW_3G_PROTO;
--
2.1.0

[dpdk-dev] [PATCH v3] eal: make hugetlb initialization more robust

[Sergio Gonzalez Monroy]

Hi Jianfeng,

On 09/05/2016 11:48, Jianfeng Tan wrote:

>   /* find physical addresses and sockets for each hugepage */
> @@ -1172,8 +1255,9 @@ rte_eal_hugepage_init(void)
>   hp_offset += new_pages_count[i];
>   #else
>   /* remap all hugepages */
> - if (map_all_hugepages(_hp[hp_offset], hpi, 0) < 0){
> - RTE_LOG(DEBUG, EAL, "Failed to remap %u MB pages\n",
> + if ((uint32_t)map_all_hugepages(_hp[hp_offset], hpi, 0) !=
> + hpi->num_pages[0]) {

It probably makes more sense to have map_all_hugepages return uint32_t 
instead.

Sergio

[dpdk-dev] [PATCH v3] examples/qos_sched: fix bad bit shift operation

[Dumitrescu, Cristian]

> -Original Message-
> From: Mrozowicz, SlawomirX
> Sent: Tuesday, May 10, 2016 10:40 AM
> To: Dumitrescu, Cristian ; Jastrzebski,
> MichalX K ; Zhang, Roy Fan
> ; Singh, Jasvinder 
> Cc: dev at dpdk.org
> Subject: RE: [PATCH v3] examples/qos_sched: fix bad bit shift operation
> 
> 
> >-Original Message-
> >From: Dumitrescu, Cristian
> >Sent: Thursday, April 28, 2016 1:16 PM
> >To: Jastrzebski, MichalX K ; Zhang, Roy
> Fan
> >; Singh, Jasvinder 
> >Cc: dev at dpdk.org; Mrozowicz, SlawomirX
> 
> >Subject: RE: [PATCH v3] examples/qos_sched: fix bad bit shift operation
> >
> >
> >
> >> -Original Message-
> >> From: Jastrzebski, MichalX K
> >> Sent: Thursday, April 21, 2016 2:08 PM
> >> To: Dumitrescu, Cristian ; Zhang, Roy
> >> Fan ; Singh, Jasvinder
> >> 
> >> Cc: dev at dpdk.org; Mrozowicz, SlawomirX
> >
> >> Subject: [PATCH v3] examples/qos_sched: fix bad bit shift operation
> >>
> >> From: Slawomir Mrozowicz 
> >>
> >> Fix issue reported by Coverity.
> >>
> >> Coverity ID 30690: Bad bit shift operation
> >> large_shift: In expression 1ULL << i, left shifting by more than 63
> >> bits has undefined behavior. The shift amount, i, is as much as 127.
> >>
> >> Fixes: de3cfa2c9823 ("sched: initial import")
> >>
> >> Signed-off-by: Slawomir Mrozowicz 
> >> ---
> >>  examples/qos_sched/args.c | 84 +--
> ---
> >-
> >> 
> >>  1 file changed, 52 insertions(+), 32 deletions(-)
> >>
> >> diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
> >> index 3e7fd08..cd077ba 100644
> >> --- a/examples/qos_sched/args.c
> >> +++ b/examples/qos_sched/args.c
> >> @@ -53,7 +53,7 @@
> >>
> >>  static uint32_t app_master_core = 1;
> >>  static uint32_t app_numa_mask;
> >> -static uint64_t app_used_core_mask = 0;
> >> +static int app_used_core_mask[RTE_MAX_LCORE];
> 
> Changed type of the app_used_core_mask variable to store up to
> RTE_MAX_LCORE cores information.
> 
> >>  static uint64_t app_used_port_mask = 0;  static uint64_t
> >> app_used_rx_port_mask = 0;  static uint64_t app_used_tx_port_mask =
> 0;
> >> @@ -115,22 +115,23 @@ static inline int str_is(const char *str, const char
> >*is)
> >>return strcmp(str, is) == 0;
> >>  }
> >>
> >> -/* returns core mask used by DPDK */
> >> -static uint64_t
> >> -app_eal_core_mask(void)
> >> +/* compare used core with eal configuration,
> >> +  returns:
> >> +  1 if equal
> >> +  0 if differ */
> >> +static int
> >> +app_eal_core_check(void)
> >>  {
> >> -  uint32_t i;
> >> -  uint64_t cm = 0;
> >> +  uint16_t i;
> >> +  int ret = 1;
> >>struct rte_config *cfg = rte_eal_get_configuration();
> >>
> >> -  for (i = 0; i < RTE_MAX_LCORE; i++) {
> >> -  if (cfg->lcore_role[i] == ROLE_RTE)
> >> -  cm |= (1ULL << i);
> >> +  for (i = 0; i < RTE_MAX_LCORE && ret; i++) {
> >> +  if ((cfg->lcore_role[i] == ROLE_RTE) !=
> >> app_used_core_mask[i])
> >> +  ret = 0;
> >>}
> >>
> >> -  cm |= (1ULL << cfg->master_lcore);
> >> -
> >> -  return cm;
> >> +  return ret;
> >>  }
> >>
> 
> Added tool function app_eal_core_check() to check compatibility used cores
> with information stored in configuration file. The function is used below.
> Removed not used function app_eal_core_mask()
> 
> >>
> >> @@ -292,14 +293,9 @@ app_parse_flow_conf(const char *conf_str)
> >>app_used_tx_port_mask |= mask;
> >>app_used_port_mask |= mask;
> >>
> >> -  mask = 1lu << pconf->rx_core;
> >> -  app_used_core_mask |= mask;
> >> -
> >> -  mask = 1lu << pconf->wt_core;
> >> -  app_used_core_mask |= mask;
> >> -
> >> -  mask = 1lu << pconf->tx_core;
> >> -  app_used_core_mask |= mask;
> >> +  app_used_core_mask[pconf->rx_core] = 1;
> >> +  app_used_core_mask[pconf->wt_core] = 1;
> >> +  app_used_core_mask[pconf->tx_core] = 1;
> >>
> 
> Change method of set the mask on each used core according to change mask
> type.
> 
> >>nb_pfc++;
> >>
> >> @@ -335,7 +331,7 @@ app_parse_args(int argc, char **argv)
> >>int option_index;
> >>const char *optname;
> >>char *prgname = argv[0];
> >> -  uint32_t i, nb_lcores;
> >> +  uint16_t i, j, k, nb_lcores;
> >>
> >>static struct option lgopts[] = {
> >>{ "pfc", 1, 0, 0 },
> >> @@ -349,6 +345,9 @@ app_parse_args(int argc, char **argv)
> >>{ NULL,  0, 0, 0 }
> >>};
> >>
> >> +  for (i = 0; i < RTE_MAX_LCORE; i++)
> >> +  app_used_core_mask[i] = 0;
> >> +
> 
> Set initial value of the mask.
> 
> >>/* initialize EAL first */
> >>ret = rte_eal_init(argc, argv);
> >>if (ret < 0)
> >> @@ -436,19 +435,40 @@ app_parse_args(int argc, char **argv)
> >>}
> >>
> >>/* check master core index validity */
> >> -  for(i = 0; i <= app_master_core; i++) {
> >> -  if (app_used_core_mask & (1u << app_master_core)) {
> >> -  RTE_LOG(ERR, APP, "Master core index is not
> >> configured properly\n");
> >> -  app_usage(prgname);
> >> -  

[dpdk-dev] [PATCH v3] examples/qos_sched: fix bad bit shift operation

[Mrozowicz, SlawomirX]

>-Original Message-
>From: Dumitrescu, Cristian
>Sent: Thursday, April 28, 2016 1:16 PM
>To: Jastrzebski, MichalX K ; Zhang, Roy Fan
>; Singh, Jasvinder 
>Cc: dev at dpdk.org; Mrozowicz, SlawomirX 
>Subject: RE: [PATCH v3] examples/qos_sched: fix bad bit shift operation
>
>
>
>> -Original Message-
>> From: Jastrzebski, MichalX K
>> Sent: Thursday, April 21, 2016 2:08 PM
>> To: Dumitrescu, Cristian ; Zhang, Roy
>> Fan ; Singh, Jasvinder
>> 
>> Cc: dev at dpdk.org; Mrozowicz, SlawomirX
>
>> Subject: [PATCH v3] examples/qos_sched: fix bad bit shift operation
>>
>> From: Slawomir Mrozowicz 
>>
>> Fix issue reported by Coverity.
>>
>> Coverity ID 30690: Bad bit shift operation
>> large_shift: In expression 1ULL << i, left shifting by more than 63
>> bits has undefined behavior. The shift amount, i, is as much as 127.
>>
>> Fixes: de3cfa2c9823 ("sched: initial import")
>>
>> Signed-off-by: Slawomir Mrozowicz 
>> ---
>>  examples/qos_sched/args.c | 84 +-
>-
>> 
>>  1 file changed, 52 insertions(+), 32 deletions(-)
>>
>> diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
>> index 3e7fd08..cd077ba 100644
>> --- a/examples/qos_sched/args.c
>> +++ b/examples/qos_sched/args.c
>> @@ -53,7 +53,7 @@
>>
>>  static uint32_t app_master_core = 1;
>>  static uint32_t app_numa_mask;
>> -static uint64_t app_used_core_mask = 0;
>> +static int app_used_core_mask[RTE_MAX_LCORE];

Changed type of the app_used_core_mask variable to store up to RTE_MAX_LCORE 
cores information.

>>  static uint64_t app_used_port_mask = 0;  static uint64_t
>> app_used_rx_port_mask = 0;  static uint64_t app_used_tx_port_mask = 0;
>> @@ -115,22 +115,23 @@ static inline int str_is(const char *str, const char
>*is)
>>  return strcmp(str, is) == 0;
>>  }
>>
>> -/* returns core mask used by DPDK */
>> -static uint64_t
>> -app_eal_core_mask(void)
>> +/* compare used core with eal configuration,
>> +returns:
>> +1 if equal
>> +0 if differ */
>> +static int
>> +app_eal_core_check(void)
>>  {
>> -uint32_t i;
>> -uint64_t cm = 0;
>> +uint16_t i;
>> +int ret = 1;
>>  struct rte_config *cfg = rte_eal_get_configuration();
>>
>> -for (i = 0; i < RTE_MAX_LCORE; i++) {
>> -if (cfg->lcore_role[i] == ROLE_RTE)
>> -cm |= (1ULL << i);
>> +for (i = 0; i < RTE_MAX_LCORE && ret; i++) {
>> +if ((cfg->lcore_role[i] == ROLE_RTE) !=
>> app_used_core_mask[i])
>> +ret = 0;
>>  }
>>
>> -cm |= (1ULL << cfg->master_lcore);
>> -
>> -return cm;
>> +return ret;
>>  }
>>

Added tool function app_eal_core_check() to check compatibility used cores with 
information stored in configuration file. The function is used below.
Removed not used function app_eal_core_mask()

>>
>> @@ -292,14 +293,9 @@ app_parse_flow_conf(const char *conf_str)
>>  app_used_tx_port_mask |= mask;
>>  app_used_port_mask |= mask;
>>
>> -mask = 1lu << pconf->rx_core;
>> -app_used_core_mask |= mask;
>> -
>> -mask = 1lu << pconf->wt_core;
>> -app_used_core_mask |= mask;
>> -
>> -mask = 1lu << pconf->tx_core;
>> -app_used_core_mask |= mask;
>> +app_used_core_mask[pconf->rx_core] = 1;
>> +app_used_core_mask[pconf->wt_core] = 1;
>> +app_used_core_mask[pconf->tx_core] = 1;
>>

Change method of set the mask on each used core according to change mask type.

>>  nb_pfc++;
>>
>> @@ -335,7 +331,7 @@ app_parse_args(int argc, char **argv)
>>  int option_index;
>>  const char *optname;
>>  char *prgname = argv[0];
>> -uint32_t i, nb_lcores;
>> +uint16_t i, j, k, nb_lcores;
>>
>>  static struct option lgopts[] = {
>>  { "pfc", 1, 0, 0 },
>> @@ -349,6 +345,9 @@ app_parse_args(int argc, char **argv)
>>  { NULL,  0, 0, 0 }
>>  };
>>
>> +for (i = 0; i < RTE_MAX_LCORE; i++)
>> +app_used_core_mask[i] = 0;
>> +

Set initial value of the mask.

>>  /* initialize EAL first */
>>  ret = rte_eal_init(argc, argv);
>>  if (ret < 0)
>> @@ -436,19 +435,40 @@ app_parse_args(int argc, char **argv)
>>  }
>>
>>  /* check master core index validity */
>> -for(i = 0; i <= app_master_core; i++) {
>> -if (app_used_core_mask & (1u << app_master_core)) {
>> -RTE_LOG(ERR, APP, "Master core index is not
>> configured properly\n");
>> -app_usage(prgname);
>> -return -1;
>> -}
>> +if (app_used_core_mask[app_master_core] == 1) {
>> +RTE_LOG(ERR, APP,
>> +"Master core index is not configured properly\n");
>> +app_usage(prgname);
>> +return -1;
>>  }

Changed method of checking if mask is present on master core.

>> -app_used_core_mask |= 1u << app_master_core;
>> +app_used_core_mask[app_master_core] = 1;
>> +

Changed method of set master core in mask.

>> +   

[dpdk-dev] [PATCH 10/16] vhost: export vid as the only interface to applications

[Yuanhan Liu]

On Tue, May 10, 2016 at 09:17:23AM -0700, Rich Lane wrote:
> On Mon, May 2, 2016 at 3:25 PM, Yuanhan Liu 
> wrote:
> 
> With all the previous prepare works, we are just one step away from
> the final ABI refactoring. That is, to change current API to let them
> stick to vid instead of the old virtio_net dev.
> 
> 
> This patch removes the only assignment to internal->vid in the PMD. It's
> initialized to zero, so only the first vhost connection will work.

I assume you meant to following diff:

-   if (dev == NULL) {
-   RTE_LOG(INFO, PMD, "Invalid argument\n");
-   return -1;
-   }
-
-   list = find_internal_resource(dev->vid);
+   list = find_internal_resource(vid);
if (list == NULL) {
-   RTE_LOG(INFO, PMD, "Invalid vid %d\n", dev->vid);
+   RTE_LOG(INFO, PMD, "Invalid vid %d\n", vid);
return -1;
}

eth_dev = list->eth_dev;
internal = eth_dev->data->dev_private;
-   internal->vid = dev->vid;

Then yes, I have no idea why I did that; it's a careless and
hard-to-catch issue. So, thanks a lot for catching it!

Rich, would you help try by adding following line there and
do a test? It would be great if this patch has your Tested-by :)

internal->vid = vid;

Thanks.

--yliu

[dpdk-dev] [PATCH 9/9] doc: update ipsec sample guide

[Mcnamara, John]

Hi,

Thanks for the updated docs and clear examples. Some minor comments below.


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez
> Monroy
> Sent: Friday, May 6, 2016 5:32 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 9/9] doc: update ipsec sample guide
> 
> Signed-off-by: Sergio Gonzalez Monroy 
> ---
>  doc/guides/sample_app_ug/ipsec_secgw.rst | 583 --
> -
>  1 file changed, 381 insertions(+), 202 deletions(-)



> +#. [Optional] Build the application for debugging:
> +   This option adds some extra flags, disables compiler optimizations and
> +   is verbose.
> +
> +   .. code-block:: console
> +
> +   make DEBUG=1
> +

For simple console code-blocks like this you can just use ::. It defaults
to "console".

> +
> +.. _figure_ipsec_endpoints:
> +
> +.. figure:: img/ipsec_endpoints.svg
> +
> +   IPSec Inbound/Outbound traffic


The patch is missing the file:
doc/guides/sample_app_ug/img/ipsec_endpoints.svg


> ++---++
> +| **Dst**   | **SA idx** |
> +|   ||
> ++---++
> +| 192.168.105.0/24  | 5  |
> +|   ||



You should add the table directive before these tables so that a
caption can be applied:

   .. _table_ipsec_endpoint_outbound_sp:

   .. table:: Endpoint 0 Outbound Security Policies

  +---++
  | **Dst**   | **SA idx** |
  |   ||
  +---++
  | 192.168.105.0/24  | 5  |
  |   ||


John

[dpdk-dev] [PATCH 10/16] vhost: export vid as the only interface to applications

[Rich Lane]

On Mon, May 2, 2016 at 3:25 PM, Yuanhan Liu 
wrote:

> With all the previous prepare works, we are just one step away from
> the final ABI refactoring. That is, to change current API to let them
> stick to vid instead of the old virtio_net dev.
>

This patch removes the only assignment to internal->vid in the PMD. It's
initialized to zero, so only the first vhost connection will work.

[dpdk-dev] rte_malloc

[Sergio Gonzalez Monroy]

Hi,

On 09/05/2016 18:32, Mahdi Moradmand Badie wrote:
> Hello All,
>
> I had a problem regarding use the rte_malloc.
> I want to know if I want to use rte_malloc instead of malloc just mak
> change like this
> struct lcore_params *p = malloc
> 
> (sizeof(*p)); ==>
> struct lcore_params *p = rte_malloc
> (NULL,
> sizeof(*p), 0);
> is enough ?

Yes, malloc(sizeof(*p)) has an equivalent behavior to rte_malloc(NULL, 
sizeof(*p), 0)
in the context of a DPDK application.

> Because I have problem and Segmentation fault (core dumped) ??

Could you provide more details of how to reproduce or could you try to
reproduce your problem using a very simple example like 
examples/helloworld ?

Sergio

> Thanks in advance,
>
>

[dpdk-dev] [PATCH v3] eal: make hugetlb initialization more robust

[Tan, Jianfeng]

Hi Sergio,

> -Original Message-
> From: Gonzalez Monroy, Sergio
> Sent: Tuesday, May 10, 2016 4:55 PM
> To: Tan, Jianfeng; dev at dpdk.org
> Cc: david.marchand at 6wind.com; nhorman at tuxdriver.com
> Subject: Re: [PATCH v3] eal: make hugetlb initialization more robust
> 
> 
> Hi Jianfeng,
> 
> On 09/05/2016 11:48, Jianfeng Tan wrote:
> 
> > /* find physical addresses and sockets for each hugepage */
> > @@ -1172,8 +1255,9 @@ rte_eal_hugepage_init(void)
> > hp_offset += new_pages_count[i];
> >   #else
> > /* remap all hugepages */
> > -   if (map_all_hugepages(_hp[hp_offset], hpi, 0) < 0){
> > -   RTE_LOG(DEBUG, EAL, "Failed to remap %u MB
> pages\n",
> > +   if ((uint32_t)map_all_hugepages(_hp[hp_offset], hpi,
> 0) !=
> > +   hpi->num_pages[0]) {
> 
> It probably makes more sense to have map_all_hugepages return uint32_t
> instead.

Yes, I agree. I was wrongly expecting there's a freebsd version 
map_all_hugepages with the same function type.

I'll fix this in next version.

Thanks,
Jianfeng

> 
> Sergio

[dpdk-dev] [PATCH 3/6] vhost: add reconnect ability

[Xie, Huawei]

On 5/10/2016 4:42 PM, Michael S. Tsirkin wrote:
> On Tue, May 10, 2016 at 08:07:00AM +, Xie, Huawei wrote:
>> On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote:
>>> On Tue, May 10, 2016 at 07:24:10AM +, Xie, Huawei wrote:
 On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
> On Mon, May 09, 2016 at 04:47:02PM +, Xie, Huawei wrote:
>> On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
>>> +static void *
>>> +vhost_user_client_reconnect(void *arg)
>>> +{
>>> +   struct reconnect_info *reconn = arg;
>>> +   int ret;
>>> +
>>> +   RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");
>>> +   while (1) {
>>> +   ret = connect(reconn->fd, (struct sockaddr 
>>> *)>un,
>>> +   sizeof(reconn->un));
>>> +   if (ret == 0)
>>> +   break;
>>> +   sleep(1);
>>> +   }
>>> +
>>> +   vhost_user_add_connection(reconn->fd, reconn->vsocket);
>>> +   free(reconn);
>>> +
>>> +   return NULL;
>>> +}
>>> +
>> We could create hundreds of vhost-user ports in OVS. Wihout connections
>> with QEMU established, those ports are just inactive. This works fine in
>> server mode.
>> With client modes, do we need to create hundreds of vhost threads? This
>> would be too interruptible.
>> How about we create only one thread and do the reconnections for all the
>> unconnected socket?
> Yes, good point and good suggestion. Will do it in v2.
 Hi Michael:
 This reminds me another irrelevant issue.
 In OVS, currently for each vhost port, we create an unix domain socket,
 and QEMU vhost proxy connects to this socket, and we use this to
 identify the connection. This works fine but is our workaround,
 otherwise we have no way to identify the connection.
 Do you think if this is an issue?
>> Let us say vhost creates one unix domain socket, with path as "sockpath",
>> and two virtio ports in two VMS both connect to the same socket with the
>> following command line
>> -chardev socket,id=char0,path=sockpath
>> How could vhost identify the connection?
> getpeername(2)?

getpeer name returns host/port? then it isn't useful.

The typical scenario in my mind is:
We create a OVS port with the name "port1", and when we receive an
virtio connection with ID "port1", we attach this virtio interface to
the OVS port "port1".


>
>
>> Workarounds:
>> vhost creates two unix domain sockets, with path as "sockpath1" and
>> "sockpath2" respectively,
>> and the virtio ports in two VMS respectively connect to "sockpath1" and
>> "sockpath2".
>>
>> If we have some name string from QEMU over vhost, as you mentioned, we
>> could create only one socket with path "sockpath".
>> User ensure that the names are unique, just as how they do with multiple
>> sockets.
>>
> Seems rather fragile.

>From the scenario above, it is enough. That is also how it works today
in DPDK OVS implementation with multiple sockets.
Any other idea?

>
>>> I'm sorry, I have trouble understanding what you wrote above.
>>> What is the issue you are trying to work around?
>>>
 Do we have plan to support identification in VHOST_USER_MESSAGE? With
 the identification, if vhost as server, we only need to create one
 socket which receives multiple connections, and use the ID in the
 message to identify the connection.

 /huawei
>>> Sending e.g. -name string from qemu over vhost might be useful
>>> for debugging, but I'm not sure it's a good idea to
>>> rely on it being unique.
>>>
> Thanks.
>
>   --yliu
>

[dpdk-dev] [PATCH v1] igu_uio: fix IOMMU domain issue

[Stephen Hemminger]

On Tue, 10 May 2016 19:21:41 +0800
Zhe Tao  wrote:

> Problem:
> The following  operations will cause the igb_uio based DPDK
> operation failed.
> --Any device assignment through the kvm_assign_device interface,
> this can be the pci-assign method in QEMU
> --VFIO group attachment operation(attach to the container)
> this can happens in  vfio-pci assignment in QEMU


If you have an IOMMU why not use VFIO instead, it is better.

[dpdk-dev] [PATCH 4/6] vhost: workaround stale vring base

[Xie, Huawei]

On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
> When DPDK app crashes (or quits, or gets killed), and when QEMU supports
> reconnecting (patches have been sent, not merged yet), a restart of DPDK
> app would get stale vring base from QEMU. That would break the kernel
> virtio net completely, making it non-work any more, unless a driver reset
> is done.

s/DPDK app/DPDK vhost/

DPDK app is confusing

>
> So, instead of getting the stale vring base from QEMU, Huawei suggested
> we could get a proper one from used->idx.
>
> Cc: "Michael S. Tsirkin" 
> Suggested-by: "Xie, Huawei" 
> Signed-off-by: Yuanhan Liu 

Acked-by: Huawei Xie 

[dpdk-dev] [PATCH 3/6] vhost: add reconnect ability

[Xie, Huawei]

On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote:
> On Tue, May 10, 2016 at 07:24:10AM +, Xie, Huawei wrote:
>> On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
>>> On Mon, May 09, 2016 at 04:47:02PM +, Xie, Huawei wrote:
 On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
> +static void *
> +vhost_user_client_reconnect(void *arg)
> +{
> + struct reconnect_info *reconn = arg;
> + int ret;
> +
> + RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");
> + while (1) {
> + ret = connect(reconn->fd, (struct sockaddr *)>un,
> + sizeof(reconn->un));
> + if (ret == 0)
> + break;
> + sleep(1);
> + }
> +
> + vhost_user_add_connection(reconn->fd, reconn->vsocket);
> + free(reconn);
> +
> + return NULL;
> +}
> +
 We could create hundreds of vhost-user ports in OVS. Wihout connections
 with QEMU established, those ports are just inactive. This works fine in
 server mode.
 With client modes, do we need to create hundreds of vhost threads? This
 would be too interruptible.
 How about we create only one thread and do the reconnections for all the
 unconnected socket?
>>> Yes, good point and good suggestion. Will do it in v2.
>> Hi Michael:
>> This reminds me another irrelevant issue.
>> In OVS, currently for each vhost port, we create an unix domain socket,
>> and QEMU vhost proxy connects to this socket, and we use this to
>> identify the connection. This works fine but is our workaround,
>> otherwise we have no way to identify the connection.
>> Do you think if this is an issue?

Let us say vhost creates one unix domain socket, with path as "sockpath",
and two virtio ports in two VMS both connect to the same socket with the
following command line
-chardev socket,id=char0,path=sockpath
How could vhost identify the connection?


Workarounds:
vhost creates two unix domain sockets, with path as "sockpath1" and
"sockpath2" respectively,
and the virtio ports in two VMS respectively connect to "sockpath1" and
"sockpath2".

If we have some name string from QEMU over vhost, as you mentioned, we
could create only one socket with path "sockpath".
User ensure that the names are unique, just as how they do with multiple
sockets.


> I'm sorry, I have trouble understanding what you wrote above.
> What is the issue you are trying to work around?
>
>> Do we have plan to support identification in VHOST_USER_MESSAGE? With
>> the identification, if vhost as server, we only need to create one
>> socket which receives multiple connections, and use the ID in the
>> message to identify the connection.
>>
>> /huawei
> Sending e.g. -name string from qemu over vhost might be useful
> for debugging, but I'm not sure it's a good idea to
> rely on it being unique.
>
>>> Thanks.
>>>
>>> --yliu
>>>

[dpdk-dev] DPDK Community Call - 16.04 Retrospective - Wednesday May 11th

[Glynn, Michael J]

Hi all
Just a reminder about the 16.04 Retrospective Call tomorrow. All the call-in 
details are provided in Tim's email below 

Chat then!
Mike 


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of O'Driscoll, Tim
Sent: Friday, April 29, 2016 3:09 PM
To: dev at dpdk.org
Subject: [dpdk-dev] DPDK Community Call - 16.04 Retrospective - Wednesday May 
11th

At the end of each release, we typically hold a retrospective within our 
development team to discuss what went well, what could be improved etc. For 
16.04, we thought it would be a good idea to try doing this with the open 
source community, so that everybody involved in the project can provide their 
input and we can discuss any suggested improvements collectively.

Mike Glynn, who's our Program Manager for DPDK, will facilitate the discussion. 
John McNamara has gathered some stats on things like how many revisions patches 
typically went through etc., which we'll present to help initiate the 
discussion, but the meeting should mostly be an open discussion where people 
should feel free to suggest any improvements they think we should make.

If the approach is successful we can repeat it for future releases.


When:
London (United Kingdom - England)Wednesday, May 11, 2016 at 4PMBST  
UTC+1 hour 
San Jose (USA - California)  Wednesday, May 11, 2016 at 8AMPDT  
UTC-7 hours
Boston (USA - Massachusetts) Wednesday, May 11, 2016 at 11AM   EDT  
UTC-4 hours
Paris (France - ?le-de-France)   Wednesday, May 11, 2016 at 5PMCEST 
UTC+2 hours
New Delhi (India - Delhi)Wednesday, May 11, 2016 at 8:30PM IST  
UTC+5:30 hours 
Shanghai (China - Shanghai Municipality) Wednesday, May 11, 2016 at 11PM   CST  
UTC+8 hours
Tokyo (Japan)Midnight between Wednesday, May 11 and 
Thursday, May 12 JST  UTC+9 hours


GoToMeeting details:
Please join my meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/634498213

You can also dial in using your phone. 
United States : +1 (312) 757-3117

Access Code: 634-498-213

More phone numbers
Australia : +61 2 8355 1039
Austria : +43 7 2088 1033
Belgium : +32 (0) 28 93 7001
Canada : +1 (647) 497-9379
Denmark : +45 69 91 89 33
Finland : +358 (0) 942 41 5770
France : +33 (0) 170 950 585
Germany : +49 (0) 692 5736 7303
Ireland : +353 (0) 19 030 050
Italy : +39 0 693 38 75 50
Netherlands : +31 (0) 208 080 208
New Zealand : +64 9 925 0481
Norway : +47 21 54 82 21
Spain : +34 911 82 9890
Sweden : +46 (0) 853 527 817
Switzerland : +41 (0) 435 0167 65
United Kingdom : +44 (0) 330 221 0099

[dpdk-dev] [PATCH 3/6] vhost: add reconnect ability

[Xie, Huawei]

On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
> On Mon, May 09, 2016 at 04:47:02PM +, Xie, Huawei wrote:
>> On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
>>> +static void *
>>> +vhost_user_client_reconnect(void *arg)
>>> +{
>>> +   struct reconnect_info *reconn = arg;
>>> +   int ret;
>>> +
>>> +   RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");
>>> +   while (1) {
>>> +   ret = connect(reconn->fd, (struct sockaddr *)>un,
>>> +   sizeof(reconn->un));
>>> +   if (ret == 0)
>>> +   break;
>>> +   sleep(1);
>>> +   }
>>> +
>>> +   vhost_user_add_connection(reconn->fd, reconn->vsocket);
>>> +   free(reconn);
>>> +
>>> +   return NULL;
>>> +}
>>> +
>> We could create hundreds of vhost-user ports in OVS. Wihout connections
>> with QEMU established, those ports are just inactive. This works fine in
>> server mode.
>> With client modes, do we need to create hundreds of vhost threads? This
>> would be too interruptible.
>> How about we create only one thread and do the reconnections for all the
>> unconnected socket?
> Yes, good point and good suggestion. Will do it in v2.

Hi Michael:
This reminds me another irrelevant issue.
In OVS, currently for each vhost port, we create an unix domain socket,
and QEMU vhost proxy connects to this socket, and we use this to
identify the connection. This works fine but is our workaround,
otherwise we have no way to identify the connection.
Do you think if this is an issue?
Do we have plan to support identification in VHOST_USER_MESSAGE? With
the identification, if vhost as server, we only need to create one
socket which receives multiple connections, and use the ID in the
message to identify the connection.

/huawei


>
> Thanks.
>
>   --yliu
>

[dpdk-dev] [PATCH 0/6] vhost: add vhost-user client mode and reconnect ability

[Xu, Qian Q]

Do we need patch qemu for the reconnect case?  

Thanks
Qian


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yuanhan Liu
Sent: Saturday, May 07, 2016 2:40 PM
To: dev at dpdk.org
Cc: Xie, Huawei; Yuanhan Liu
Subject: [dpdk-dev] [PATCH 0/6] vhost: add vhost-user client mode and reconnect 
ability

Both the vhost-user backend (DPDK here) and frontend (QEMU) could be server, as 
well as client. DPDK just acts as server so far. This patch set would make it 
possible to act as both.

A new arg (flags) is introduced for API rte_vhost_driver_register(). And the 
client mode is enabled when RTE_VHOST_USER_CLIENT is given. Note that this 
implies an API breakage. However, since this release deals with ABI/API 
refactoring, it should not be an issue.

With the DPDK as client, it's easier to implement the "reconnect" ability, 
which means we could still make vhost-user work after DPDK restarts.


---
Yuanhan Liu (6):
  vhost: rename structs for enabling client mode
  vhost: add vhost-user client mode
  vhost: add reconnect ability
  vhost: workaround stale vring base
  examples/vhost: add client and reconnect option
  vhost: add pmd client and reconnect option

 drivers/net/vhost/rte_eth_vhost.c|  54 +++-
 examples/vhost/main.c|  23 +-
 lib/librte_vhost/rte_virtio_net.h|  12 +-
 lib/librte_vhost/vhost_user/vhost-net-user.c | 355 ++-
 lib/librte_vhost/vhost_user/vhost-net-user.h |   6 -
 lib/librte_vhost/virtio-net.c|   8 +
 6 files changed, 313 insertions(+), 145 deletions(-)

--
1.9.0

[dpdk-dev] [PATCH] armv7a: disable qede pmd

[Jan Viktorin]

The qede PMD driver is failing when building for ARMv7:

drivers/net/qede/base/ecore_dev.c: In function ?ecore_hw_init_pf?:
drivers/net/qede/base/ecore_dev.c:1150:6:
error: variable ?prs_reg? set but not used 
[-Werror=unused-but-set-variable]
  u32 prs_reg;
  ^
[...]

drivers/net/qede/base/ecore_dev.c:2492:13:
error: variable ?p_phys? set but not used 
[-Werror=unused-but-set-variable]
  dma_addr_t p_phys = p_chain->p_phys_addr, p_phys_next = 0;
 ^
drivers/net/qede/base/ecore_dev.c: In function ?ecore_chain_free_pbl?:
drivers/net/qede/base/ecore_dev.c:2532:39:
error: variable ?pbl_size? set but not used 
[-Werror=unused-but-set-variable]
  u32 page_cnt = p_chain->page_cnt, i, pbl_size;

Fixes: 3eae93a9bfd5 ("qede: enable PMD build")

Signed-off-by: Jan Viktorin 
---
 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 e626ec1..bde6acd 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -74,3 +74,4 @@ CONFIG_RTE_LIBRTE_MPIPE_PMD=n
 CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
 CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
 CONFIG_RTE_LIBRTE_PMD_BNX2X=n
+CONFIG_RTE_LIBRTE_QEDE_PMD=n
-- 
2.6.2

[dpdk-dev] [PATCH 2/6] vhost: add vhost-user client mode

[Michael S. Tsirkin]

On Mon, May 09, 2016 at 01:33:08PM -0700, Yuanhan Liu wrote:
> On Mon, May 09, 2016 at 06:33:45AM -0400, Victor Kaplansky wrote:
> > Adding a flag for a future extension seems fine to me.
> > Could we manage without adding a flag?
> > For example, could we always try a client mode for a while at first,
> > and if unsuccessful, then come up with server mode?
> 
> It's hard to define "how long is for a while". And I don't think
> there is a way to switch it back to client mode from server mode
> if you do so.
> 
> So, assume you create a vhost-user port (as client), and you
> start QEMU (as server) later, after the gap you mentioned of
> auto-turn into server, it simply doesn't work then.
> 
>   --yliu

I think I agree - I don't know of other software doing
such an automatic switch. Correctly setting server/client mode
seems easy enough.


> > - Original Message -
> > > From: "Yuanhan Liu" 
> > > To: dev at dpdk.org
> > > Cc: "huawei xie" , "Yuanhan Liu"  > > linux.intel.com>
> > > Sent: Saturday, May 7, 2016 9:40:20 AM
> > > Subject: [dpdk-dev] [PATCH 2/6] vhost: add vhost-user client mode
> > > 
> > > Add a new paramter (flags) to rte_vhost_driver_register(). DPDK
> > > vhost-user acts as client mode when RTE_VHOST_USER_CLIENT flag
> > > is set.
> > > 
> > > The flags would also allow future extensions without breaking the
> > > API (again).
> > > 
> > > The rest is straingfoward then: allocate a unix socket, and
> > > bind/listen for server, connect for client.
> > > 
> > > Signed-off-by: Yuanhan Liu 
> > > ---
> > >  drivers/net/vhost/rte_eth_vhost.c|   2 +-
> > >  examples/vhost/main.c|   2 +-
> > >  lib/librte_vhost/rte_virtio_net.h|  11 +-
> > >  lib/librte_vhost/vhost_user/vhost-net-user.c | 215
> > >  ---
> > >  4 files changed, 142 insertions(+), 88 deletions(-)
> > > 
> > > diff --git a/drivers/net/vhost/rte_eth_vhost.c
> > > b/drivers/net/vhost/rte_eth_vhost.c
> > > index a9dada5..36697cf 100644
> > > --- a/drivers/net/vhost/rte_eth_vhost.c
> > > +++ b/drivers/net/vhost/rte_eth_vhost.c
> > > @@ -456,7 +456,7 @@ eth_dev_start(struct rte_eth_dev *dev)
> > >   int ret = 0;
> > >  
> > >   if (rte_atomic16_cmpset(>once, 0, 1)) {
> > > - ret = rte_vhost_driver_register(internal->iface_name);
> > > + ret = rte_vhost_driver_register(internal->iface_name, 0);
> > >   if (ret)
> > >   return ret;
> > >   }
> > > diff --git a/examples/vhost/main.c b/examples/vhost/main.c
> > > index bbf0d28..6899189 100644
> > > --- a/examples/vhost/main.c
> > > +++ b/examples/vhost/main.c
> > > @@ -1499,7 +1499,7 @@ main(int argc, char *argv[])
> > >   rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_MRG_RXBUF);
> > >  
> > >   /* Register vhost(cuse or user) driver to handle vhost messages. */
> > > - ret = rte_vhost_driver_register((char *)_basename);
> > > + ret = rte_vhost_driver_register(dev_basename, 0);
> > >   if (ret != 0)
> > >   rte_exit(EXIT_FAILURE, "vhost driver register failure.\n");
> > >  
> > > diff --git a/lib/librte_vhost/rte_virtio_net.h
> > > b/lib/librte_vhost/rte_virtio_net.h
> > > index 4e50425..c84e7ab 100644
> > > --- a/lib/librte_vhost/rte_virtio_net.h
> > > +++ b/lib/librte_vhost/rte_virtio_net.h
> > > @@ -51,6 +51,8 @@
> > >  #include 
> > >  #include 
> > >  
> > > +#define RTE_VHOST_USER_CLIENT(1ULL << 0)
> > > +
> > >  struct rte_mbuf;
> > >  
> > >  #define VHOST_MEMORY_MAX_NREGIONS 8
> > > @@ -96,11 +98,14 @@ uint64_t rte_vhost_feature_get(void);
> > >  
> > >  int rte_vhost_enable_guest_notification(int vid, uint16_t queue_id, int
> > >  enable);
> > >  
> > > -/* Register vhost driver. dev_name could be different for multiple 
> > > instance
> > > support. */
> > > -int rte_vhost_driver_register(const char *dev_name);
> > > +/**
> > > + * Register vhost driver. path could be different for multiple
> > > + * instance support.
> > > + */
> > > +int rte_vhost_driver_register(const char *path, uint64_t flags);
> > >  
> > >  /* Unregister vhost driver. This is only meaningful to vhost user. */
> > > -int rte_vhost_driver_unregister(const char *dev_name);
> > > +int rte_vhost_driver_unregister(const char *path);
> > >  
> > >  /* Register callbacks. */
> > >  int rte_vhost_driver_callback_register(struct virtio_net_device_ops 
> > > const *
> > >  const);
> > > diff --git a/lib/librte_vhost/vhost_user/vhost-net-user.c
> > > b/lib/librte_vhost/vhost_user/vhost-net-user.c
> > > index f485a3b..aa98717 100644
> > > --- a/lib/librte_vhost/vhost_user/vhost-net-user.c
> > > +++ b/lib/librte_vhost/vhost_user/vhost-net-user.c
> > > @@ -58,6 +58,7 @@
> > >  struct vhost_user_socket {
> > >   char *path;
> > >   int listenfd;
> > > + int is_server;
> > >  };
> > >  
> > >  struct vhost_user_connection {
> > > @@ -75,7 +76,7 @@ struct vhost_user {
> > >  
> > >  #define MAX_VIRTIO_BACKLOG 128
> > >  
> > > -static void vhost_user_new_connection(int fd,