[dpdk-dev] [PATCH] test-pmd: Fix pointer aliasing error

[Dayu Qiu]

Just re-post this mail as Thomas said it missed in mail list.

On Wed, Dec 3, 2014 at 7:42 PM, Bruce Richardson  wrote:

> On Wed, Dec 03, 2014 at 07:28:19PM +0800, Michael Qiu wrote:
> > app/test-pmd/csumonly.c: In function ?get_psd_sum?:
> > build/include/rte_ip.h:161: error: dereferencing pointer ?u16?
> >   does break strict-aliasing rules
> > build/include/rte_ip.h:157: note: initialized from here
> >   ...
> >
> > The root cause is that, compile enable strict aliasing by default,
> > while in function rte_raw_cksum() try to convert 'const char *'
> > to 'const uint16_t *'.
> >
>
> What compiler version is this with? Is there any other way to fix this
> other than disabling the compiler warnings. Turning off strict aliasing may
> affect performance as it reduces the number of optimizations that the
> compiler
> can perform.
>
>

The compile version is:

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
...
gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)


The OS is centos6.5 x86_64


Actually, another possible solution is, as gcc manual shows, use union.
In function rte_raw_cksum() of lib/librte_net/rte_ip.h:

static inline uint16_t
rte_raw_cksum(const char *buf, size_t len){
union {
const char *ubuf;
const uint16_t *uu16;
} convert;

convert.ubuf = buf;
const uint16_t *u16 = convert.uu16;
...
}

This may be work, but not test yet.


Thanks,
Michael

> /Bruce
>
> > Need to add CFLAG '-Wno-strict-aliasing' to avoid this issue.
> >
> > Signed-off-by: Michael Qiu 
> > ---
> >  app/test-pmd/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
> > index 97dc2e6..995c874 100644
> > --- a/app/test-pmd/Makefile
> > +++ b/app/test-pmd/Makefile
> > @@ -38,7 +38,7 @@ ifeq ($(CONFIG_RTE_TEST_PMD),y)
> >  #
> >  APP = testpmd
> >
> > -CFLAGS += -O3
> > +CFLAGS += -O3 -Wno-strict-aliasing
> >  CFLAGS += $(WERROR_FLAGS)
> >
> >  ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
> > --
> > 1.9.3
> >
>



-- 
Thanks & Best Regards
Mike

[dpdk-dev] [PATCH] mk: fix LDFLAGS for shared lib

[Hiroshi Shimamoto]

From: Hiroshi Shimamoto 

Only CPU_LDFLAGS is used in mk/rte.sharelib.mk.
It should be LDFLAGS to build the library with correct linkage options.

Signed-off-by: Hiroshi Shimamoto 
Reviewed-by: Hayato Momma 
---
 mk/rte.sharelib.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index c0a811a..df6c268 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -45,7 +45,7 @@ sharelib: $(LIB_ONE) FORCE

 OBJS = $(wildcard $(RTE_OUTPUT)/build/lib/*.o)

-O_TO_S = $(LD) $(CPU_LDFLAGS) -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
+O_TO_S = $(LD) $(LDFLAGS) -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
 O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
 O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)","  LD $(@)")
 O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)"
-- 
1.8.3.1

[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[O'driscoll, Tim]

Hi Olga,

> Can you please send the presentations from last Community Call.
> We have Tetsuya's presentation,  if we can also get other presentations it 
> will
> be great

No problem. Changchun's slides on the converged Virtio driver and Marvin's 
slides on the DPDK Test Suite are attached.


Tim

-- next part --
A non-text attachment was scrubbed...
Name: DPDK Test Suite.pdf
Type: application/pdf
Size: 725579 bytes
Desc: DPDK Test Suite.pdf
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20141203/3477d73d/attachment-0002.pdf>
-- next part --
A non-text attachment was scrubbed...
Name: Single Virtio.pdf
Type: application/pdf
Size: 216187 bytes
Desc: Single Virtio.pdf
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20141203/3477d73d/attachment-0003.pdf>

[dpdk-dev] [PATCH 2/2] app/testpmd: fix endianness detection

[Thomas Monjalon]

Use endianness detection factorized in EAL.

The comment about arpa/inet.h is not valid anymore since
commit d07180f211c08 ("net: fix conflict with libc").

The macro _htons could also be moved in rte_byteorder.h
by providing some constant byte swapping.

Signed-off-by: Thomas Monjalon 
---
 app/test-pmd/config.c   | 2 +-
 app/test-pmd/csumonly.c | 5 ++---
 app/test-pmd/testpmd.h  | 2 +-
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index f0b770e..69a83c2 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -628,7 +628,7 @@ ring_dma_zone_lookup(const char *ring_name, uint8_t 
port_id, uint16_t q_id)
 union igb_ring_dword {
uint64_t dword;
struct {
-#ifdef RTE_ARCH_BIG_ENDIAN
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
uint32_t lo;
uint32_t hi;
 #else
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 6f43761..da4bca4 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -79,9 +79,8 @@
 #define IP_HDRLEN  0x05 /* default IP header length == five 32-bits words. */
 #define IP_VHL_DEF (IP_VERSION | IP_HDRLEN)

-/* we cannot use htons() from arpa/inet.h due to name conflicts, and we
- * cannot use rte_cpu_to_be_16() on a constant in a switch/case */
-#if  __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+/* We cannot use rte_cpu_to_be_16() on a constant in a switch/case */
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
 #define _htons(x) ((uint16_t)x) & 0x00ffU) << 8) | (((x) & 0xff00U) >> 8)))
 #else
 #define _htons(x) (x)
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index c925910..f8b0740 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -567,7 +567,7 @@ int tx_queue_id_is_invalid(queueid_t txq_id);
 #define RTE_BE_TO_CPU_16(be_16_v)  rte_be_to_cpu_16((be_16_v))
 #define RTE_CPU_TO_BE_16(cpu_16_v) rte_cpu_to_be_16((cpu_16_v))
 #else
-#ifdef __big_endian__
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
 #define RTE_BE_TO_CPU_16(be_16_v)  (be_16_v)
 #define RTE_CPU_TO_BE_16(cpu_16_v) (cpu_16_v)
 #else
-- 
2.1.3

[dpdk-dev] [PATCH 1/2] eal: detect endianness

[Thomas Monjalon]

There is no standard to check endianness.
So we need to try different checks.
Previous trials were done in testpmd (see commits
51f694dd40f56 and 64741f237cf29) without full success.
This one is not guaranteed to work everywhere so it could
evolve when exceptions are found.

If endianness is not detected, there is a fallback on x86
to little endian. It could be forced before doing detection
but it would add some arch-dependent code in the generic header.

The option CONFIG_RTE_ARCH_BIG_ENDIAN introduced for IBM Power only
(commit a982ec81d84d53) can be removed. A compile-time check is better.

Signed-off-by: Thomas Monjalon 
---
 config/defconfig_ppc_64-power8-linuxapp-gcc|  1 -
 .../common/include/arch/ppc_64/rte_byteorder.h |  4 ++--
 .../common/include/arch/x86/rte_byteorder.h|  4 
 .../common/include/generic/rte_byteorder.h | 28 ++
 4 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc 
b/config/defconfig_ppc_64-power8-linuxapp-gcc
index 48018c3..d97a885 100644
--- a/config/defconfig_ppc_64-power8-linuxapp-gcc
+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc
@@ -34,7 +34,6 @@ CONFIG_RTE_MACHINE="power8"

 CONFIG_RTE_ARCH="ppc_64"
 CONFIG_RTE_ARCH_PPC_64=y
-CONFIG_RTE_ARCH_BIG_ENDIAN=y
 CONFIG_RTE_ARCH_64=y

 CONFIG_RTE_TOOLCHAIN="gcc"
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_byteorder.h 
b/lib/librte_eal/common/include/arch/ppc_64/rte_byteorder.h
index 1a89051..80436f2 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_byteorder.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_byteorder.h
@@ -105,7 +105,7 @@ static inline uint64_t rte_arch_bswap64(uint64_t _x)
 /* Power 8 have both little endian and big endian mode
  * Power 7 only support big endian
  */
-#ifndef RTE_ARCH_BIG_ENDIAN
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN

 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -123,7 +123,7 @@ static inline uint64_t rte_arch_bswap64(uint64_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)

-#else
+#else /* RTE_BIG_ENDIAN */

 #define rte_cpu_to_le_16(x) rte_bswap16(x)
 #define rte_cpu_to_le_32(x) rte_bswap32(x)
diff --git a/lib/librte_eal/common/include/arch/x86/rte_byteorder.h 
b/lib/librte_eal/common/include/arch/x86/rte_byteorder.h
index 1aa6985..ffdb6ef 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_byteorder.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_byteorder.h
@@ -40,6 +40,10 @@ extern "C" {

 #include "generic/rte_byteorder.h"

+#ifndef RTE_BYTE_ORDER
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#endif
+
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
diff --git a/lib/librte_eal/common/include/generic/rte_byteorder.h 
b/lib/librte_eal/common/include/generic/rte_byteorder.h
index 9358136..ea23fdf 100644
--- a/lib/librte_eal/common/include/generic/rte_byteorder.h
+++ b/lib/librte_eal/common/include/generic/rte_byteorder.h
@@ -44,6 +44,34 @@
  */

 #include 
+#ifdef RTE_EXEC_ENV_BSDAPP
+#include 
+#else
+#include 
+#endif
+
+/*
+ * Compile-time endianness detection
+ */
+#define RTE_BIG_ENDIAN1
+#define RTE_LITTLE_ENDIAN 2
+#if defined __BYTE_ORDER
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define RTE_BYTE_ORDER RTE_BIG_ENDIAN
+#elif __BYTE_ORDER == __LITTLE_ENDIAN
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#endif /* __BYTE_ORDER */
+#elif defined __BYTE_ORDER__
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+#define RTE_BYTE_ORDER RTE_BIG_ENDIAN
+#elif __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#endif /* __BYTE_ORDER__ */
+#elif defined __BIG_ENDIAN__
+#define RTE_BYTE_ORDER RTE_BIG_ENDIAN
+#elif defined __LITTLE_ENDIAN__
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#endif

 /*
  * An internal function to swap bytes in a 16-bit value.
-- 
2.1.3

[dpdk-dev] [PATCH 0/2] fix endianness in EAL

[Thomas Monjalon]

It can be hard to implement a reliable detection of endianness.
Previous trials in testpmd failed.
The IBM Power patchset introduced a config option.

This patchset try to improve the situation by having a detection
in EAL headers.

Please test it (especially on IBM Power) with different toolchains
or distributions.

Thomas Monjalon (2):
  eal: detect endianness
  app/testpmd: fix endianness detection

-- 
2.1.3

[dpdk-dev] [PATCH] test-pmd: Fix "__BYTE_ORDER__" not defined error

[Thomas Monjalon]

2014-12-03 16:26, Qiu, Michael:
> > --- a/app/test-pmd/csumonly.c
> > +++ b/app/test-pmd/csumonly.c
> > @@ -81,7 +81,13 @@
> >  
> >  /* we cannot use htons() from arpa/inet.h due to name conflicts, and we
> >   * cannot use rte_cpu_to_be_16() on a constant in a switch/case */
> > -#if  __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > +#ifdef __BYTE_ORDER__
> > +#define LITTLE_ENDIAN_CHECK (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
> > +#else
> > +#define LITTLE_ENDIAN_CHECK (__BYTE_ORDER == __LITTLE_ENDIAN)
> > +#endif
> > +
> > +#if LITTLE_ENDIAN_CHECK
> >  #define _htons(x) ((uint16_t)x) & 0x00ffU) << 8) | (((x) & 0xff00U) >> 
> > 8)))
> >  #else
> >  #define _htons(x) (x)

I don't agree we should fix it in testpmd.
It's a more general problem which must be solved in EAL.
I'm preparing a patchset to fix it.

-- 
Thomas

[dpdk-dev] [PULL REQUEST] doc: document modifications in user guides

[Thomas Monjalon]

Hi Bernard,

These patches won't pulled as is for 2 reasons:
1) I made some comments recently on some of these patches
2) It appears you didn't applied the v5 of Pablo's patchset
http://dpdk.org/ml/archives/dev/2014-December/009270.html

Below some title rewording to make it concise and more consistent:

2014-12-03 15:50, Bernard Iremonger:
> Bruce Richardson (3):
>   doc: change hardcoded date to auto-generated in guide documents
doc: auto-generate date in guides
>   doc: adjust line lengths in freebsd getting started guide rst files
doc: adjust line lengths in freebsd guide
>   doc: update freebsd getting started guide to document ports install
doc: add freebsd ports
> 
> Doherty, Declan (1):
>   doc: link bonding related updates to programmers guide
doc: update bonding
> 
> Pablo de Lara (4):
>   doc: added new commands in testpmd application user guide
doc: new testpmd commands
>   doc: fix commands in testpmd application user guide
doc: fix testpmd commands
>   doc: moved commands in testpmd application user guide to match testpmd 
> command help order
doc: reorder testpmd commands
>   doc: fixes in testpmd application user guide
doc: fix testpmd guide
> 
> Siobhan Butler (4):
>   doc: added distributor sample application to the sample application 
> user guide
doc: add distributor application
>   doc: add vhost library section in programmers guide
doc: add vhost library
>   doc: updated i40e enabling additonal functionality in linux getting 
> started guide
doc: update i40e
>   doc: remove references to intel dpdk in linux getting started guide

-- 
Thomas

[dpdk-dev] Error: Cannot allocate memzone for ethernet port data Pktgen

[Venkateswara Rao Dokku]

Hi,

I am getting the following error when I am trying to run the PktGen on DPDK
EAL:   PCI memory mapped at 0x7f4ba0d6c000
PANIC in rte_eth_dev_data_alloc():
Cannot allocate memzone for ethernet port data
9: [./app/build/pktgen() [0x421069]]
8: [/lib64/libc.so.6(__libc_start_main+0xfd) [0x3af581ecdd]]
7: [./app/build/pktgen(main+0x115) [0x430ce5]]
6: [./app/build/pktgen(rte_eal_init+0xb58) [0x4b2a88]]
5: [./app/build/pktgen(rte_eal_pci_probe+0xfb) [0x4bc90b]]
4: [./app/build/pktgen() [0x4ac87e]]
3: [./app/build/pktgen() [0x4ac822]]
2: [./app/build/pktgen(__rte_panic+0xc0) [0x420fb0]]
1: [./app/build/pktgen(rte_dump_stack+0x1e) [0x4b900e]]
Aborted (core dumped)

These are the steps I followed.

1. Loaded the Igb_Uio module
2. Loaded the KNI module
3. Allocated HugePages
4.Ran the PktGen with the following command
./app/build/pktgen -c 0x1 -n 3 --proc-type auto --file-prefix pg -- -P

Can you please help me in solving the issue.

PS: I thought the error is due to insufficient number of huge pages, so I
increased the number of hugepages and tried. Still facing the same issue.
DPDK version 1.7
PktGen 2.5.6

-- 
Thanks & Regards,
Venkateswara Rao Dokku.

[dpdk-dev] [question] DPDK-2.0 support broadcom driver

[Thomas Monjalon]

2014-12-03 10:04, Stephen Hemminger:
> On Wed, 3 Dec 2014 09:48:57 +0800
> "Zhang Haoyu"  wrote:
> > I see that broadcom driver will be supported in DPDK-2.0 from 
> > DPDK roadmap(http://dpdk.org/dev/roadmap),
> > any details about the progress?
> 
> I have patch, just too big for mailing list.

Yes, a repository to maintain this broadcom driver should be open soon.
The goal is to merge it in DPDK 2.0 and to maintain it in a sub-repository
with a "pull request" model.

By the way, the sub-repository model will be also applied to i40e and to any
other driver having a maintainer who requests it.

-- 
Thomas

[dpdk-dev] [PATCH] librte_cmdline: FreeBSD Fix oveflow when size of command result structure is greater than BUFSIZ

[Thomas Monjalon]

2014-12-03 17:05, Olivier MATZ:
> Hi,
> 
> On 10/27/2014 10:14 AM, Olivier MATZ wrote:
> > Hello Alan,
> >
> > On 10/20/2014 05:26 PM, Carew, Alan wrote:
> >> A comment on my own patch.
> >>
> >> Making the size of result_buf consistent across each OS and keeping it as 
> >> large
> >> as the Linux BUFSIZ(8192) doesn't really address the core issue.
> >>
> >> In the event that a user of librte_cmdline creates a custom context with a
> >> result structure > 8192 bytes then this problem will occur again, though
> >> somewhat unlikely, as the minimum number of the largest type would be 64 x
> >> cmdline_fixed_string_t types within a result structure, at its current 
> >> size.
> >>
> >> There is no checking of overflow, I would be tempted to add a runtime 
> >> check in
> >> cmdline_parse()/match_inst(), however I would be more comfortable with a 
> >> build
> >> time check for this type of problem.
> >>
> >> Due to the opaque handling of user defined contexts there is no obvious 
> >> way to
> >> do this at build time.
> >>
> >> Thoughts?
> >
> > Indeed, your patch does not address the core issue of the problem,
> > altough it's already an improvement to the current situation.
> >
> > Your issue was already fixed in the latest libcmdline library by
> > this patch (which also includes the replacement of BUFSIZ):
> > http://git.droids-corp.org/?p=libcmdline.git;a=commitdiff;h=b1d5b169352e57df3fc14c51ffad4b83f3e5613f
> >
> > I'm pretty sure it won't apply smoothly on the dpdk command line
> > library but it can probably be adapted. Ideally, the latest libcmdline
> > library should be [cleaned first and] merged in dpdk.org.
> 
> Sorry, I had no time to deeply check this. I think your patch can
> go in 1.8 as it's still an enhancement compared to the current
> situation. We may go back on this later.
> 
> Acked-by: Olivier Matz 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH v2] add one option memory-only for secondary processes

[chixiaobo]

From: Chi Xiaobo 

Problem: There is one normal DPDK processes deployment scenarios: one primary 
process and several (even hundreds) secondary processes; all outside 
packets/messages are sent/received by primary process and then distribute them 
to those secondary processes by DPDK's ring/sharedmemory mechanism. In such 
scenarios, those SECONDARY processes need only hugepage based sharememory 
mechanism and it???s upper libs (such as ring, mempool, etc.), they need not 
cpu core pinning, iopl privilege changing , pci device, timer, alarm, 
interrupt, shared_driver_list,  core_info, threads for each core, etc. Then, 
for such kind of SECONDARY processes, the current rte_eal_init() is too heavy.

Solution:One new EAL initializing argument, --memory-only, is added. It is only 
for those SECONDARY processes which only want to share memory with other 
processes. if this argument is defined, users need not define those mandatory 
arguments, such as -c and -n, due to we don't want to pin such kind of 
processes to any CPUs.
Signed-off-by: Chi Xiaobo 
---
 lib/librte_eal/common/eal_common_options.c | 17 ---
 lib/librte_eal/common/eal_internal_cfg.h   |  1 +
 lib/librte_eal/common/eal_options.h|  2 ++
 lib/librte_eal/linuxapp/eal/eal.c  | 34 +-
 4 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index e2810ab..7b18498 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -85,6 +85,7 @@ eal_long_options[] = {
{OPT_XEN_DOM0, 0, 0, OPT_XEN_DOM0_NUM},
{OPT_CREATE_UIO_DEV, 1, NULL, OPT_CREATE_UIO_DEV_NUM},
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
+   {OPT_MEMORY_ONLY, 0, NULL, OPT_MEMORY_ONLY_NUM},
{0, 0, 0, 0}
 };

@@ -126,6 +127,7 @@ eal_reset_internal_config(struct internal_config 
*internal_cfg)
internal_cfg->no_hpet = 1;
 #endif
internal_cfg->vmware_tsc_map = 0;
+   internal_cfg->memory_only= 0;
 }

 /*
@@ -454,6 +456,10 @@ eal_parse_common_option(int opt, const char *optarg,
conf->process_type = eal_parse_proc_type(optarg);
break;

+   case OPT_MEMORY_ONLY_NUM:
+   conf->memory_only= 1;
+   break;
+
case OPT_MASTER_LCORE_NUM:
if (eal_parse_master_lcore(optarg) < 0) {
RTE_LOG(ERR, EAL, "invalid parameter for --"
@@ -525,9 +531,9 @@ eal_check_common_options(struct internal_config 
*internal_cfg)
 {
struct rte_config *cfg = rte_eal_get_configuration();

-   if (!lcores_parsed) {
-   RTE_LOG(ERR, EAL, "CPU cores must be enabled with options "
-   "-c or -l\n");
+   if (!lcores_parsed && !(internal_cfg->process_type == 
RTE_PROC_SECONDARY&& internal_cfg->memory_only) ) {
+   RTE_LOG(ERR, EAL, "For those processes without memory-only 
option, CPU cores "
+   "must be enabled with 
options -c or -l\n");
return -1;
}
if (cfg->lcore_role[cfg->master_lcore] != ROLE_RTE) {
@@ -545,6 +551,10 @@ eal_check_common_options(struct internal_config 
*internal_cfg)
"specified\n");
return -1;
}
+   if ( internal_cfg->process_type != RTE_PROC_SECONDARY && 
internal_cfg->memory_only ) {
+   RTE_LOG(ERR, EAL, "only secondary processes can specify 
memory-only option.\n");
+   return -1;
+   }
if (index(internal_cfg->hugefile_prefix, '%') != NULL) {
RTE_LOG(ERR, EAL, "Invalid char, '%%', in --"OPT_FILE_PREFIX" "
"option\n");
@@ -590,6 +600,7 @@ eal_common_usage(void)
   "  --"OPT_SYSLOG" : set syslog facility\n"
   "  --"OPT_LOG_LEVEL"  : set default log level\n"
   "  --"OPT_PROC_TYPE"  : type of this process\n"
+  "  --"OPT_MEMORY_ONLY": only use shared memory, valid only for 
secondary process.\n"
   "  --"OPT_PCI_BLACKLIST", -b: add a PCI device in black list.\n"
   "   Prevent EAL from using this PCI device. The 
argument\n"
   "   format is .\n"
diff --git a/lib/librte_eal/common/eal_internal_cfg.h 
b/lib/librte_eal/common/eal_internal_cfg.h
index aac6abf..f51f0a2 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -85,6 +85,7 @@ struct internal_config {

unsigned num_hugepage_sizes;  /**< how many sizes on this system */
struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES];
+   volatile unsigned memory_only;/**name);
solib->lib_handle = dlopen(solib->name, RTLD_NOW);
-- 
1.9.4.msysgit.2

[dpdk-dev] DPDK logs

[Venkateswara Rao Dokku]

Hi,

Where are the logs be stored, when we are running the DPDK.

Can we customize them , to log into a specific folder?

Thanks.

-- 
Thanks & Regards,
Venkateswara Rao Dokku,
Senior Software Engineer, Citrix Systems R&D,
Bangalore

[dpdk-dev] [PATCH] librte_cmdline: FreeBSD Fix oveflow when size of command result structure is greater than BUFSIZ

[Olivier MATZ]

Hi,

On 10/27/2014 10:14 AM, Olivier MATZ wrote:
> Hello Alan,
>
> On 10/20/2014 05:26 PM, Carew, Alan wrote:
>> A comment on my own patch.
>>
>> Making the size of result_buf consistent across each OS and keeping it as 
>> large
>> as the Linux BUFSIZ(8192) doesn't really address the core issue.
>>
>> In the event that a user of librte_cmdline creates a custom context with a
>> result structure > 8192 bytes then this problem will occur again, though
>> somewhat unlikely, as the minimum number of the largest type would be 64 x
>> cmdline_fixed_string_t types within a result structure, at its current size.
>>
>> There is no checking of overflow, I would be tempted to add a runtime check 
>> in
>> cmdline_parse()/match_inst(), however I would be more comfortable with a 
>> build
>> time check for this type of problem.
>>
>> Due to the opaque handling of user defined contexts there is no obvious way 
>> to
>> do this at build time.
>>
>> Thoughts?
>
> Indeed, your patch does not address the core issue of the problem,
> altough it's already an improvement to the current situation.
>
> Your issue was already fixed in the latest libcmdline library by
> this patch (which also includes the replacement of BUFSIZ):
> http://git.droids-corp.org/?p=libcmdline.git;a=commitdiff;h=b1d5b169352e57df3fc14c51ffad4b83f3e5613f
>
> I'm pretty sure it won't apply smoothly on the dpdk command line
> library but it can probably be adapted. Ideally, the latest libcmdline
> library should be [cleaned first and] merged in dpdk.org.

Sorry, I had no time to deeply check this. I think your patch can
go in 1.8 as it's still an enhancement compared to the current
situation. We may go back on this later.

Acked-by: Olivier Matz 

[dpdk-dev] [PATCH] examples: fix symmetric_mp, set NIC rx_drop_en bit

[Bruce Richardson]

The symmetric_mp example app is set up to allow two processes to
share a NIC port, with each pulling packets from one queue. In order
to have the app continue working when one of the process dies, the
drop_en bit should be set in the NIC configuration. Without this bit
set, the NIC will stall once any queue fills. With the bit set, once
a queue fills, all subsequent packets for that queue are discarded
allowing other queues to continue operating as normal.

This setting was missed when converting to use standardised defaults
in commit 81f7ecd9.

Signed-off-by: Bruce Richardson 
---
 examples/multi_process/symmetric_mp/main.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/examples/multi_process/symmetric_mp/main.c 
b/examples/multi_process/symmetric_mp/main.c
index 01faae9..2fc2acf 100644
--- a/examples/multi_process/symmetric_mp/main.c
+++ b/examples/multi_process/symmetric_mp/main.c
@@ -229,6 +229,7 @@ smp_port_init(uint8_t port, struct rte_mempool *mbuf_pool, 
uint16_t num_queues)
}
};
const uint16_t rx_rings = num_queues, tx_rings = num_queues;
+   struct rte_eth_dev_info info;
int retval;
uint16_t q;

@@ -241,6 +242,9 @@ smp_port_init(uint8_t port, struct rte_mempool *mbuf_pool, 
uint16_t num_queues)
printf("# Initialising port %u... ", (unsigned)port);
fflush(stdout);

+   rte_eth_dev_info_get(port, &info);
+   info.default_rxconf.rx_drop_en = 1;
+
retval = rte_eth_dev_configure(port, rx_rings, tx_rings, &port_conf);
if (retval < 0)
return retval;
@@ -248,7 +252,7 @@ smp_port_init(uint8_t port, struct rte_mempool *mbuf_pool, 
uint16_t num_queues)
for (q = 0; q < rx_rings; q ++) {
retval = rte_eth_rx_queue_setup(port, q, RX_RING_SIZE,
rte_eth_dev_socket_id(port),
-   NULL,
+   &info.default_rxconf,
mbuf_pool);
if (retval < 0)
return retval;
-- 
1.9.3

[dpdk-dev] [PATCH] test-pmd: Fix "__BYTE_ORDER__" not defined error

[Qiu, Michael]

Hi all,

What about this patch?

It may be some network or mail client issue of me, so not sure this
patch posted to mail list successful.

If failed, I will re-post it later.

Thanks,
Michael

On 2014/12/3 19:28, Michael Qiu wrote:
> app/test-pmd/csumonly.c:84:5: error: "__BYTE_ORDER__" is not defined
> app/test-pmd/csumonly.c:84:23: error: "__ORDER_LITTLE_ENDIAN__" is not defined
>
> This because old gcc version, like 4.4.7, does not has these buildin macros.
>
> $ gcc -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> ...
> gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
>
> $ echo | gcc -dM -E -| grep "LITTLE"
> (none)
>
> In this situation, we should back to use the macros defined in
> 
>
> Signed-off-by: Michael Qiu 
> ---
>  app/test-pmd/csumonly.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index 6f43761..3fa81a2 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -81,7 +81,13 @@
>  
>  /* we cannot use htons() from arpa/inet.h due to name conflicts, and we
>   * cannot use rte_cpu_to_be_16() on a constant in a switch/case */
> -#if  __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> +#ifdef __BYTE_ORDER__
> +#define LITTLE_ENDIAN_CHECK (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
> +#else
> +#define LITTLE_ENDIAN_CHECK (__BYTE_ORDER == __LITTLE_ENDIAN)
> +#endif
> +
> +#if LITTLE_ENDIAN_CHECK
>  #define _htons(x) ((uint16_t)x) & 0x00ffU) << 8) | (((x) & 0xff00U) >> 
> 8)))
>  #else
>  #define _htons(x) (x)

[dpdk-dev] [PATCH] test-pmd: Fix pointer aliasing error

[Olivier MATZ]

Hi Bruce,

On 12/03/2014 12:42 PM, Bruce Richardson wrote:
> On Wed, Dec 03, 2014 at 07:28:19PM +0800, Michael Qiu wrote:
>> app/test-pmd/csumonly.c: In function ?get_psd_sum?:
>> build/include/rte_ip.h:161: error: dereferencing pointer ?u16?
>>  does break strict-aliasing rules
>> build/include/rte_ip.h:157: note: initialized from here
>>  ...
>>
>> The root cause is that, compile enable strict aliasing by default,
>> while in function rte_raw_cksum() try to convert 'const char *'
>> to 'const uint16_t *'.
>>
>
> What compiler version is this with? Is there any other way to fix this
> other than disabling the compiler warnings. Turning off strict aliasing may
> affect performance as it reduces the number of optimizations that the compiler
> can perform.

I can reproduce the issue with a gcc-4.4.6 toolchain. But I think it's
a toolchain bug as the warning does not occur with other versions I've
tested.

If it's the case, we could either:

- do nothing: in this case the user need to upgrade its toolchain, or
   pass the -Wno-strict-aliasing manually in EXTRA_CFLAGS

- add the -Wno-strict-aliasing only for gcc 4.4 in the Makefile

What do you think?

Regards,
Olivier

[dpdk-dev] [PATCH] enic: fix warnings

[Thomas Monjalon]

2014-12-03 14:52, Sujith Sankar:
> 
> On 02/12/14 8:29 pm, "Thomas Monjalon"  wrote:
> 
> >A lot of warnings were not seen because $(WERROR_FLAGS) was not set
> >in the Makefile. But they appear with toolchains that enforce more checks.
> >
> >-Wno-deprecated seems useless.
> >-Wno-strict-aliasing is added to avoid false positives.
> >
> >This patch cleans up unused variable, unused functions, wrong types,
> >static declarations, etc. A lot of functions have unused parameters;
> >it suggests that more clean-up could be needed.
> 
> I shall look at it when I pull these changes to my repo.
> What other toolchains did you check with?

It's tested with many distributions, example CentOS 6.
But adding the warnings as in this patch should be enough to test with
any toolchain.

-- 
Thomas

[dpdk-dev] [PULL REQUEST] doc: document modifications in user guides

[Bernard Iremonger]

These changes are DPDK 1.8 modifications and some corrections to the
Linux Getting Started Guide, the FreeBSD Getting Started Guide,
the Programmers Guide, the Sample Application User Guide,
the TestPMD Application User Guide and the Release Notes.

The following changes since commit b6f80756e7b78a8a2a8688bc475a2cb8f6e3a188:

  kni: create interface in current network namespace (2014-12-03 15:01:08 +0100)

are available in the git repository at:
  git://dpdk.org/next/dpdk-doc  master


Bruce Richardson (3):
  doc: change hardcoded date to auto-generated in guide documents
  doc: adjust line lengths in freebsd getting started guide rst files
  doc: update freebsd getting started guide to document ports install

Doherty, Declan (1):
  doc: link bonding related updates to programmers guide

Pablo de Lara (4):
  doc: added new commands in testpmd application user guide
  doc: fix commands in testpmd application user guide
  doc: moved commands in testpmd application user guide to match testpmd 
command help order
  doc: fixes in testpmd application user guide

Siobhan Butler (4):
  doc: added distributor sample application to the sample application user 
guide
  doc: add vhost library section in programmers guide
  doc: updated i40e enabling additonal functionality in linux getting 
started guide
  doc: remove references to intel dpdk in linux getting started guide

 doc/guides/freebsd_gsg/build_dpdk.rst  |  295 --
 doc/guides/freebsd_gsg/build_sample_apps.rst   |   96 +-
 doc/guides/freebsd_gsg/index.rst   |4 +-
 doc/guides/freebsd_gsg/install_from_ports.rst  |  162 +++
 doc/guides/freebsd_gsg/intro.rst   |   55 +-
 doc/guides/freebsd_gsg/sys_reqs.rst|  163 ---
 doc/guides/linux_gsg/build_dpdk.rst|  149 ++--
 doc/guides/linux_gsg/build_sample_apps.rst |  146 ++-
 doc/guides/linux_gsg/enable_func.rst   |  158 ++-
 doc/guides/linux_gsg/index.rst |2 +-
 doc/guides/linux_gsg/intro.rst |   37 +-
 doc/guides/linux_gsg/quick_start.rst   |   61 +-
 doc/guides/linux_gsg/sys_reqs.rst  |  182 ++--
 doc/guides/prog_guide/img/bond-mode-0.svg  |  638 +++
 doc/guides/prog_guide/img/bond-mode-1.svg  |  724 +
 doc/guides/prog_guide/img/bond-mode-2.svg  |  702 
 doc/guides/prog_guide/img/bond-mode-3.svg  |  702 
 doc/guides/prog_guide/img/bond-mode-4.svg  |  784 ++
 doc/guides/prog_guide/img/bond-mode-5.svg  |  642 +++
 doc/guides/prog_guide/img/bond-overview.svg|  121 +++
 doc/guides/prog_guide/img/link_bonding.png |  Bin 223318 -> 0 bytes
 doc/guides/prog_guide/index.rst|3 +-
 .../prog_guide/link_bonding_poll_mode_drv_lib.rst  |  365 +--
 doc/guides/prog_guide/vhost_lib.rst|  101 ++
 doc/guides/rel_notes/index.rst |2 +-
 doc/guides/sample_app_ug/dist_app.rst  |  177 +++
 doc/guides/sample_app_ug/img/dist_app.svg  |  442 
 doc/guides/sample_app_ug/img/dist_perf.svg |  459 
 doc/guides/sample_app_ug/index.rst |7 +-
 doc/guides/testpmd_app_ug/index.rst|2 +-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst| 1129 +++-
 31 files changed, 7278 insertions(+), 1232 deletions(-)
 create mode 100644 doc/guides/freebsd_gsg/install_from_ports.rst
 delete mode 100644 doc/guides/freebsd_gsg/sys_reqs.rst
 create mode 100644 doc/guides/prog_guide/img/bond-mode-0.svg
 create mode 100644 doc/guides/prog_guide/img/bond-mode-1.svg
 create mode 100644 doc/guides/prog_guide/img/bond-mode-2.svg
 create mode 100644 doc/guides/prog_guide/img/bond-mode-3.svg
 create mode 100644 doc/guides/prog_guide/img/bond-mode-4.svg
 create mode 100644 doc/guides/prog_guide/img/bond-mode-5.svg
 create mode 100644 doc/guides/prog_guide/img/bond-overview.svg
 delete mode 100644 doc/guides/prog_guide/img/link_bonding.png
 create mode 100644 doc/guides/prog_guide/vhost_lib.rst
 create mode 100644 doc/guides/sample_app_ug/dist_app.rst
 create mode 100644 doc/guides/sample_app_ug/img/dist_app.svg
 create mode 100644 doc/guides/sample_app_ug/img/dist_perf.svg

[dpdk-dev] [PATCH v5 2/3] mbuf:add three TX ol_flags and repalce PKT_TX_VXLAN_CKSUM

[Olivier MATZ]

Hi Konstantin,

On 12/03/2014 01:59 PM, Ananyev, Konstantin wrote:
>> I still think having a flag IPV4 + another flag IP_CHECKSUM is not
>> appropriate.
>
> Sorry, didn't get you here.
> Are you talking about our discussion should PKT_TX_IP_CKSUM and PKT_TX_IPV4 
> be mutually exclusive or not?

Yes

>> I though Konstantin agreed on other flags, but I may
>> have misunderstood:
>>
>> http://dpdk.org/ml/archives/dev/2014-November/009070.html
>
> In that mail, I was talking about my suggestion to make  PKT_TX_IP_CKSUM, 
> PKT_TX_IPV4 and PKT_TX_IPV6 to occupy 2 bits.
> Something like:
> #define   PKT_TX_IP_CKSUM (1 << X)
> #define   PKT_TX_IPV6 (2 << X)
> #define   PKT_TX_IPV4 (3 << X)
>
> "Even better, if we can squeeze these 3 flags into 2 bits.
> Would save us 2 bits, plus might be handy, as in the PMD you can do:
>
> switch (ol_flags & TX_L3_MASK) {
>  case TX_IPV4:
> ...
> break;
>  case TX_IPV6:
> ...
> break;
>  case TX_IP_CKSUM:
> ...
> break;
> }"
>
> As you pointed out, it will break backward compatibility.
> I agreed with that and self-NACKed it.

ok, so we are back between:

1/ (Jijiang's patch)
PKT_TX_IP_CKSUM  /* packet is IPv4, and we want hw cksum */
PKT_TX_IPV6  /* packet is IPv6 */
PKT_TX_IPV4  /* packet is IPv4, and we don't want hw cksum */

with PKT_TX_IP_CKSUM and PKT_TX_IPV4 exclusive

and

2/
PKT_TX_IP_CKSUM  /* we want hw IP cksum */
PKT_TX_IPV6  /* packet is IPv6 */
PKT_TX_IPV4  /* packet is IPv4 */

with PKT_TX_IP_CKSUM implies PKT_TX_IPV4


Solution 2/ looks better from a user point of view. Anyone else has an
opinion?

Regards,
Olivier

[dpdk-dev] [PATCH v2] Fix two compile issues with i686 platform

[Bruce Richardson]

On Wed, Dec 03, 2014 at 04:10:23PM +0800, Michael Qiu wrote:
> lib/librte_eal/linuxapp/eal/eal_memory.c:324:4: error: comparison
> is always false due to limited range of data type [-Werror=type-limits]
> || (hugepage_sz == RTE_PGSIZE_16G)) {
> ^
> cc1: all warnings being treated as errors
> 
> lib/librte_eal/linuxapp/eal/eal.c(461): error #2259: non-pointer
> conversion from "long long" to "void *" may lose significant bits
>RTE_PTR_ALIGN_CEIL((uintptr_t)addr, RTE_PGSIZE_16M);
> 
> This was introuduced by commit b77b5639:
> mem: add huge page sizes for IBM Power
> 
> The root cause is that size_t and uintptr_t are 32-bit in i686
> platform, but RTE_PGSIZE_16M and RTE_PGSIZE_16G are always 64-bit.
> 
> Define RTE_PGSIZE_16G only in 64 bit platform to avoid
> this issue.
> 
> Signed-off-by: Michael Qiu 
Minor comment below.

Acked-by: Bruce Richardson 

> ---
>  app/test/test_memzone.c| 18 --
>  lib/librte_eal/common/eal_common_memzone.c |  2 ++
>  lib/librte_eal/common/include/rte_memory.h | 14 --
>  lib/librte_eal/linuxapp/eal/eal_memory.c   | 12 +---
>  4 files changed, 27 insertions(+), 19 deletions(-)
> 
... snip ...
> --- a/lib/librte_eal/common/include/rte_memory.h
> +++ b/lib/librte_eal/common/include/rte_memory.h
> @@ -53,12 +53,14 @@ extern "C" {
>  #endif
>  
>  enum rte_page_sizes {
> - RTE_PGSIZE_4K = 1ULL << 12,
> - RTE_PGSIZE_2M = 1ULL << 21,
> - RTE_PGSIZE_1G = 1ULL << 30,
> - RTE_PGSIZE_64K = 1ULL << 16,
> - RTE_PGSIZE_16M = 1ULL << 24,
> - RTE_PGSIZE_16G = 1ULL << 34
> + RTE_PGSIZE_4K   = 1UL << 12,
> + RTE_PGSIZE_2M   = 1UL << 21,
> + RTE_PGSIZE_1G   = 1UL << 30,
> + RTE_PGSIZE_64K  = 1UL << 16,
> + RTE_PGSIZE_16M  = 1UL << 24,
> +#ifdef RTE_ARCH_64
> + RTE_PGSIZE_16G  = 1ULL << 34
you don't need the "LL" here as long type is 64-bits on 64-bit systems. Changing
it to 1UL << 34 will keep all entries consistent.

[dpdk-dev] [PATCH] test-pmd: Fix pointer aliasing error

[Bruce Richardson]

On Wed, Dec 03, 2014 at 03:19:34PM +, Qiu, Michael wrote:
> On 2014/12/3 22:51, Richardson, Bruce wrote:
> > On Wed, Dec 03, 2014 at 01:59:58PM +, Qiu, Michael wrote:
> >> On 2014/12/3 19:43, Richardson, Bruce wrote:
> >>> On Wed, Dec 03, 2014 at 07:28:19PM +0800, Michael Qiu wrote:
>  app/test-pmd/csumonly.c: In function ?get_psd_sum?:
>  build/include/rte_ip.h:161: error: dereferencing pointer ?u16?
>   does break strict-aliasing rules
>  build/include/rte_ip.h:157: note: initialized from here
>   ...
> 
>  The root cause is that, compile enable strict aliasing by default,
>  while in function rte_raw_cksum() try to convert 'const char *'
>  to 'const uint16_t *'.
> 
> >>> What compiler version is this with? Is there any other way to fix this
> >>> other than disabling the compiler warnings. Turning off strict aliasing 
> >>> may
> >>> affect performance as it reduces the number of optimizations that the 
> >>> compiler
> >>> can perform.
> >> The compile version is:
> >>
> >> $ gcc -v
> >> Using built-in specs.
> >> Target: x86_64-redhat-linux
> >> ...
> >> gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
> >>
> >>
> >> The OS is centos6.5 x86_64
> >>
> >>
> >> Actually, another possible solution is, as gcc manual shows, use union.
> >> In function rte_raw_cksum() of lib/librte_net/rte_ip.h:
> >>
> >> static inline uint16_t
> >> rte_raw_cksum(const char *buf, size_t len){
> >> union {
> >> const char *ubuf;
> >> const uint16_t *uu16;
> >> } convert;
> >>
> >> convert.ubuf = buf;
> >> const uint16_t *u16 = convert.uu16;
> >> ...
> >> }
> >>
> >> This may be work, but not test yet.
> >>
> >> Any comments about this solution?
> > what happens if you make rte_raw_cksum take a void * (or const void *) 
> > parameter
> > instead of "const char *"?
> 
> "size_t len" is for type char, it is the the array size(for char array
> is byte numbers), if we use void *, the meaning maybe confuse I think.
That shouldn't be a big issue. We can rename it to "size" instead of "len" if
needed.

> But it should work with other code change.
> 
> Thanks,
> Michael
> >
> > /Bruce
> >
> 

[dpdk-dev] [PATCH] test-pmd: Fix pointer aliasing error

[Qiu, Michael]

On 2014/12/3 22:51, Richardson, Bruce wrote:
> On Wed, Dec 03, 2014 at 01:59:58PM +, Qiu, Michael wrote:
>> On 2014/12/3 19:43, Richardson, Bruce wrote:
>>> On Wed, Dec 03, 2014 at 07:28:19PM +0800, Michael Qiu wrote:
 app/test-pmd/csumonly.c: In function ?get_psd_sum?:
 build/include/rte_ip.h:161: error: dereferencing pointer ?u16?
does break strict-aliasing rules
 build/include/rte_ip.h:157: note: initialized from here
...

 The root cause is that, compile enable strict aliasing by default,
 while in function rte_raw_cksum() try to convert 'const char *'
 to 'const uint16_t *'.

>>> What compiler version is this with? Is there any other way to fix this
>>> other than disabling the compiler warnings. Turning off strict aliasing may
>>> affect performance as it reduces the number of optimizations that the 
>>> compiler
>>> can perform.
>> The compile version is:
>>
>> $ gcc -v
>> Using built-in specs.
>> Target: x86_64-redhat-linux
>> ...
>> gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
>>
>>
>> The OS is centos6.5 x86_64
>>
>>
>> Actually, another possible solution is, as gcc manual shows, use union.
>> In function rte_raw_cksum() of lib/librte_net/rte_ip.h:
>>
>> static inline uint16_t
>> rte_raw_cksum(const char *buf, size_t len){
>> union {
>> const char *ubuf;
>> const uint16_t *uu16;
>> } convert;
>>
>> convert.ubuf = buf;
>> const uint16_t *u16 = convert.uu16;
>> ...
>> }
>>
>> This may be work, but not test yet.
>>
>> Any comments about this solution?
> what happens if you make rte_raw_cksum take a void * (or const void *) 
> parameter
> instead of "const char *"?

"size_t len" is for type char, it is the the array size(for char array
is byte numbers), if we use void *, the meaning maybe confuse I think.
But it should work with other code change.

Thanks,
Michael
>
> /Bruce
>

[dpdk-dev] [PATCH] enic: fix warnings

[Sujith Sankar (ssujith)]

On 03/12/14 8:35 pm, "Thomas Monjalon"  wrote:

>2014-12-03 14:52, Sujith Sankar:
>> 
>> On 02/12/14 8:29 pm, "Thomas Monjalon" 
>>wrote:
>> 
>> >A lot of warnings were not seen because $(WERROR_FLAGS) was not set
>> >in the Makefile. But they appear with toolchains that enforce more
>>checks.
>> >
>> >-Wno-deprecated seems useless.
>> >-Wno-strict-aliasing is added to avoid false positives.
>> >
>> >This patch cleans up unused variable, unused functions, wrong types,
>> >static declarations, etc. A lot of functions have unused parameters;
>> >it suggests that more clean-up could be needed.
>> 
>> I shall look at it when I pull these changes to my repo.
>> What other toolchains did you check with?
>
>It's tested with many distributions, example CentOS 6.
>But adding the warnings as in this patch should be enough to test with
>any toolchain.

Thanks Thomas.  I shall look at the unused vars and get back with clean-up
patch.
Your patch looks good.  And I did a quick sanity test on my server, which
went through fine.

-Sujith
>
>-- 
>Thomas

[dpdk-dev] [PATCH v3] kni: create KNI interface in current network namespace

[Thomas Monjalon]

> > With this patch, KNI interface (e.g. vEth0) is created in the
> > network namespace where the DPDK application is running.
> > Otherwise, all interfaces are created in the default namespace
> > in the host.
> >
> > put_net() is required, since get_net_ns_by_pid() increments
> > the reference counter of the network namespace with get_net().
> >
> > Signed-off-by: Takayuki Usui 
> Signed-off-by: Nicolas Dichtel 

Applied

Thanks
-- 
Thomas

[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[Olga Shern]

Hi Tim, 

Can you please send the presentations from last Community Call.
We have Tetsuya's presentation,  if we can also get other presentations it will 
be great

Thanks
Olga


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> Sent: Tuesday, December 02, 2014 4:41 AM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00
> AM GMT
> 
> Hi Folks,
> 
> I attached slides that describe current progress of port hotplug feature.
> 
> Regards,
> Tetsuya
> 
> (2014/12/01 18:40), O'driscoll, Tim wrote:
> > Hi Tetsuya,
> >
> > It would be great if you could explain your work on hotplug at tomorrow's
> call. I think this is a topic that lots of people will be interested in.
> >
> > I'm not sure of the policy for sending attachments to the list. Perhaps 
> > that's
> something that Thomas can clarify. Can you send the slides to me anyway,
> just in case there's any problem with you presenting them in GoToMeeting
> tomorrow. I will also record the session and post the video for those who
> can't attend.
> >
> >
> > Tim
> >
> >> -Original Message-
> >> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> >> Sent: Monday, December 1, 2014 2:50 AM
> >> To: O'driscoll, Tim; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] Next Community Call, Tuesday 2nd December,
> >> 8:00 AM GMT
> >>
> >> Hi Tim,
> >>
> >> Could I explain port hotplug function at next conference call?
> >> For this explanation, I've prepared slides. could I send a PDF to this ML?
> >> That slides describe what is the function, how it works and what is
> >> current progress.
> >> And it's under 100KB.
> >>
> >> Regards,
> >> Tetsuya
> >>
> >> (2014/11/22 1:08), O'driscoll, Tim wrote:
> >>> We're going to hold our next community call on Tuesday 2nd December.
> >> This time, we're going to try a time that's more suitable for
> >> participants in Asia, so we're going to hold it at 8:00 AM GMT. The
> >> meeting time in a variety of timezones is included below.
> >>> Generally, GoToMeeting worked well last time, although there was a
> >> limitation that Neil was unable to present slides as he joined from a
> >> Linux system. We'll stick with GoToMeeting again this time as we
> >> don't yet have a better solution. Details for joining the GoToMeeting
> >> session are included below.
> >>> I'll record the session again and post the video to YouTube
> >>> afterwards for
> >> anybody who can't make it. This seemed to work well last time, and as
> >> Kevin pointed out, the audio quality on the recording is good.
> >>> For the agenda, we'd like to discuss the following:
> >>> ? Remaining 2.0 candidate features, especially PCI Hotplug as
> >>> there's been a
> >> lot of discussion on that on the mailing list. Hopefully Tetsuya
> >> Mukawa can join us to describe his work on this.
> >>> ? DPDK Test Suite. We hope to announce the release of this next week.
> >> Waterman Cao and Yong (Marvin) Liu from our Shanghai team will
> >> describe the functionality and benefits of this.
> >>>
> >>> Meeting Time:
> >>> Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC
> >>> Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1
> >>> hour Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST
> >>> UTC+2 hours Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00
> AM
> >>> MSK UTC+3
> >> hours
> >>> New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM
> >>> IST
> >> UTC+5:30 hours
> >>> Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014
> >>> at
> >> 4:00:00 PM CST UTC+8 hours
> >>> Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9
> >>> hours San Francisco (U.S.A. - California) Midnight between Monday,
> >>> December 1,
> >> 2014 and Tuesday, December 2, 2014 PST UTC-8 hours
> >>> Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM
> >>> MST
> >> UTC-7 hours
> >>> New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM
> >> EST UTC-5 hours
> >>> Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM
> >>> EST
> >> UTC-5 hours
> >>> Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00
> >>>
> >>>
> >>> GoToMeeting Details:
> >>> To join, follow the meeting link:
> >> https://global.gotomeeting.com/join/772753069. This will start the
> >> GoToMeeting web viewer. You then have two options for audio:
> >>> 1. To use your computer's audio via a headset, you need to switch to
> >>> the
> >> desktop version of GoToMeeting. You can do this by clicking the
> >> GoToMeeting icon on the top right hand side of the web viewer, and
> >> then selecting "Switch to the desktop version". The desktop version
> >> will need to download and install, so if you plan to use this you may
> >> want to get it set up in advance. Once it starts, under the Audio
> >> section, you can select "Mic & Speakers". The desktop version is only
> >> available for Windows and Mac, so if you're using

[dpdk-dev] [PATCH 2/3] docs: adjust line lengths in FreeBSD GSG rst files

[Bruce Richardson]

On Wed, Dec 03, 2014 at 02:23:44PM +0100, Thomas Monjalon wrote:
> 2014-11-24 15:48, Bruce Richardson:
> > The FreeBSD GSG rst files had very inconsistent line lengths for text
> > within paragraph blocks. Sometimes a line would be very short, while often
> > lines would be quite long.
> > This patch adjusts the formatting of the rst files so that lines break
> > at approx the 80-character mark, as is standard in the DPDK source code.
> 
> I'm not sure we should be strict with line lengths in the doc.
> The most important thing is to limit the wrapping impact of future patches.
> Starting a new sentence at the beginning of the line is often a good way
> to keep context lines unchanged when updating only one sentence.
> Don't forget that a carriage return in rst has no impact on generated doc.
> 
> -- 
> Thomas

Hi Thomas,
I agree that we shouldn't be strict, but the variance in line length was really
huge, and shorter lines are always easier to read. Even my patch just limited
line length to somethign between 80-90 depending on wording, since a hard-80 I
feel is too extreme.

/Bruce

[dpdk-dev] [PATCH] enic: fix warnings

[Sujith Sankar (ssujith)]

On 02/12/14 8:29 pm, "Thomas Monjalon"  wrote:

>A lot of warnings were not seen because $(WERROR_FLAGS) was not set
>in the Makefile. But they appear with toolchains that enforce more checks.
>
>-Wno-deprecated seems useless.
>-Wno-strict-aliasing is added to avoid false positives.
>
>This patch cleans up unused variable, unused functions, wrong types,
>static declarations, etc. A lot of functions have unused parameters;
>it suggests that more clean-up could be needed.

I shall look at it when I pull these changes to my repo.
What other toolchains did you check with?

>
>Signed-off-by: Thomas Monjalon 
>---
> lib/librte_pmd_enic/Makefile |  3 +-
> lib/librte_pmd_enic/enic.h   |  4 +-
> lib/librte_pmd_enic/enic_ethdev.c| 20 -
> lib/librte_pmd_enic/enic_main.c  | 81
>+++-
> lib/librte_pmd_enic/vnic/vnic_cq.h   |  1 -
> lib/librte_pmd_enic/vnic/vnic_dev.c  | 22 +++---
> lib/librte_pmd_enic/vnic/vnic_dev.h  |  4 +-
> lib/librte_pmd_enic/vnic/vnic_intr.c |  5 ---
> 8 files changed, 46 insertions(+), 94 deletions(-)
>
>diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile
>index 948ec96..a2a623f 100644
>--- a/lib/librte_pmd_enic/Makefile
>+++ b/lib/librte_pmd_enic/Makefile
>@@ -39,7 +39,8 @@ LIB = librte_pmd_enic.a
> 
> CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/vnic/
> CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/
>-CFLAGS += -O3 -Wno-deprecated
>+CFLAGS += -O3
>+CFLAGS += $(WERROR_FLAGS) -Wno-strict-aliasing
> 
> VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src
> 
>diff --git a/lib/librte_pmd_enic/enic.h b/lib/librte_pmd_enic/enic.h
>index f128e64..c43417c 100644
>--- a/lib/librte_pmd_enic/enic.h
>+++ b/lib/librte_pmd_enic/enic.h
>@@ -134,7 +134,7 @@ struct enic {
>   unsigned int intr_count;
> };
> 
>-static inline unsigned int enic_cq_rq(struct enic *enic, unsigned int rq)
>+static inline unsigned int enic_cq_rq(__rte_unused struct enic *enic,
>unsigned int rq)
> {
>   return rq;
> }
>@@ -144,7 +144,7 @@ static inline unsigned int enic_cq_wq(struct enic
>*enic, unsigned int wq)
>   return enic->rq_count + wq;
> }
> 
>-static inline unsigned int enic_msix_err_intr(struct enic *enic)
>+static inline unsigned int enic_msix_err_intr(__rte_unused struct enic
>*enic)
> {
>   return 0;
> }
>diff --git a/lib/librte_pmd_enic/enic_ethdev.c
>b/lib/librte_pmd_enic/enic_ethdev.c
>index f582152..9cb 100644
>--- a/lib/librte_pmd_enic/enic_ethdev.c
>+++ b/lib/librte_pmd_enic/enic_ethdev.c
>@@ -67,7 +67,7 @@ RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO,
>PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
> 
> static int enicpmd_fdir_remove_perfect_filter(struct rte_eth_dev
>*eth_dev,
>   struct rte_fdir_filter *fdir_filter,
>-  uint16_t soft_id)
>+  __rte_unused uint16_t soft_id)
> {
>   struct enic *enic = pmd_priv(eth_dev);
> 
>@@ -76,7 +76,7 @@ static int enicpmd_fdir_remove_perfect_filter(struct
>rte_eth_dev *eth_dev,
> }
> 
> static int enicpmd_fdir_add_perfect_filter(struct rte_eth_dev *eth_dev,
>-  struct rte_fdir_filter *fdir_filter, uint16_t soft_id,
>+  struct rte_fdir_filter *fdir_filter, __rte_unused uint16_t soft_id,
>   uint8_t queue, uint8_t drop)
> {
>   struct enic *enic = pmd_priv(eth_dev);
>@@ -103,7 +103,7 @@ static void enicpmd_dev_tx_queue_release(void *txq)
> static int enicpmd_dev_setup_intr(struct enic *enic)
> {
>   int ret;
>-  int index;
>+  unsigned int index;
> 
>   ENICPMD_FUNC_TRACE();
> 
>@@ -134,7 +134,7 @@ static int enicpmd_dev_tx_queue_setup(struct
>rte_eth_dev *eth_dev,
>   uint16_t queue_idx,
>   uint16_t nb_desc,
>   unsigned int socket_id,
>-  const struct rte_eth_txconf *tx_conf)
>+  __rte_unused const struct rte_eth_txconf *tx_conf)
> {
>   int ret;
>   struct enic *enic = pmd_priv(eth_dev);
>@@ -215,7 +215,7 @@ static int enicpmd_dev_rx_queue_setup(struct
>rte_eth_dev *eth_dev,
>   uint16_t queue_idx,
>   uint16_t nb_desc,
>   unsigned int socket_id,
>-  const struct rte_eth_rxconf *rx_conf,
>+  __rte_unused const struct rte_eth_rxconf *rx_conf,
>   struct rte_mempool *mp)
> {
>   int ret;
>@@ -334,7 +334,7 @@ static void enicpmd_dev_close(struct rte_eth_dev
>*eth_dev)
> }
> 
> static int enicpmd_dev_link_update(struct rte_eth_dev *eth_dev,
>-  int wait_to_complete)
>+  __rte_unused int wait_to_complete)
> {
>   struct enic *enic = pmd_priv(eth_dev);
>   int ret;
>@@ -428,7 +428,7 @@ static void enicpmd_dev_allmulticast_disable(struct
>rte_eth_dev *eth_dev)
> 
> static void enicpmd_add_mac_addr(struct rte_eth_dev *eth_dev,
>   struct ether_addr *mac_addr,
>-  uint32_t index, uint32_t pool)
>+  __rte_unused uint32_t index, __rte_unused uint32_t pool)
> {
>   struct enic *enic = pmd_priv(eth_dev);
> 
>@@ -436,7 +436,7 @@ static void enicpmd_add_mac_addr(struct rte_eth_dev
>*eth_dev,
>   enic_set_mac_address(enic, mac_addr->addr_bytes);
> }

[dpdk-dev] [PATCH] test-pmd: Fix pointer aliasing error

[Bruce Richardson]

On Wed, Dec 03, 2014 at 01:59:58PM +, Qiu, Michael wrote:
> On 2014/12/3 19:43, Richardson, Bruce wrote:
> > On Wed, Dec 03, 2014 at 07:28:19PM +0800, Michael Qiu wrote:
> >> app/test-pmd/csumonly.c: In function ?get_psd_sum?:
> >> build/include/rte_ip.h:161: error: dereferencing pointer ?u16?
> >>does break strict-aliasing rules
> >> build/include/rte_ip.h:157: note: initialized from here
> >>...
> >>
> >> The root cause is that, compile enable strict aliasing by default,
> >> while in function rte_raw_cksum() try to convert 'const char *'
> >> to 'const uint16_t *'.
> >>
> > What compiler version is this with? Is there any other way to fix this
> > other than disabling the compiler warnings. Turning off strict aliasing may
> > affect performance as it reduces the number of optimizations that the 
> > compiler
> > can perform.
> 
> The compile version is:
> 
> $ gcc -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> ...
> gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
> 
> 
> The OS is centos6.5 x86_64
> 
> 
> Actually, another possible solution is, as gcc manual shows, use union.
> In function rte_raw_cksum() of lib/librte_net/rte_ip.h:
> 
> static inline uint16_t
> rte_raw_cksum(const char *buf, size_t len){
> union {
> const char *ubuf;
> const uint16_t *uu16;
> } convert;
> 
> convert.ubuf = buf;
> const uint16_t *u16 = convert.uu16;
> ...
> }
> 
> This may be work, but not test yet.
> 
> Any comments about this solution?

what happens if you make rte_raw_cksum take a void * (or const void *) parameter
instead of "const char *"?

/Bruce

[dpdk-dev] [PATCH 4/4] doc: Various document fixes in testpmd UG

[Thomas Monjalon]

2014-12-03 13:26, De Lara Guarch, Pablo:
> Hi Thomas,
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Wednesday, December 03, 2014 1:18 PM
> > To: De Lara Guarch, Pablo
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 4/4] doc: Various document fixes in testpmd
> > UG
> > 
> > 2014-11-15 19:13, Pablo de Lara:
> > > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > [...]
> > > -Quit to prompt in Linux or reboot on Baremetal:
> > > +Quit to prompt in Linux/FreeBSD or reboot on Baremetal:
> > 
> > Bare-metal traces have been removed.
> You are looking at the v1, I sent a v5 last Monday without that part.

Exact, sorry.
So I guess Bernard should update his branch (I was looking at dpdk-doc):
http://dpdk.org/browse/next/dpdk-doc/commit/?id=fc888aeff9fe

-- 
Thomas

[dpdk-dev] [PATCH 2/2] doc: remove references to intel dpdk in linux_gsg

[Thomas Monjalon]

2014-12-02 23:41, Siobhan Butler:
> Adjusted line lengths and removed references to Intel which
> are no longer relevant in linux gsg.

The patch is really hard to read because you mix wrapping and rewording.
I think it's not important to adjust line lengths, especially when removing
some words.

-- 
Thomas

[dpdk-dev] [PATCH 2/3] docs: adjust line lengths in FreeBSD GSG rst files

[Thomas Monjalon]

2014-11-24 15:48, Bruce Richardson:
> The FreeBSD GSG rst files had very inconsistent line lengths for text
> within paragraph blocks. Sometimes a line would be very short, while often
> lines would be quite long.
> This patch adjusts the formatting of the rst files so that lines break
> at approx the 80-character mark, as is standard in the DPDK source code.

I'm not sure we should be strict with line lengths in the doc.
The most important thing is to limit the wrapping impact of future patches.
Starting a new sentence at the beginning of the line is often a good way
to keep context lines unchanged when updating only one sentence.
Don't forget that a carriage return in rst has no impact on generated doc.

-- 
Thomas

[dpdk-dev] [PATCH 4/4] doc: Various document fixes in testpmd UG

[Thomas Monjalon]

2014-11-15 19:13, Pablo de Lara:
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
[...]
> -Quit to prompt in Linux or reboot on Baremetal:
> +Quit to prompt in Linux/FreeBSD or reboot on Baremetal:

Bare-metal traces have been removed.

-- 
Thomas

[dpdk-dev] [PATCH] test-pmd: Fix pointer aliasing error

[Qiu, Michael]

On 2014/12/3 19:43, Richardson, Bruce wrote:
> On Wed, Dec 03, 2014 at 07:28:19PM +0800, Michael Qiu wrote:
>> app/test-pmd/csumonly.c: In function ?get_psd_sum?:
>> build/include/rte_ip.h:161: error: dereferencing pointer ?u16?
>>  does break strict-aliasing rules
>> build/include/rte_ip.h:157: note: initialized from here
>>  ...
>>
>> The root cause is that, compile enable strict aliasing by default,
>> while in function rte_raw_cksum() try to convert 'const char *'
>> to 'const uint16_t *'.
>>
> What compiler version is this with? Is there any other way to fix this
> other than disabling the compiler warnings. Turning off strict aliasing may
> affect performance as it reduces the number of optimizations that the compiler
> can perform.

The compile version is:

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
...
gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)


The OS is centos6.5 x86_64


Actually, another possible solution is, as gcc manual shows, use union.
In function rte_raw_cksum() of lib/librte_net/rte_ip.h:

static inline uint16_t
rte_raw_cksum(const char *buf, size_t len){
union {
const char *ubuf;
const uint16_t *uu16;
} convert;

convert.ubuf = buf;
const uint16_t *u16 = convert.uu16;
...
}

This may be work, but not test yet.

Any comments about this solution?

Thanks,
Michael
>
> /Bruce
>
>> Need to add CFLAG '-Wno-strict-aliasing' to avoid this issue.
>>
>> Signed-off-by: Michael Qiu 
>> ---
>>  app/test-pmd/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
>> index 97dc2e6..995c874 100644
>> --- a/app/test-pmd/Makefile
>> +++ b/app/test-pmd/Makefile
>> @@ -38,7 +38,7 @@ ifeq ($(CONFIG_RTE_TEST_PMD),y)
>>  #
>>  APP = testpmd
>>  
>> -CFLAGS += -O3
>> +CFLAGS += -O3 -Wno-strict-aliasing
>>  CFLAGS += $(WERROR_FLAGS)
>>  
>>  ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
>> -- 
>> 1.9.3
>>

[dpdk-dev] [PATCH 4/4] doc: Various document fixes in testpmd UG

[De Lara Guarch, Pablo]

Hi Thomas,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, December 03, 2014 1:18 PM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 4/4] doc: Various document fixes in testpmd
> UG
> 
> 2014-11-15 19:13, Pablo de Lara:
> > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> [...]
> > -Quit to prompt in Linux or reboot on Baremetal:
> > +Quit to prompt in Linux/FreeBSD or reboot on Baremetal:
> 
> Bare-metal traces have been removed.
You are looking at the v1, I sent a v5 last Monday without that part.

> 
> --
> Thomas

[dpdk-dev] [PATCH v5 2/3] mbuf:add three TX ol_flags and repalce PKT_TX_VXLAN_CKSUM

[Ananyev, Konstantin]

Hi Oliver,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Wednesday, December 03, 2014 11:41 AM
> To: Liu, Jijiang; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 2/3] mbuf:add three TX ol_flags and repalce 
> PKT_TX_VXLAN_CKSUM
> 
> Hi Jijiang,
> 
> On 12/02/2014 04:06 PM, Jijiang Liu wrote:
> > Replace PKT_TX_VXLAN_CKSUM with PKT_TX_UDP_TUNNEL_PKT in order to indicate 
> > a packet is an UDP tunneling packet, and
> introduce 3 TX offload flags for outer IP TX checksum, which are 
> PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV4 and
> PKT_TX_OUTER_IPV6 respectively;Rework csum forward engine and i40e PMD due to 
> these changes.
> >
> > Signed-off-by: Jijiang Liu 
> > ---
> >   app/test-pmd/csumonly.c |9 +++--
> >   lib/librte_mbuf/rte_mbuf.c  |7 ++-
> >   lib/librte_mbuf/rte_mbuf.h  |   11 ++-
> >   lib/librte_pmd_i40e/i40e_rxtx.c |6 +++---
> >   4 files changed, 26 insertions(+), 7 deletions(-)
> >
> > diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> > index d8c080a..9094967 100644
> > --- a/app/test-pmd/csumonly.c
> > +++ b/app/test-pmd/csumonly.c
> > @@ -257,7 +257,7 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
> > outer_ethertype,
> > uint64_t ol_flags = 0;
> >
> > if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
> > -   ol_flags |= PKT_TX_VXLAN_CKSUM;
> > +   ol_flags |= PKT_TX_UDP_TUNNEL_PKT;
> >
> > if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) {
> > ipv4_hdr->hdr_checksum = 0;
> > @@ -470,7 +470,12 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
> > { PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK },
> > { PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK },
> > { PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK },
> > -   { PKT_TX_VXLAN_CKSUM, PKT_TX_VXLAN_CKSUM },
> > +   { PKT_TX_UDP_TUNNEL_PKT, PKT_TX_UDP_TUNNEL_PKT 
> > },
> > +   { PKT_TX_IPV4, PKT_TX_IPV4 },
> > +   { PKT_TX_IPV6, PKT_TX_IPV6 },
> > +   { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM 
> > },
> > +   { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4 },
> > +   { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6 },
> > { PKT_TX_TCP_SEG, PKT_TX_TCP_SEG },
> 
> I still think having a flag IPV4 + another flag IP_CHECKSUM is not
> appropriate.

Sorry, didn't get you here.
Are you talking about our discussion should PKT_TX_IP_CKSUM and PKT_TX_IPV4 be 
mutually exclusive or not?

> I though Konstantin agreed on other flags, but I may
> have misunderstood:
> 
> http://dpdk.org/ml/archives/dev/2014-November/009070.html

In that mail, I was talking about my suggestion to make  PKT_TX_IP_CKSUM, 
PKT_TX_IPV4 and PKT_TX_IPV6 to occupy 2 bits.
Something like:
#define PKT_TX_IP_CKSUM (1 << X)
#define PKT_TX_IPV6 (2 << X)
#define PKT_TX_IPV4 (3 << X)

"Even better, if we can squeeze these 3 flags into 2 bits.
Would save us 2 bits, plus might be handy, as in the PMD you can do:

switch (ol_flags & TX_L3_MASK) {
case TX_IPV4:
   ...
   break;
case TX_IPV6:
   ...
   break;
case TX_IP_CKSUM:
   ...
   break;
}"

As you pointed out, it will break backward compatibility.
I agreed with that and self-NACKed it.

> 
> 
> Olivier

[dpdk-dev] [PATCH v5 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

[Olivier MATZ]

Hi Jijiang,

On 12/02/2014 04:06 PM, Jijiang Liu wrote:
> Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and 
> outer_l3_len field, and rework csum forward engine and i40e PMD due to  these 
> changes.
>
> Signed-off-by: Jijiang Liu 
> ---
>   app/test-pmd/csumonly.c |   58 
> +--
>   lib/librte_mbuf/rte_mbuf.h  |4 +-
>   lib/librte_pmd_i40e/i40e_rxtx.c |   38 +
>   3 files changed, 53 insertions(+), 47 deletions(-)
>

One more thing about the arguments of testpmd, thay may be changed
a bit to make it clearer. We may also remove the distinction between
udp/tcp/sctp and just have l4 instead.

We don't need to add a tunnel-type argument in the testpmd
command line, because the application is already able to parse
the packet and can set the proper tunnel flag by itself.

This is the current description of the csumonly forward engine:

  * Receive a burst of packets, and for each packet:
  *  - parse packet, and try to recognize a supported packet type (1)
  *  - if it's not a supported packet type, don't touch the packet, else:
  *  - modify the IPs in inner headers and in outer headers if any
  *  - reprocess the checksum of all supported layers. This is done in SW
  *or HW, depending on testpmd command line configuration
  *  - if TSO is enabled in testpmd command line, also flag the mbuf for
  *TCP segmentation offload (this implies HW TCP checksum)
  * Then transmit packets on the output port.
  *
  * (1) Supported packets are:
  *   Ether / (vlan) / IP|IP6 / UDP|TCP|SCTP .
  *   Ether / (vlan) / outer IP|IP6 / outer UDP / VxLAN / Ether / IP|IP6
  */ UDP|TCP|SCTP
  *
  * The testpmd command line for this forward engine sets the flags
  * TESTPMD_TX_OFFLOAD_* in ports[tx_port].tx_ol_flags. They control
  * wether a checksum must be calculated in software or in hardware. The
  * IP, UDP, TCP and SCTP flags always concern the inner layer.  The
  * VxLAN flag concerns the outer IP and UDP layer (if packet is
  * recognized as a vxlan packet).


This would give:

   tx_cksum set (outer-ip|outer-l4|ip|l4) (hw|sw) (port_id)


A/ outer-ip=sw, outer-l4=sw, ip=sw, l4=sw

   Ether / IP / UDP
 IP, UDP checksum reprocessed in sw

   Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
 IP1, UDP1, IP2, UDP2 checksums reprocessed in sw



B/ outer-ip=hw, outer-l4=hw, ip=sw, l4=sw

   Ether / IP / UDP
 IP, UDP checksum reprocessed in sw

   Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
 IP1, UDP1 checksums reprocessed in hw (using l2_len, l3_len)
 IP2, UDP2 checksums reprocessed in sw



C/ outer-ip=hw, outer-l4=hw, ip=hw, l4=hw

   Ether / IP / UDP
 IP, UDP checksum reprocessed in hw (using l2_len, l3_len)

   Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
 IP1 checksums reprocessed in hw (using outer_l2_len, outer_l3_len)
 UDP1 checksum must be 0 in packet (I think it's not supported by hw
or driver today)
 IP2, UDP2 checksums reprocessed in hw (using l2_len, l3_len)



D/ outer-ip=sw, outer-l4=sw, ip=hw, l4=hw

   Ether / IP / UDP
 IP, UDP checksum reprocessed in hw (using l2_len and l3_len)

   Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
 not supported, we are not able to calculate the outer
 checksum in sw as some inner fields will be filled by the hw


What is your opinion?

Regards,
Olivier

[dpdk-dev] [PATCH v5 2/3] mbuf:add three TX ol_flags and repalce PKT_TX_VXLAN_CKSUM

[Olivier MATZ]

Hi Jijiang,

On 12/02/2014 04:06 PM, Jijiang Liu wrote:
> Replace PKT_TX_VXLAN_CKSUM with PKT_TX_UDP_TUNNEL_PKT in order to indicate a 
> packet is an UDP tunneling packet, and introduce 3 TX offload flags for outer 
> IP TX checksum, which are PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV4 and 
> PKT_TX_OUTER_IPV6 respectively;Rework csum forward engine and i40e PMD due to 
> these changes.
>
> Signed-off-by: Jijiang Liu 
> ---
>   app/test-pmd/csumonly.c |9 +++--
>   lib/librte_mbuf/rte_mbuf.c  |7 ++-
>   lib/librte_mbuf/rte_mbuf.h  |   11 ++-
>   lib/librte_pmd_i40e/i40e_rxtx.c |6 +++---
>   4 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index d8c080a..9094967 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -257,7 +257,7 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
> outer_ethertype,
>   uint64_t ol_flags = 0;
>
>   if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
> - ol_flags |= PKT_TX_VXLAN_CKSUM;
> + ol_flags |= PKT_TX_UDP_TUNNEL_PKT;
>
>   if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) {
>   ipv4_hdr->hdr_checksum = 0;
> @@ -470,7 +470,12 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
>   { PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK },
>   { PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK },
>   { PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK },
> - { PKT_TX_VXLAN_CKSUM, PKT_TX_VXLAN_CKSUM },
> + { PKT_TX_UDP_TUNNEL_PKT, PKT_TX_UDP_TUNNEL_PKT 
> },
> + { PKT_TX_IPV4, PKT_TX_IPV4 },
> + { PKT_TX_IPV6, PKT_TX_IPV6 },
> + { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM 
> },
> + { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4 },
> + { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6 },
>   { PKT_TX_TCP_SEG, PKT_TX_TCP_SEG },

I still think having a flag IPV4 + another flag IP_CHECKSUM is not
appropriate. I though Konstantin agreed on other flags, but I may
have misunderstood:

http://dpdk.org/ml/archives/dev/2014-November/009070.html


Olivier

[dpdk-dev] [PATCH v5 1/3] mbuf:redefine three TX ol_flags

[Olivier MATZ]

Hi Jijiang,

On 12/02/2014 04:06 PM, Jijiang Liu wrote:
> The reason of redefining the PKT_TX_IPV4 and the PKT_TX_IPV6 is listed below,
> It will avoid to send a packet with a bad info:
>- we receive a Ether/IP6/IP4/L4/data packet
>- the driver sets PKT_RX_IPV6_HDR
>- the stack decapsulates IP6
>- the stack sends the packet, it has the PKT_TX_IPV6 flag but it's an IPv4 
> packet.
>
> Signed-off-by: Jijiang Liu 
> ---
>   lib/librte_mbuf/rte_mbuf.h |   10 +-
>   1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 2e5fce5..cbadf8e 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -141,13 +141,13 @@ extern "C" {
>   #define PKT_TX_IP_CKSUM  (1ULL << 54) /**< IP cksum of TX pkt. computed 
> by NIC. */
>   #define PKT_TX_IPV4_CSUM PKT_TX_IP_CKSUM /**< Alias of PKT_TX_IP_CKSUM. 
> */
>
> -/** Tell the NIC it's an IPv4 packet. Required for L4 checksum offload or 
> TSO. */
> -#define PKT_TX_IPV4  PKT_RX_IPV4_HDR
> +/** Packet is IPv4 without requiring IP checksum offload. */
> +#define PKT_TX_IPV4  (1ULL << 55)
>
> -/** Tell the NIC it's an IPv6 packet. Required for L4 checksum offload or 
> TSO. */
> -#define PKT_TX_IPV6  PKT_RX_IPV6_HDR
> +/** Tell the NIC it's an IPv6 packet.*/
> +#define PKT_TX_IPV6  (1ULL << 56)
>
> -#define PKT_TX_VLAN_PKT  (1ULL << 55) /**< TX packet is a 802.1q VLAN 
> packet. */
> +#define PKT_TX_VLAN_PKT  (1ULL << 57) /**< TX packet is a 802.1q VLAN 
> packet. */
>
>   /* Use final bit of flags to indicate a control mbuf */
>   #define CTRL_MBUF_FLAG   (1ULL << 63) /**< Mbuf contains control data */
>

Acked-by: Olivier Matz 

[dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

[Olivier MATZ]

Hi Konstantin,

On 12/03/2014 12:11 PM, Ananyev, Konstantin wrote:
 Let's discuss the two possibilities.

 1) outer_lx_len fields are introduced.
 In this case, the stack should have knowledge that it is processing
 tunneled packets to use outer_lx_len rather than lx_len,
 or stack should always use outer_lx_len packet and move those fields to
 lx_len packets if no tunneling occurs...
 I think it will induce extra processing that does not seem to be really
 needed.

 2) inner_lx_len fields are introduced.
 In this case, the stack first uses lx_len fields. When packet should be
 tunneled, lx_len fields are moved to inner_lx_len fields.
 Then the stack can process the outer layer and still use the lx_len fields.
>>>
>>> Not sure, that I understood why 2) is better than 1).
>>> Let say,  you have a 'normal' (non-tunnelling) packet: ether/IP/TCP
>>> In that case you still use mbuf's l2_len/l3_len/l4_len fields and setup 
>>> ol_flags as usual.
>>> Then later, you decided to 'tunnel' that packet.
>>> So you just fill mbuf's outer_l2_len/outer_l3_len, setup TX_OUTER_* and 
>>> TX_TUNNEL_* bits in ol_flags and probably update l2_len.
>>> l3_len/l4_len and ol_flags bits set for them remain intact.
>>> That's with 1)
>>>
>>> With 2) - you'll have to move l3_len/l4_len to inner_lx_len.
>>> And I suppose ol_flags values too:
>>> ol_flags &= ~PKT_ IP_CKSUM;
>>> ol_flgas  |=  PKT_INNER_IP_CKSUM
>>> ?
>>> And same for L4_CKSUM flags too?
>>
>> After reading Didier's mail, I start to be convinced that keeping inner
>> may be better than outer. From a network stack architecture point of
>> view, 2) looks better:
>>
>> - the functions in the network stack that write the Ether/IP header
>> always deal with l2_len/l3_len, whatever it's a tunnel or not.
>>
>> - the function that adds the tunnel header moves the l2_len/l3_len and
>> the flags to inner_l2_len/inner_l3_len and inner_flags.
>
> Hmm, still don't understand you here.
> Why all that you mentioned above suddenly become 'better'?
> Here is you original suggestion about introducing 'outer_lx_len':
> http://dpdk.org/ml/archives/dev/2014-November/008268.html
> As you pointed, it is a clean and straightforward way to extend DPDK HW TX 
> offload API with tunnelling support.
> And we agreed with you here.
>
>  From other side, 2) approach looks like a mess:
> If packet is going to be tunnelled, the upper layer has to:
> 1.  move lx_len values to inner_lx_len.
> 2. move PKT_TX_*_CKSUM bit to PKT_TX_INNER_*_CKSUM bits in ol_flags.
> Plus in the mbuf we'll either have to introduce 
> PKT_TX_INNER_(TCP|UDP|SCTP)_CKSUM flags
> (otherwise we'll have a weird situation when PKT_TX_IP_CKSUM we'll be for 
> outer IP header, but
> PKT_TX_TCP_CKSUM will be for inner).
>
> So, from DPDK perspective, 2) looks like a waste of bits in ol_flags and 
> unnecessary complication.
> At least to me.
> You are talking about 'the network stack', but as I know at dpdk.org we don't 
> have any open sourced L3/L4 stack supported.
>  From other side - in DPDK we just adding fields into mbuf for TX tunnelling.
> So if any of the existing commercial stacks already support tunnelling - they 
> should have their own fields for that in their own packet metadata structure.
> Which means - they somehow have to copy information from their packet 
> structure into mbuf anyway.
> If they don't support tunnelling yet and plan to use mbuf directly (without 
> copying info into their own packet metadata structure),
> I suppose they can adopt  the DPDK approach.
> So, from my point - let's implement it in a way that makes most sense from 
> DPDK perspective: 1).

OK. your argumentation makes sense even though I think DPDK aims to be
a SDK for building network applications or stacks and should ease the
work done in application. But this is something we can handle in the
stack if the API is properly defined in DPDK.

Anyway, we need to find a way to conclude on this :)
And it does not prevent us to think again about it for 2.0, if a
dev_prep_tx() function is introduced.

I still have few comments on the v5 patch from Jijiang but I think we
can converge soon.

Regards,
Olivier

[dpdk-dev] [PATCH v3] kni: create KNI interface in current network namespace

[Nicolas Dichtel]

Le 03/12/2014 02:37, Takayuki Usui a ?crit :
> With this patch, KNI interface (e.g. vEth0) is created in the
> network namespace where the DPDK application is running.
> Otherwise, all interfaces are created in the default namespace
> in the host.
>
> put_net() is required, since get_net_ns_by_pid() increments
> the reference counter of the network namespace with get_net().
>
> Signed-off-by: Takayuki Usui 
Signed-off-by: Nicolas Dichtel 

[dpdk-dev] [PATCH 2/2] doc: remove references to intel dpdk in linux_gsg

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Tuesday, December 2, 2014 11:41 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 2/2] doc: remove references to intel dpdk in 
> linux_gsg
> 
> Adjusted line lengths and removed references to Intel which
> are no longer relevant in linux gsg.
> 
> Signed-off-by: Siobhan Butler 


Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH] test-pmd: Fix pointer aliasing error

[Bruce Richardson]

On Wed, Dec 03, 2014 at 07:28:19PM +0800, Michael Qiu wrote:
> app/test-pmd/csumonly.c: In function ?get_psd_sum?:
> build/include/rte_ip.h:161: error: dereferencing pointer ?u16?
>   does break strict-aliasing rules
> build/include/rte_ip.h:157: note: initialized from here
>   ...
> 
> The root cause is that, compile enable strict aliasing by default,
> while in function rte_raw_cksum() try to convert 'const char *'
> to 'const uint16_t *'.
>

What compiler version is this with? Is there any other way to fix this
other than disabling the compiler warnings. Turning off strict aliasing may
affect performance as it reduces the number of optimizations that the compiler
can perform.

/Bruce

> Need to add CFLAG '-Wno-strict-aliasing' to avoid this issue.
> 
> Signed-off-by: Michael Qiu 
> ---
>  app/test-pmd/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
> index 97dc2e6..995c874 100644
> --- a/app/test-pmd/Makefile
> +++ b/app/test-pmd/Makefile
> @@ -38,7 +38,7 @@ ifeq ($(CONFIG_RTE_TEST_PMD),y)
>  #
>  APP = testpmd
>  
> -CFLAGS += -O3
> +CFLAGS += -O3 -Wno-strict-aliasing
>  CFLAGS += $(WERROR_FLAGS)
>  
>  ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
> -- 
> 1.9.3
> 

[dpdk-dev] [PATCH 1/2] doc: updated i40e enabling additonal fnct in gsg

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Tuesday, December 2, 2014 11:41 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/2] doc: updated i40e enabling additonal fnct in 
> gsg
> 
> Updated the i40e Enabling Additional Functionality section (5.7) of DPDK 
> Getting Started Guide.
> 
> Signed-off-by: Siobhan Butler 
> 
> Signed-off-by: Helin Zhang 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v2] Fix two compile issues with i686 platform

[Qiu, Michael]

Hi all,

Any comments on this patch?

It is really a big issue in dpdk1.8-rc2 and blocked the testing on i686
platform.

Thanks,
Michael
On 12/3/2014 4:11 PM, Michael Qiu wrote:
> lib/librte_eal/linuxapp/eal/eal_memory.c:324:4: error: comparison
> is always false due to limited range of data type [-Werror=type-limits]
> || (hugepage_sz == RTE_PGSIZE_16G)) {
> ^
> cc1: all warnings being treated as errors
>
> lib/librte_eal/linuxapp/eal/eal.c(461): error #2259: non-pointer
> conversion from "long long" to "void *" may lose significant bits
>RTE_PTR_ALIGN_CEIL((uintptr_t)addr, RTE_PGSIZE_16M);
>
> This was introuduced by commit b77b5639:
> mem: add huge page sizes for IBM Power
>
> The root cause is that size_t and uintptr_t are 32-bit in i686
> platform, but RTE_PGSIZE_16M and RTE_PGSIZE_16G are always 64-bit.
>
> Define RTE_PGSIZE_16G only in 64 bit platform to avoid
> this issue.
>
> Signed-off-by: Michael Qiu 
> ---
>  app/test/test_memzone.c| 18 --
>  lib/librte_eal/common/eal_common_memzone.c |  2 ++
>  lib/librte_eal/common/include/rte_memory.h | 14 --
>  lib/librte_eal/linuxapp/eal/eal_memory.c   | 12 +---
>  4 files changed, 27 insertions(+), 19 deletions(-)
>
> diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
> index 5da6903..7bab8b5 100644
> --- a/app/test/test_memzone.c
> +++ b/app/test/test_memzone.c
> @@ -145,8 +145,10 @@ test_memzone_reserve_flags(void)
>   hugepage_1GB_avail = 1;
>   if (ms[i].hugepage_sz == RTE_PGSIZE_16M)
>   hugepage_16MB_avail = 1;
> +#ifdef RTE_ARCH_64
>   if (ms[i].hugepage_sz == RTE_PGSIZE_16G)
>   hugepage_16GB_avail = 1;
> +#endif
>   }
>   /* Display the availability of 2MB ,1GB, 16MB, 16GB pages */
>   if (hugepage_2MB_avail)
> @@ -234,8 +236,8 @@ test_memzone_reserve_flags(void)
>   return -1;
>   }
>  
> - /* Check if 1GB huge pages are unavailable, that function fails 
> unless
> -  * HINT flag is indicated
> + /* Check if 2MB huge pages are unavailable, that function
> +  * fails unless HINT flag is indicated
>*/
>   if (!hugepage_2MB_avail) {
>   mz = rte_memzone_reserve("flag_zone_2M_HINT", size, 
> SOCKET_ID_ANY,
> @@ -295,8 +297,9 @@ test_memzone_reserve_flags(void)
>   return -1;
>   }
>  
> - /* Check if 1GB huge pages are unavailable, that function fails
> -  * unless HINT flag is indicated
> +#ifdef RTE_ARCH_64
> + /* Check if 16GB huge pages are unavailable, that function
> +  * fails unless HINT flag is indicated
>*/
>   if (!hugepage_16GB_avail) {
>   mz = rte_memzone_reserve("flag_zone_16G_HINT", size,
> @@ -318,7 +321,9 @@ test_memzone_reserve_flags(void)
>   return -1;
>   }
>   }
> +#endif
>   }
> +#ifdef RTE_ARCH_64
>   /*As with 16MB tests above for 16GB huge page requests*/
>   if (hugepage_16GB_avail) {
>   mz = rte_memzone_reserve("flag_zone_16G", size, SOCKET_ID_ANY,
> @@ -343,8 +348,8 @@ test_memzone_reserve_flags(void)
>   return -1;
>   }
>  
> - /* Check if 1GB huge pages are unavailable, that function fails
> -  * unless HINT flag is indicated
> + /* Check if 16MB huge pages are unavailable, that function
> +  * fails unless HINT flag is indicated
>*/
>   if (!hugepage_16MB_avail) {
>   mz = rte_memzone_reserve("flag_zone_16M_HINT", size,
> @@ -376,6 +381,7 @@ test_memzone_reserve_flags(void)
>   }
>   }
>   }
> +#endif
>   return 0;
>  }
>  
> diff --git a/lib/librte_eal/common/eal_common_memzone.c 
> b/lib/librte_eal/common/eal_common_memzone.c
> index b5a5d72..ee233ad 100644
> --- a/lib/librte_eal/common/eal_common_memzone.c
> +++ b/lib/librte_eal/common/eal_common_memzone.c
> @@ -221,12 +221,14 @@ memzone_reserve_aligned_thread_unsafe(const char *name, 
> size_t len,
>   if ((flags & RTE_MEMZONE_1GB) &&
>   free_memseg[i].hugepage_sz == RTE_PGSIZE_2M)
>   continue;
> +#ifdef RTE_ARCH_64
>   if ((flags & RTE_MEMZONE_16MB) &&
>   free_memseg[i].hugepage_sz == RTE_PGSIZE_16G)
>   continue;
>   if ((flags & RTE_MEMZONE_16GB) &&
>   free_memseg[i].hugepage_sz == RTE_PGSIZE_16M)
>   continue;
> +#endif
>  
>   /* this segment is the best until now */
>   if (memseg_idx == -1) {
> diff --git a/lib/librte_eal/common/include/rte_memory.h 
> b/lib/librte_eal/co

[dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

[Ananyev, Konstantin]

Hi Oliver,

> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, December 03, 2014 8:57 AM
> To: Ananyev, Konstantin; didier.pallard; Liu, Jijiang; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the 
> inner_l3_len fields
> 
> Hi Didier, Konstantin, Jijiang,
> 
> On 12/02/2014 04:36 PM, Ananyev, Konstantin wrote:
> > Hi Didier
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of didier.pallard
> >> Sent: Tuesday, December 02, 2014 2:53 PM
> >> To: Liu, Jijiang; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and 
> >> the inner_l3_len fields
> >>
> >> Hello,
> >>
> >> On 12/02/2014 07:52 AM, Jijiang Liu wrote:
> >>> Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len 
> >>> and outer_l3_len field, and rework csum forward
> engine
> >> and i40e PMD due to  these changes.
> >>>
> >>> Signed-off-by: Jijiang Liu 
> >> [...]
> >>> --- a/lib/librte_mbuf/rte_mbuf.h
> >>> +++ b/lib/librte_mbuf/rte_mbuf.h
> >>> @@ -276,8 +276,8 @@ struct rte_mbuf {
> >>>   uint64_t tso_segsz:16; /**< TCP TSO segment 
> >>> size */
> >>>
> >>>   /* fields for TX offloading of tunnels */
> >>> - uint64_t inner_l3_len:9; /**< inner L3 (IP) Hdr Length. 
> >>> */
> >>> - uint64_t inner_l2_len:7; /**< inner L2 (MAC) Hdr 
> >>> Length. */
> >>> + uint64_t outer_l3_len:9; /**< Outer L3 (IP) Hdr Length. 
> >>> */
> >>> + uint64_t outer_l2_len:7; /**< Outer L2 (MAC) Hdr 
> >>> Length. */
> >>>
> >>>   /* uint64_t unused:8; */
> >>>   };
> >>
> >> Sorry for entering lately this discussion, but i'm not convinced by the
> >> choice of outer_lx_len rather than inner_lx_len for new fields.
> >> I agree with Olivier that new flags should only be related to the use of
> >> new fields, to maintain coherency with oldest implementations.
> >> But from a stack point of view, i think it is better to have lx_len
> >> fields that target the outer layers, and to name new fields inner_lx_len.
> >>
> >> Let's discuss the two possibilities.
> >>
> >> 1) outer_lx_len fields are introduced.
> >> In this case, the stack should have knowledge that it is processing
> >> tunneled packets to use outer_lx_len rather than lx_len,
> >> or stack should always use outer_lx_len packet and move those fields to
> >> lx_len packets if no tunneling occurs...
> >> I think it will induce extra processing that does not seem to be really
> >> needed.
> >>
> >> 2) inner_lx_len fields are introduced.
> >> In this case, the stack first uses lx_len fields. When packet should be
> >> tunneled, lx_len fields are moved to inner_lx_len fields.
> >> Then the stack can process the outer layer and still use the lx_len fields.
> >
> > Not sure, that I understood why 2) is better than 1).
> > Let say,  you have a 'normal' (non-tunnelling) packet: ether/IP/TCP
> > In that case you still use mbuf's l2_len/l3_len/l4_len fields and setup 
> > ol_flags as usual.
> > Then later, you decided to 'tunnel' that packet.
> > So you just fill mbuf's outer_l2_len/outer_l3_len, setup TX_OUTER_* and 
> > TX_TUNNEL_* bits in ol_flags and probably update l2_len.
> > l3_len/l4_len and ol_flags bits set for them remain intact.
> > That's with 1)
> >
> > With 2) - you'll have to move l3_len/l4_len to inner_lx_len.
> > And I suppose ol_flags values too:
> > ol_flags &= ~PKT_ IP_CKSUM;
> > ol_flgas  |=  PKT_INNER_IP_CKSUM
> > ?
> > And same for L4_CKSUM flags too?
> 
> After reading Didier's mail, I start to be convinced that keeping inner
> may be better than outer. From a network stack architecture point of
> view, 2) looks better:
> 
> - the functions in the network stack that write the Ether/IP header
>always deal with l2_len/l3_len, whatever it's a tunnel or not.
> 
> - the function that adds the tunnel header moves the l2_len/l3_len and
>the flags to inner_l2_len/inner_l3_len and inner_flags.

Hmm, still don't understand you here.
Why all that you mentioned above suddenly become 'better'?
Here is you original suggestion about introducing 'outer_lx_len':
http://dpdk.org/ml/archives/dev/2014-November/008268.html
As you pointed, it is a clean and straightforward way to extend DPDK HW TX 
offload API with tunnelling support.
And we agreed with you here.

>From other side, 2) approach looks like a mess:
If packet is going to be tunnelled, the upper layer has to:
1.  move lx_len values to inner_lx_len.
2. move PKT_TX_*_CKSUM bit to PKT_TX_INNER_*_CKSUM bits in ol_flags. 
Plus in the mbuf we'll either have to introduce 
PKT_TX_INNER_(TCP|UDP|SCTP)_CKSUM flags
(otherwise we'll have a weird situation when PKT_TX_IP_CKSUM we'll be for outer 
IP header, but
PKT_TX_TCP_CKSUM will be for inner).

So, from DPDK perspective, 2) looks like a waste of bits in ol_flags a

[dpdk-dev] [PATCH v2] i40e: fix of compile error

[Thomas Monjalon]

> > The compile error will occur as below when set
> > 'RTE_LIBRTE_I40E_16BYTE_RX_DESC=y'.
> > 'fd_id' should be used to replace 'fd', as 'fd' is not defined in that 
> > structure at
> > all. In addition, local variable of 'flexbl' and 'flexbh' must be used only 
> > if
> > 32 bytes RX descriptor is selected.
> > 
> > error logs:
> > lib/librte_pmd_i40e/i40e_rxtx.c: In function i40e_rxd_build_fdir:
> > lib/librte_pmd_i40e/i40e_rxtx.c:431:28: error: volatile union 
> > has no member named fd
> > lib/librte_pmd_i40e/i40e_rxtx.c:427:19: error: unused variable flexbl [-
> > Werror=unused-variable]
> > lib/librte_pmd_i40e/i40e_rxtx.c:427:11: error: unused variable flexbh [-
> > Werror=unused-variable]
> > 
> > Signed-off-by: Helin Zhang 
> 
> Acked-by: Jingjing Wu 

Applied

Thanks 
-- 
Thomas

[dpdk-dev] [PATCH v2] add one option memory-only for secondary processes

[Hiroshi Shimamoto]

Hi,

> Subject: [dpdk-dev] [PATCH v2] add one option memory-only for secondary 
> processes
> 
> From: Chi Xiaobo 
> 
> Problem: There is one normal DPDK processes deployment scenarios: one primary 
> process and several (even hundreds) secondary
> processes; all outside packets/messages are sent/received by primary process 
> and then distribute them to those secondary
> processes by DPDK's ring/sharedmemory mechanism. In such scenarios, those 
> SECONDARY processes need only hugepage based
> sharememory mechanism and it???s upper libs (such as ring, mempool, etc.), 
> they need not cpu core pinning, iopl privilege
> changing , pci device, timer, alarm, interrupt, shared_driver_list,  
> core_info, threads for each core, etc. Then, for
> such kind of SECONDARY processes, the current rte_eal_init() is too heavy.
> 
> Solution:One new EAL initializing argument, --memory-only, is added. It is 
> only for those SECONDARY processes which only
> want to share memory with other processes. if this argument is defined, users 
> need not define those mandatory arguments,
> such as -c and -n, due to we don't want to pin such kind of processes to any 
> CPUs.

however, we need the lcore_id per thread to use mempool.
If the lcore_id is not initialized, it must be 0, and multiple threads will 
break
mempool caches per thread, because of race condition.
We have to assign lcore_id per thread, these ids must not be overlapped, or 
disable
mempool handling in SECONDARY process.

thanks,
Hiroshi

> Signed-off-by: Chi Xiaobo 
> ---
>  lib/librte_eal/common/eal_common_options.c | 17 ---
>  lib/librte_eal/common/eal_internal_cfg.h   |  1 +
>  lib/librte_eal/common/eal_options.h|  2 ++
>  lib/librte_eal/linuxapp/eal/eal.c  | 34 
> +-
>  4 files changed, 36 insertions(+), 18 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_options.c 
> b/lib/librte_eal/common/eal_common_options.c
> index e2810ab..7b18498 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -85,6 +85,7 @@ eal_long_options[] = {
>   {OPT_XEN_DOM0, 0, 0, OPT_XEN_DOM0_NUM},
>   {OPT_CREATE_UIO_DEV, 1, NULL, OPT_CREATE_UIO_DEV_NUM},
>   {OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
> + {OPT_MEMORY_ONLY, 0, NULL, OPT_MEMORY_ONLY_NUM},
>   {0, 0, 0, 0}
>  };
> 
> @@ -126,6 +127,7 @@ eal_reset_internal_config(struct internal_config 
> *internal_cfg)
>   internal_cfg->no_hpet = 1;
>  #endif
>   internal_cfg->vmware_tsc_map = 0;
> + internal_cfg->memory_only= 0;
>  }
> 
>  /*
> @@ -454,6 +456,10 @@ eal_parse_common_option(int opt, const char *optarg,
>   conf->process_type = eal_parse_proc_type(optarg);
>   break;
> 
> + case OPT_MEMORY_ONLY_NUM:
> + conf->memory_only= 1;
> + break;
> +
>   case OPT_MASTER_LCORE_NUM:
>   if (eal_parse_master_lcore(optarg) < 0) {
>   RTE_LOG(ERR, EAL, "invalid parameter for --"
> @@ -525,9 +531,9 @@ eal_check_common_options(struct internal_config 
> *internal_cfg)
>  {
>   struct rte_config *cfg = rte_eal_get_configuration();
> 
> - if (!lcores_parsed) {
> - RTE_LOG(ERR, EAL, "CPU cores must be enabled with options "
> - "-c or -l\n");
> + if (!lcores_parsed && !(internal_cfg->process_type == 
> RTE_PROC_SECONDARY&& internal_cfg->memory_only) ) {
> + RTE_LOG(ERR, EAL, "For those processes without memory-only 
> option, CPU cores "
> + "must be enabled with 
> options -c or -l\n");
>   return -1;
>   }
>   if (cfg->lcore_role[cfg->master_lcore] != ROLE_RTE) {
> @@ -545,6 +551,10 @@ eal_check_common_options(struct internal_config 
> *internal_cfg)
>   "specified\n");
>   return -1;
>   }
> + if ( internal_cfg->process_type != RTE_PROC_SECONDARY && 
> internal_cfg->memory_only ) {
> + RTE_LOG(ERR, EAL, "only secondary processes can specify 
> memory-only option.\n");
> + return -1;
> + }
>   if (index(internal_cfg->hugefile_prefix, '%') != NULL) {
>   RTE_LOG(ERR, EAL, "Invalid char, '%%', in --"OPT_FILE_PREFIX" "
>   "option\n");
> @@ -590,6 +600,7 @@ eal_common_usage(void)
>  "  --"OPT_SYSLOG" : set syslog facility\n"
>  "  --"OPT_LOG_LEVEL"  : set default log level\n"
>  "  --"OPT_PROC_TYPE"  : type of this process\n"
> +"  --"OPT_MEMORY_ONLY": only use shared memory, valid only for 
> secondary process.\n"
>  "  --"OPT_PCI_BLACKLIST", -b: add a PCI device in black list.\n"
>  "   Prevent EAL from using this PCI device. The 
> argument\n"
>  "   format is .\n"
> diff --git a/lib/librte_eal/common/eal_internal_cfg.h 
> b/lib/librte_eal/common/eal_internal_c

[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[O'driscoll, Tim]

Thanks to everybody who attended yesterday's call, particularly those who 
presented:

Tetsuya Mukawa (mukawa at igel.co.jp) on PCI Hot Plug
Changchun Ouyang (changchun.ouyang at intel.com) on a converged Virtio driver
Marvin (Yong) Liu (yong.liu at intel.com) on the DPDK Test Suite

For anybody who missed the call, the video is available at: 
http://youtu.be/uD_cbE4CVe8.


Thanks,
Tim

> -Original Message-
> From: O'driscoll, Tim
> Sent: Friday, November 21, 2014 4:09 PM
> To: dev at dpdk.org
> Subject: Next Community Call, Tuesday 2nd December, 8:00 AM GMT
> 
> We're going to hold our next community call on Tuesday 2nd December. This
> time, we're going to try a time that's more suitable for participants in 
> Asia, so
> we're going to hold it at 8:00 AM GMT. The meeting time in a variety of
> timezones is included below.
> 
> Generally, GoToMeeting worked well last time, although there was a
> limitation that Neil was unable to present slides as he joined from a Linux
> system. We'll stick with GoToMeeting again this time as we don't yet have a
> better solution. Details for joining the GoToMeeting session are included
> below.
> 
> I'll record the session again and post the video to YouTube afterwards for
> anybody who can't make it. This seemed to work well last time, and as Kevin
> pointed out, the audio quality on the recording is good.
> 
> For the agenda, we'd like to discuss the following:
> ? Remaining 2.0 candidate features, especially PCI Hotplug as there's been a
> lot of discussion on that on the mailing list. Hopefully Tetsuya Mukawa can
> join us to describe his work on this.
> ? DPDK Test Suite. We hope to announce the release of this next week.
> Waterman Cao and Yong (Marvin) Liu from our Shanghai team will describe
> the functionality and benefits of this.
> 
> 
> Meeting Time:
> Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC
> Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1 hour
> Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST UTC+2 hours
> Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00 AM MSK UTC+3
> hours
> New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM IST
> UTC+5:30 hours
> Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014 at
> 4:00:00 PM CST UTC+8 hours
> Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9 hours
> San Francisco (U.S.A. - California) Midnight between Monday, December 1,
> 2014 and Tuesday, December 2, 2014 PST UTC-8 hours
> Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM MST
> UTC-7 hours
> New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM EST
> UTC-5 hours
> Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM EST
> UTC-5 hours
> Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00
> 
> 
> GoToMeeting Details:
> To join, follow the meeting link:
> https://global.gotomeeting.com/join/772753069. This will start the
> GoToMeeting web viewer. You then have two options for audio:
> 
> 1. To use your computer's audio via a headset, you need to switch to the
> desktop version of GoToMeeting. You can do this by clicking the
> GoToMeeting icon on the top right hand side of the web viewer, and then
> selecting "Switch to the desktop version". The desktop version will need to
> download and install, so if you plan to use this you may want to get it set up
> in advance. Once it starts, under the Audio section, you can select "Mic &
> Speakers". The desktop version is only available for Windows and Mac, so if
> you're using Linux then you need to use option 2 below.
> 
> 2. You can join using a phone via one of the numbers listed below. The
> Access Code is 772-753-069. You'll also be asked for an Audio PIN, which is
> accessible by clicking the phone icon in the GoToMeeting web viewer after
> you've joined the meeting.
> ? Australia   (Long distance): +61 2 9091 7601
> ? Austria   (Long distance): +43 (0) 7 2088 1036
> ? Belgium   (Long distance): +32 (0) 28 08 4345
> ? Canada   (Long distance): +1 (647) 497-9372
> ? Denmark   (Long distance): +45 (0) 69 91 89 24
> ? Finland   (Long distance): +358 (0) 942 45 0382
> ? France   (Long distance): +33 (0) 170 950 586
> ? Germany   (Long distance): +49 (0) 692 5736 7206
> ? Ireland   (Long distance): +353 (0) 15 255 598
> ? Italy   (Long distance): +39 0 694 80 31 28
> ? Netherlands   (Long distance): +31 (0) 208 084 055
> ? New Zealand   (Long distance): +64 (0) 4 974 7243
> ? Norway   (Long distance): +47 23 96 01 18
> ? Spain   (Long distance): +34 932 20 0506
> ? Sweden   (Long distance): +46 (0) 852 500 182
> ? Switzerland   (Long distance): +41 (0) 435 0824 78
> ? United Kingdom   (Long distance): +44 (0) 330 221 0098
> ? United States   (Long distance): +1 (626) 521-0013
> Access Code 772-753-069.
> 
> Info on downloading the desktop app is available at:
> http://support.citrixonline.com/en_US/meeting/help_files/G2M010002?title
> =Download%7D
> Info on

[dpdk-dev] [PATCH v3] kni: create KNI interface in current network namespace

[Takayuki Usui]

With this patch, KNI interface (e.g. vEth0) is created in the
network namespace where the DPDK application is running.
Otherwise, all interfaces are created in the default namespace
in the host.

put_net() is required, since get_net_ns_by_pid() increments
the reference counter of the network namespace with get_net().

Signed-off-by: Takayuki Usui 
---
 lib/librte_eal/linuxapp/kni/kni_misc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index ba6..868b325 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -311,6 +311,7 @@ kni_ioctl_create(unsigned int ioctl_num, unsigned long 
ioctl_param)
struct net_device *net_dev = NULL;
struct net_device *lad_dev = NULL;
struct kni_dev *kni, *dev, *n;
+   struct net *net;

printk(KERN_INFO "KNI: Creating kni...\n");
/* Check the buffer size, to avoid warning */
@@ -354,6 +355,14 @@ kni_ioctl_create(unsigned int ioctl_num, unsigned long 
ioctl_param)
return -EBUSY;
}

+   net = get_net_ns_by_pid(current->pid);
+   if (IS_ERR(net)) {
+   free_netdev(net_dev);
+   return PTR_ERR(net);
+   }
+   dev_net_set(net_dev, net);
+   put_net(net);
+
kni = netdev_priv(net_dev);

kni->net_dev = net_dev;
-- 
2.1.3

[dpdk-dev] [PATCH] doc: patch to include vhost library UG section in PG

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Tuesday, December 2, 2014 9:12 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: patch to include vhost library UG section in 
> PG
> 
> As Vhost will be a library in DPDK 1.8, adding a new section to Programmer's 
> Guide to describe its use.
> 
> Signed-off-by: Siobhan Butler 
> 
> Signed-off-by: Huawei Xie 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [question] DPDK-2.0 support broadcom driver

[Stephen Hemminger]

On Wed, 3 Dec 2014 09:48:57 +0800
"Zhang Haoyu"  wrote:

> Hi,
> 
> I see that broadcom driver will be supported in DPDK-2.0 from 
> DPDK roadmap(http://dpdk.org/dev/roadmap),
> any details about the progress?
> 
> And, is there a plane for supporting emulex driver?
> 
> Thanks,
> Zhang Haoyu
> 

I have patch, just too big for mailing list.

[dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

[Olivier MATZ]

Hi Didier, Konstantin, Jijiang,

On 12/02/2014 04:36 PM, Ananyev, Konstantin wrote:
> Hi Didier
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of didier.pallard
>> Sent: Tuesday, December 02, 2014 2:53 PM
>> To: Liu, Jijiang; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the 
>> inner_l3_len fields
>>
>> Hello,
>>
>> On 12/02/2014 07:52 AM, Jijiang Liu wrote:
>>> Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len 
>>> and outer_l3_len field, and rework csum forward engine
>> and i40e PMD due to  these changes.
>>>
>>> Signed-off-by: Jijiang Liu 
>> [...]
>>> --- a/lib/librte_mbuf/rte_mbuf.h
>>> +++ b/lib/librte_mbuf/rte_mbuf.h
>>> @@ -276,8 +276,8 @@ struct rte_mbuf {
>>> uint64_t tso_segsz:16; /**< TCP TSO segment size */
>>>
>>> /* fields for TX offloading of tunnels */
>>> -   uint64_t inner_l3_len:9; /**< inner L3 (IP) Hdr Length. 
>>> */
>>> -   uint64_t inner_l2_len:7; /**< inner L2 (MAC) Hdr 
>>> Length. */
>>> +   uint64_t outer_l3_len:9; /**< Outer L3 (IP) Hdr Length. 
>>> */
>>> +   uint64_t outer_l2_len:7; /**< Outer L2 (MAC) Hdr 
>>> Length. */
>>>
>>> /* uint64_t unused:8; */
>>> };
>>
>> Sorry for entering lately this discussion, but i'm not convinced by the
>> choice of outer_lx_len rather than inner_lx_len for new fields.
>> I agree with Olivier that new flags should only be related to the use of
>> new fields, to maintain coherency with oldest implementations.
>> But from a stack point of view, i think it is better to have lx_len
>> fields that target the outer layers, and to name new fields inner_lx_len.
>>
>> Let's discuss the two possibilities.
>>
>> 1) outer_lx_len fields are introduced.
>> In this case, the stack should have knowledge that it is processing
>> tunneled packets to use outer_lx_len rather than lx_len,
>> or stack should always use outer_lx_len packet and move those fields to
>> lx_len packets if no tunneling occurs...
>> I think it will induce extra processing that does not seem to be really
>> needed.
>>
>> 2) inner_lx_len fields are introduced.
>> In this case, the stack first uses lx_len fields. When packet should be
>> tunneled, lx_len fields are moved to inner_lx_len fields.
>> Then the stack can process the outer layer and still use the lx_len fields.
>
> Not sure, that I understood why 2) is better than 1).
> Let say,  you have a 'normal' (non-tunnelling) packet: ether/IP/TCP
> In that case you still use mbuf's l2_len/l3_len/l4_len fields and setup 
> ol_flags as usual.
> Then later, you decided to 'tunnel' that packet.
> So you just fill mbuf's outer_l2_len/outer_l3_len, setup TX_OUTER_* and 
> TX_TUNNEL_* bits in ol_flags and probably update l2_len.
> l3_len/l4_len and ol_flags bits set for them remain intact.
> That's with 1)
>
> With 2) - you'll have to move l3_len/l4_len to inner_lx_len.
> And I suppose ol_flags values too:
> ol_flags &= ~PKT_ IP_CKSUM;
> ol_flgas  |=  PKT_INNER_IP_CKSUM
> ?
> And same for L4_CKSUM flags too?

After reading Didier's mail, I start to be convinced that keeping inner
may be better than outer. From a network stack architecture point of
view, 2) looks better:

- the functions in the network stack that write the Ether/IP header
   always deal with l2_len/l3_len, whatever it's a tunnel or not.

- the function that adds the tunnel header moves the l2_len/l3_len and
   the flags to inner_l2_len/inner_l3_len and inner_flags.

Althought it was my first idea, now I cannot find a better argument in
favor of outer_lX_len. The initial argument was that the correspondance
between a flag and a lX_len should always remain the same, but it is
still possible with Didier's approach:
   - PKT_IP_CKSUM uses l2_len and l3_len
   - PKT_INNER_CKSUM uses inner_l2_len and inner_l3_len

Jijiang, I'm sorry to change my mind about this. If you want (and if
Konstantin is also ok with that), I can try to rebase your patches to
match this. Or do you prefer to do it by yourself?

Regards,
Olivier

[dpdk-dev] [question] DPDK-2.0 support broadcom driver

[Zhang Haoyu]

Hi,

I see that broadcom driver will be supported in DPDK-2.0 from 
DPDK roadmap(http://dpdk.org/dev/roadmap),
any details about the progress?

And, is there a plane for supporting emulex driver?

Thanks,
Zhang Haoyu

[dpdk-dev] [PATCH v2] i40e: fix of compile error

[Helin Zhang]

The compile error will occur as below when set 
'RTE_LIBRTE_I40E_16BYTE_RX_DESC=y'.
'fd_id' should be used to replace 'fd', as 'fd' is not defined in that structure
at all. In addition, local variable of 'flexbl' and 'flexbh' must be used only 
if
32 bytes RX descriptor is selected.

error logs:
lib/librte_pmd_i40e/i40e_rxtx.c: In function i40e_rxd_build_fdir:
lib/librte_pmd_i40e/i40e_rxtx.c:431:28: error: volatile union  has 
no member named fd
lib/librte_pmd_i40e/i40e_rxtx.c:427:19: error: unused variable flexbl 
[-Werror=unused-variable]
lib/librte_pmd_i40e/i40e_rxtx.c:427:11: error: unused variable flexbh 
[-Werror=unused-variable]

Signed-off-by: Helin Zhang 
---
 lib/librte_pmd_i40e/i40e_rxtx.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

v2 changes:
* Removed the changes for code style fix, and kept it for compile error fix 
only.
* Re-word the commit logs.

diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 2d2ef04..63c872d 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -424,13 +424,9 @@ static inline uint64_t
 i40e_rxd_build_fdir(volatile union i40e_rx_desc *rxdp, struct rte_mbuf *mb)
 {
uint64_t flags = 0;
+#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC
uint16_t flexbh, flexbl;

-#ifdef RTE_LIBRTE_I40E_16BYTE_RX_DESC
-   mb->hash.fdir.hi =
-   rte_le_to_cpu_32(rxdp->wb.qword0.hi_dword.fd);
-   flags |= PKT_RX_FDIR_ID;
-#else
flexbh = (rte_le_to_cpu_32(rxdp->wb.qword2.ext_status) >>
I40E_RX_DESC_EXT_STATUS_FLEXBH_SHIFT) &
I40E_RX_DESC_EXT_STATUS_FLEXBH_MASK;
@@ -453,6 +449,10 @@ i40e_rxd_build_fdir(volatile union i40e_rx_desc *rxdp, 
struct rte_mbuf *mb)

rte_le_to_cpu_32(rxdp->wb.qword3.lo_dword.flex_bytes_lo);
flags |= PKT_RX_FDIR_FLX;
}
+#else
+   mb->hash.fdir.hi =
+   rte_le_to_cpu_32(rxdp->wb.qword0.hi_dword.fd_id);
+   flags |= PKT_RX_FDIR_ID;
 #endif
return flags;
 }
-- 
1.9.3

[dpdk-dev] [PATCH 0/3] i40e VXLAN TX checksum rework

[Liu, Jijiang]

Hi Thomas,

> -Original Message-
> From: Liu, Jijiang
> Sent: Friday, November 28, 2014 12:32 AM
> To: Olivier MATZ
> Cc: Ananyev, Konstantin; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 0/3] i40e VXLAN TX checksum rework
> 
> 
> 
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Thursday, November 27, 2014 11:30 PM
> > To: Olivier MATZ; Liu, Jijiang; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 0/3] i40e VXLAN TX checksum rework
> >
> > Hi Oliver,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> > > Sent: Thursday, November 27, 2014 9:45 AM
> > > To: Liu, Jijiang; dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/3] i40e VXLAN TX checksum rework
> > >
> > > Hi Jijiang,
> > >
> > > Please find below some comments about the specifications. The global
> > > picture looks fine to me.
> > >
> > > I've not reviewed the patch right now, but it's in the pipe.
> > >
> > > On 11/27/2014 09:18 AM, Jijiang Liu wrote:
> > > > We have got some feedback about backward compatibility of VXLAN TX
> > > > checksum offload API with 1G/10G NIC after the i40e VXLAN
> > > TX checksum codes were applied, so we have to rework the APIs on
> > > i40e,
> > including the changes of mbuf, i40e PMD and csum engine.
> > > >
> > > > The main changes in mbuf are as follows, In place of removing
> > > > PKT_TX_VXLAN_CKSUM, we introducing 2 new flags:
> > PKT_TX_OUT_IP_CKSUM,
> > > > PKT_TX_UDP_TUNNEL_PKT,
> > > and a new field: l4_tun_len.
> > >
> > > What about PKT_TX_OUT_UDP_CKSUM instead of
> > PKT_TX_UDP_TUNNEL_PKT? It's
> > > maybe more coherent with the other names.
> >
> > FVL HW don't support outer L4 checksum offload.
> > But to calculate inner checksums correctly, it needs a hint from SW
> > about L4 Tunnelling Type.
> >
> > >
> > >
> > > > Replace the inner_l2_len and the inner_l3_len field with the
> > > > outer_l2_len and
> > outer_l3_len field.
> > > >
> > > > The existing flags are listed below,
> > > > PKT_TX_IP_CKSUM: HW IPv4 checksum for non-tunnelling packet/ HW
> > inner IPv4 checksum for tunnelling packet
> > > > PKT_TX_TCP_CKSUM:HW TCP checksum for non-tunnelling packet/ HW
> > inner TCP checksum for tunnelling packet
> > > > PKT_TX_SCTP_CKSUM:   HW SCTP checksum for non-tunnelling packet/ HW
> > inner SCTP checksum for tunnelling packet
> > > > PKT_TX_UDP_CKSUM:HW SCTP checksum for non-tunnelling packet/ HW
> > inner SCTP checksum for tunnelling packet
> > > > PKT_TX_IPV4:IPv4 with no HW checksum offload for non-tunnelling
> > packet/inner IPv4 with no HW checksum offload for
> > > tunnelling packet
> > > > PKT_TX_IPV6:IPv6 non-tunnelling packet/ inner IPv6 with no HW
> > checksum offload for tunnelling packet
> > >
> > > As I suggested in the TSO thread, I think the following semantics is
> > > easier to understand for the user:
> > >
> > >- PKT_TX_IP_CKSUM: tell the NIC to compute IP cksum
> > >
> > >- PKT_TX_IPV4: tell the NIC it's an IPv4 packet. Required for L4
> > >  checksum offload or TSO.
> > >
> > >- PKT_TX_IPV6: tell the NIC it's an IPv6 packet. Required for L4
> > >  checksum offload or TSO.
> > >
> > > I think it won't make a big difference in the FVL driver.
> >
> > No, no big difference here, but I still think it will be a bit cleaner
> > if all 3 flags would be nutually exclusive.
> > In fact,  we can unite all 3 of them them into 2 bits,same as we doing 
> > for L4
> > checksum flags.
> >
> > >
> > >
> > > > let's use a few examples to demonstrate how to use these flags:
> > > > Let say we have a tunnel packet:
> > > > eth_hdr_out/ipv4_hdr_out/udp_hdr_out/vxlan_hdr/ehtr_hdr_in/ipv4_hd
> > > > r_
> > > > in/tcp_hdr_in.There
> > > could be several scenarios:
> > > >
> > > > A) User requests HW offload for ipv4_hdr_out checksum.
> > > > He doesn't care is it a tunnelled packet or not.
> > > > So he sets:
> > > >
> > > > mb->l2_len =  eth_hdr_out;
> > > > mb->l3_len = ipv4_hdr_out;
> > > > mb->ol_flags |= PKT_TX_IPV4_CSUM;
> > > >
> > > > B) User is aware that it is a tunnelled packet and requests HW
> > > > offload for
> > ipv4_hdr_in and tcp_hdr_in *only*.
> > > > He doesn't care about outer IP checksum offload.
> > > > In that case, for FVL  he has 2 choices:
> > > > 1. Treat that packet as a 'proper' tunnelled packet, and fill all 
> > > > the fields:
> > > >   mb->l2_len =  eth_hdr_in;
> > > >   mb->l3_len = ipv4_hdr_in;
> > > >   mb->outer_l2_len = eth_hdr_out;
> > > >   mb->outer_l3_len = ipv4_hdr_out;
> > > >   mb->l4tun_len = vxlan_hdr;
> > > >   mb->ol_flags |= PKT_TX_UDP_TUNNEL_PKT | PKT_TX_IP_CKSUM |
> > > > PKT_TX_TCP_CKSUM;
> > > >
> > > > 2. As user doesn't care about outer IP hdr checksum, he can
> > > > treat
> > everything before ipv4_hdr_in as L2 header.
> > > > So he knows, that it is a tunnelled packet, but makes HW to
> > > > treat it as
> > ordinary (non-tunnelled) packet:
> > > >   

[dpdk-dev] [PATCH v2] i40e: fix of compile error

[Wu, Jingjing]

> -Original Message-
> From: Zhang, Helin
> Sent: Wednesday, December 03, 2014 9:13 AM
> To: dev at dpdk.org
> Cc: Cao, Waterman; Cao, Min; Wu, Jingjing; Zhang, Helin
> Subject: [PATCH v2] i40e: fix of compile error
> 
> The compile error will occur as below when set
> 'RTE_LIBRTE_I40E_16BYTE_RX_DESC=y'.
> 'fd_id' should be used to replace 'fd', as 'fd' is not defined in that 
> structure at
> all. In addition, local variable of 'flexbl' and 'flexbh' must be used only if
> 32 bytes RX descriptor is selected.
> 
> error logs:
> lib/librte_pmd_i40e/i40e_rxtx.c: In function i40e_rxd_build_fdir:
> lib/librte_pmd_i40e/i40e_rxtx.c:431:28: error: volatile union 
> has no member named fd
> lib/librte_pmd_i40e/i40e_rxtx.c:427:19: error: unused variable flexbl [-
> Werror=unused-variable]
> lib/librte_pmd_i40e/i40e_rxtx.c:427:11: error: unused variable flexbh [-
> Werror=unused-variable]
> 
> Signed-off-by: Helin Zhang 
> ---
>  lib/librte_pmd_i40e/i40e_rxtx.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> v2 changes:
> * Removed the changes for code style fix, and kept it for compile error fix
> only.
> * Re-word the commit logs.
> 
> diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
> index 2d2ef04..63c872d 100644
> --- a/lib/librte_pmd_i40e/i40e_rxtx.c
> +++ b/lib/librte_pmd_i40e/i40e_rxtx.c
> @@ -424,13 +424,9 @@ static inline uint64_t  i40e_rxd_build_fdir(volatile
> union i40e_rx_desc *rxdp, struct rte_mbuf *mb)  {
>   uint64_t flags = 0;
> +#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC
>   uint16_t flexbh, flexbl;
> 
> -#ifdef RTE_LIBRTE_I40E_16BYTE_RX_DESC
> - mb->hash.fdir.hi =
> - rte_le_to_cpu_32(rxdp->wb.qword0.hi_dword.fd);
> - flags |= PKT_RX_FDIR_ID;
> -#else
>   flexbh = (rte_le_to_cpu_32(rxdp->wb.qword2.ext_status) >>
>   I40E_RX_DESC_EXT_STATUS_FLEXBH_SHIFT) &
>   I40E_RX_DESC_EXT_STATUS_FLEXBH_MASK;
> @@ -453,6 +449,10 @@ i40e_rxd_build_fdir(volatile union i40e_rx_desc
> *rxdp, struct rte_mbuf *mb)
>   rte_le_to_cpu_32(rxdp-
> >wb.qword3.lo_dword.flex_bytes_lo);
>   flags |= PKT_RX_FDIR_FLX;
>   }
> +#else
> + mb->hash.fdir.hi =
> + rte_le_to_cpu_32(rxdp->wb.qword0.hi_dword.fd_id);
> + flags |= PKT_RX_FDIR_ID;
>  #endif
>   return flags;
>  }
> --
> 1.9.3

Acked-by: Jingjing Wu 

[dpdk-dev] Error running dpdk app: cannot open /dev/uio

[Qiu, Michael]

On 12/3/2014 9:25 AM, Malveeka Tewari wrote:
> I do have the uio and igb_uio modules loaded.
> For my issue, I found a workaround by manually creating /dev/uio0
> using mknod.
> But I still get the vfio error.
>
> If I try "sudo modprobe vfio" but that gives an error that Module vfio
> not found.
> I tried looking for vfio.ko in the dpdk source tree as well but could
> not find that module.
> How can I install the vfio module?

VFIO is supplied by kernel :)
if you use uio then vfio can be ignored. It is just another way of
things in new kernel(version > 3.6).

Thanks,
Michael

>
> Thanks!
> Malveeka
>
>
>
> On Tue, Dec 2, 2014 at 5:12 PM, Qiu, Michael  > wrote:
>
> Hi Malveeka,
>
> To be sure that you should have [uio, igb_uio] or [uio,
> uio_pci_generic]
> or [vfio] module loaded.
>
> Thanks,
> Michael
> On 12/3/2014 5:44 AM, Malveeka Tewari wrote:
> > Hi
> >
> > I am trying to run the testpmd app as but I get the following
> errors:
> > EAL: VFIO could not be initialized
> > EAL: Cannot open /dev/uio0: No such file or directory
> > EAL: Error - exiting with code: 1
> >   Cause: Requested device :07:00.0 cannot be used
> >
> > lsmod shows that the uio module is installed.
> > Is there anything that's missing?
> >
> > Thanks!
> > Malveeka
> >
> >
> >
> > Output on trying to run testpmd
> >
> > EAL: Detected 16 lcore(s)
> > *EAL:   cannot open VFIO container, error 2 (No such file or
> directory)*
> > *EAL: VFIO support could not be initialized*
> > EAL: Setting up memory...
> > EAL: Ask a virtual area of 0x20 bytes
> > EAL: Virtual area found at 0x7fe66ac0 (size = 0x20)
> > EAL: Ask a virtual area of 0xffc0 bytes
> > EAL: Virtual area found at 0x7fe56ae0 (size = 0xffc0)
> > EAL: Ask a virtual area of 0x20 bytes
> > EAL: Virtual area found at 0x7fe56aa0 (size = 0x20)
> > EAL: Ask a virtual area of 0xfec0 bytes
> > EAL: Virtual area found at 0x7fe46bc0 (size = 0xfec0)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe46b60 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe46b00 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe46aa0 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe46a40 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe469e0 (size = 0x40)
> > EAL: Requesting 2048 pages of size 2MB from socket 0
> > EAL: Requesting 2048 pages of size 2MB from socket 1
> > EAL: TSC frequency is ~2266745 KHz
> > EAL: Master core 3 is ready (tid=6cedb800)
> > EAL: PCI device :07:00.0 on NUMA socket -1
> > EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> >
> >
> > *EAL: Cannot open /dev/uio0: No such file or directoryEAL: Error
> - exiting
> > with code: 1  Cause: Requested device :07:00.0 cannot be used*
> >
>
>

[dpdk-dev] Error running dpdk app: cannot open /dev/uio

[Qiu, Michael]

Hi Malveeka,

To be sure that you should have [uio, igb_uio] or [uio, uio_pci_generic]
or [vfio] module loaded.

Thanks,
Michael
On 12/3/2014 5:44 AM, Malveeka Tewari wrote:
> Hi
>
> I am trying to run the testpmd app as but I get the following errors:
> EAL: VFIO could not be initialized
> EAL: Cannot open /dev/uio0: No such file or directory
> EAL: Error - exiting with code: 1
>   Cause: Requested device :07:00.0 cannot be used
>
> lsmod shows that the uio module is installed.
> Is there anything that's missing?
>
> Thanks!
> Malveeka
>
>
>
> Output on trying to run testpmd
>
> EAL: Detected 16 lcore(s)
> *EAL:   cannot open VFIO container, error 2 (No such file or directory)*
> *EAL: VFIO support could not be initialized*
> EAL: Setting up memory...
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7fe66ac0 (size = 0x20)
> EAL: Ask a virtual area of 0xffc0 bytes
> EAL: Virtual area found at 0x7fe56ae0 (size = 0xffc0)
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7fe56aa0 (size = 0x20)
> EAL: Ask a virtual area of 0xfec0 bytes
> EAL: Virtual area found at 0x7fe46bc0 (size = 0xfec0)
> EAL: Ask a virtual area of 0x40 bytes
> EAL: Virtual area found at 0x7fe46b60 (size = 0x40)
> EAL: Ask a virtual area of 0x40 bytes
> EAL: Virtual area found at 0x7fe46b00 (size = 0x40)
> EAL: Ask a virtual area of 0x40 bytes
> EAL: Virtual area found at 0x7fe46aa0 (size = 0x40)
> EAL: Ask a virtual area of 0x40 bytes
> EAL: Virtual area found at 0x7fe46a40 (size = 0x40)
> EAL: Ask a virtual area of 0x40 bytes
> EAL: Virtual area found at 0x7fe469e0 (size = 0x40)
> EAL: Requesting 2048 pages of size 2MB from socket 0
> EAL: Requesting 2048 pages of size 2MB from socket 1
> EAL: TSC frequency is ~2266745 KHz
> EAL: Master core 3 is ready (tid=6cedb800)
> EAL: PCI device :07:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
>
>
> *EAL: Cannot open /dev/uio0: No such file or directoryEAL: Error - exiting
> with code: 1  Cause: Requested device :07:00.0 cannot be used*
>

[dpdk-dev] [PATCH] doc: remove redundant Intel referances-FreeBSD GSG

[Siobhan Butler]

Updated the FreeBSD GSG to remove redundant Intel referances.

Signed-off-by: Siobhan Butler 
---
 doc/guides/freebsd_gsg/build_dpdk.rst| 117 ---
 doc/guides/freebsd_gsg/build_sample_apps.rst |  54 +++--
 doc/guides/freebsd_gsg/intro.rst |  44 +-
 doc/guides/freebsd_gsg/sys_reqs.rst  |  45 ++-
 4 files changed, 143 insertions(+), 117 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst 
b/doc/guides/freebsd_gsg/build_dpdk.rst
index 9b78840..dec3eea 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -28,13 +28,13 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-Compiling the Intel? DPDK Target from Source
-
+Compiling the DPDK Target from Source
+=

-Install the Intel? DPDK and Browse Sources
---
+Install the DPDK and Browse Sources
+---

-First, uncompress the archive and move to the Intel? DPDK source directory:
+First, uncompress the archive and move to the DPDK source directory:

 .. code-block:: console

@@ -43,20 +43,20 @@ First, uncompress the archive and move to the Intel? DPDK 
source directory:
 user at host:~/DPDK # ls
 app/ config/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile mk/ scripts/ 
tools/

-The Intel? DPDK is composed of several directories:
+The DPDK is composed of several directories:

-*   lib: Source code of Intel? DPDK libraries
+*   lib: Source code of DPDK libraries

-*   app: Source code of Intel? DPDK applications (automatic tests)
+*   app: Source code of DPDK applications (automatic tests)

-*   examples: Source code of Intel? DPDK applications
+*   examples: Source code of DPDK applications

 *   config, tools, scripts, mk: Framework-related makefiles, scripts and 
configuration

-Installation of the Intel? DPDK Target Environments

+Installation of the DPDK Target Environments
+

-The format of an Intel? DPDK target is:
+The format of a DPDK target is:

 ARCH-MACHINE-EXECENV-TOOLCHAIN

@@ -70,7 +70,8 @@ Where:

 *   TOOLCHAIN is: gcc

-The configuration files for the Intel? DPDK targets can be found in the 
DPDK/config directory in the form of:
+The configuration files for the DPDK targets can be found in the DPDK/config
+directory in the form of:

 ::

@@ -82,7 +83,7 @@ The configuration files for the Intel? DPDK targets can be 
found in the DPDK/co
 Within the configuration files, the RTE_MACHINE configuration value is set 
to native,
 which means that the compiled software is tuned for the platform on which 
it is built.
 For more information on this setting, and its possible values,
-see the *Intel? DPDK Programmers Guide*.
+see the *DPDK Programmers Guide*.

 To install and make the target, use gmake install T= CC=gcc48.

@@ -106,33 +107,37 @@ To build after configuration, change directory to 
./x86_64-native-bsdapp-gcc and

 gmake CC=gcc48

-Browsing the Installed Intel?DPDK Environment Target
-
+Browsing the Installed DPDK Environment Target
+--

 Once a target is created, it contains all the libraries
-and header files for the Intel? DPDK environment that are required to build 
customer applications.
-In addition, the test and testpmd applications are built under the build/app 
directory, which may be used for testing.
-A kmod directory is also present that contains the kernel modules to install:
+and header files for the DPDK environment that are required to build customer 
applications.
+In addition, the test and testpmd applications are built under the build/app 
directory,
+which may be used for testing. A kmod directory is also present that contains 
the kernel
+modules to install:

 .. code-block:: console

 user at host:~/DPDK # ls x86_64-native-bsdapp-gcc
 app   buildhostappincludekmodlibMakefile

-Loading the Intel? DPDK contigmem Module
+Loading the DPDK contigmem Module
 

-To run any Intel? DPDK application, the contigmem module must be loaded into 
the running kernel.
-The module is found in the kmod sub-directory of the Intel? DPDK target 
directory.
-The module can be loaded using kldload (assuming that the current directory is 
the Intel? DPDK target directory):
+To run any DPDK application, the contigmem module must be loaded into the 
running
+kernel.
+The module is found in the kmod sub-directory of the DPDK target directory.
+The module can be loaded using kldload (assuming that the current directory is 
the
+DPDK target directory):

 .. code-block:: console

 kldload