[dpdk-dev] tools brainstorming

[Don Provan]

>NOTE Please avoid, as much as possible, including headers from other headers 
>file. Doing so should be properly explained and justified.

Actually, I think a *failure* to #include other header files that this header 
file depends on should be what needs explained and justified. It drives me 
crazy when a header file forces me to figure out what header files it depends 
on and then forces me to include them in my sources even though my sources 
don't use them. Especially when #include is such a straightforward way to 
document the dependency while keeping me out of it.

Or are you only talking about when the header file doesn't depend on the header 
files its #including? If so, then I'd prefer ruling it out entirely rather than 
saying it needs to be justified.

>For consistency, getopt(3) should be used to parse options.

I assume this means the getopt() family, and I'd expect getopt_long() to be 
used normally. (If it were me, I'd *encourage* getopt_long() over getopt().)

>not:: 
> if (!*p)

I'm not sure why you'd bother to rule out this common idiom or the similar NULL 
pointer check. Are "if (*p)" and "if (p)" also prohibited, or just their 
negations?

>Values in return statements should be enclosed in parentheses.

Please don't encourage people to have this silly habit. It makes no more sense 
than insisting variables be set with "x = (-1)".

>static void
> usage()

This has nothing to do with the point being made here in your document, but 
surely you want to insist on "static void usage(void)", right? In fact, you 
might mention parameterless functions explicitly in the section on function 
declarations.

Everything else looks pretty cool. I'm surprised and impressed.
-don provan

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, April 8, 2015 5:16 PM
> To: Wiles, Keith; Butler, Siobhan A
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> 2015-04-08 15:53, Wiles, Keith:
> > One of the biggest problems with any style is helping the developer
> > maintain the style. Using some tool does help and I have used astyle
> > before, not bad code formatter. Here is a few that seem to be reasonable.
> >
> > http://astyle.sourceforge.net/
> >
> > http://uncrustify.sourceforge.net/
> >
> > http://sourceforge.net/projects/gcgreatcode/
> 
> I'm not sure it's a good idea to convert the codebase automatically.
> The coding style must be a reference for new patches and they must be
> automatically checked with a dedicated checkpatch tool.
> By forbidding patches which don't comply, the codebase will be naturally
> converted over time.
> 
> I didn't review this proposal yet.
> My first comment is that it's too long to read :) When a consensus is done, it
> must be added with a patch with custom checkpatch addition.
Thanks Thomas, agreed it is a bit of a novel :)- I will refactor with the 
comments supplied so far and post a fresh version tomorrow.
Siobhan 

[dpdk-dev] [PATCH] doc: fix vhost guide

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Igor Ryzhov
> Sent: Wednesday, April 8, 2015 5:31 PM
> To: dev at dpdk.org
> Cc: Igor Ryzhov
> Subject: [dpdk-dev] [PATCH] doc: fix vhost guide
> 
> Guide says that a configure parameter to choose between vhost cuse and
> vhost user will be introduced in the future, but it?s already added by commit
> 28a1ccca41bf.
Good point Igor- thanks for the spot.
Siobhan
> 
> Signed-off-by: Igor Ryzhov 
> ---
>  doc/guides/sample_app_ug/vhost.rst | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guides/sample_app_ug/vhost.rst
> b/doc/guides/sample_app_ug/vhost.rst
> index 8a7eb3b..df8cd8c 100644
> --- a/doc/guides/sample_app_ug/vhost.rst
> +++ b/doc/guides/sample_app_ug/vhost.rst
> @@ -309,13 +309,12 @@ Compiling the Sample Code
> 
>  CONFIG_RTE_LIBRTE_VHOST=n
> 
> -vhost user is turned on by default in the lib/librte_vhost/Makefile.
> -To enable vhost cuse, uncomment vhost cuse and comment vhost user
> manually. In future, a configure will be created for switch between two
> implementations.
> +vhost user is turned on by default in the configure file
> config/common_linuxapp.
> +To enable vhost cuse, disable vhost user.
> 
>  .. code-block:: console
> 
> -SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_cuse/vhost-net-cdev.c
> vhost_cuse/virtio-net-cdev.c vhost_cuse/eventfd_copy.c
> -#SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_user/vhost-net-user.c
> vhost_user/virtio-net-user.c vhost_user/fd_man.c
> +CONFIG_RTE_LIBRTE_VHOST_USER=y
> 
>   After vhost is enabled and the implementation is selected, build the 
> vhost
> library.
> 
> --
> 1.9.5 (Apple Git-50.3)

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Wednesday, April 8, 2015 7:16 PM
> To: Butler, Siobhan A
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> Thanks for doing this, it is a great start.
> I admit strong bias towards Linux kernel style.
> 
> Could you use one of the standard markup styles so that it could get put in
> documentation?


Sure Stephen - will tidy it all up when we get a consensus :) 
Thanks for the feedback 
Siobhan 
> 
> 
> > License Header
> > --
> 
> I prefer the file just say that it is BSD or GPL and refer to license files 
> in the
> package. That way if something has to change it doesn't need a massive
> license sweep
> 
> 
> >
> > Macros
> >
> > Do not ``#define`` or declare names in the implementation namespace
> except for implementing application interfaces.
> >
> > The names of ``unsafe`` macros (ones that have side effects), and the
> names of macros for manifest constants, are all in uppercase.
> >
> > The expansions of expression-like macros are either a single token or
> > have outer parentheses. If a macro is an inline expansion of a
> > function, the function name is all in lowercase and the macro has the same
> name all in uppercase. Right-justify the backslashes; it makes it easier to
> read. If the macro encapsulates a compound statement, enclose it in a do
> loop, so that it can be used safely in if statements.
> > Any final statement-terminating semicolon should be supplied by the
> macro invocation rather than the macro, to make parsing easier for pretty-
> printers and editors.
> >  #define MACRO(x, y) do {\
> >  variable = (x) + (y);   \
> >  (y) += 2;   \
> >  }while (0)
> ^ bad whitespace
> 
> it is important that all examples in documentation are perfect.
> 
> 
> > C Function Definition, Declaration and Use
> >
> > Prototypes
> >
> > It is recommended, but not required that all functions are prototyped
> somewhere.
> >
> > Any function prototypes for private functions (that is, functions not used
> elsewhere) go at the top of the first source module. Functions
> > local to one source module should be declared static.
> 
> I find prototypes for private functions to be redundant and error prone.
> The do nothing. Better to just put private functions in the correct order.
> 
> 
> You also need to raise the issue that all global names need to be prefaced by
> a unique string.
> I see places in drivers where global names leak out causing possible later
> name collision.
> 
> > Definitions
> > ---
> >
> > The function type should be on a line by itself preceding the function. The
> opening brace of the function body should be on a line by itself.
> >  static char *
> >  function(int a1, int a2, float fl, int a4)
> >  {
> 
> Not a big fan of that style. Prefer it on same line.
> 
> 
> >
> > Indentation is a hard tab, that is, a tab character, not a sequence of 
> > spaces.
> 
> Also no spaces before tabs.
> 
> > NOTE General rule in DPDK, use tabs for indentation, spaces for alignment.
> > If you have to wrap a long statement, put the operator at the end of the
> line, and indent again. For control statements (if, while, etc.),
> > it is recommended that the next line be indented by two tabs, rather than
> one, to prevent confusion as to whether the second line of the
> > control statement forms part of the statement body or not. For non-
> control statements, this issue does not apply, so they can be indented
> > by a single tab. However, a two-tab indent is recommended in this case
> also to keep consistency across all statement types.
> >  while (really_long_variable_name_1 == really_long_variable_name_2 &&
> >  var3 == var4){
> >  x = y + z;  /* control stmt body lines up with second line of */
> >  a = b + c;  /* control statement itself if single indent used */
> >  }
> >
> >  if (really_long_variable_name_1 == really_long_variable_name_2 &&
> >  var3 == var4){  /* two tabs used */
> 
> No. Should line up with really_long_variable_name_1
> 
> >  x = y + z;  /* statement body no longer lines up */
> >  a = b + c;
> >  }
> >
> >  z = a + really + long + statement + that + needs +
> >  two + lines + gets + indented + on + the +
> >  second + and + subsequent + lines;
> >
> >
> > Do not add whitespace at the end of a line.
> >
> > Closing and opening braces go on the same line as the else keyword. Braces
> that are not necessary should be left out.
> >  if (test)
> >  stmt;
> >  else if (bar) {
> >  stmt;
> >  stmt;
> >  } else
> >  stmt;
> >
> >
> > Function Calls
> > --
> >
> > Do not use spaces after function names. Commas should have a space after
> them. No spaces after ``(`` or ``[`` or preceding the 

[dpdk-dev] [PATCH] doc: fix vhost guide

[Igor Ryzhov]

Guide says that a configure parameter to choose between vhost cuse and vhost 
user will be introduced in the future, but it?s already added by commit 
28a1ccca41bf.

Signed-off-by: Igor Ryzhov 
---
 doc/guides/sample_app_ug/vhost.rst | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/doc/guides/sample_app_ug/vhost.rst 
b/doc/guides/sample_app_ug/vhost.rst
index 8a7eb3b..df8cd8c 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -309,13 +309,12 @@ Compiling the Sample Code

 CONFIG_RTE_LIBRTE_VHOST=n

-vhost user is turned on by default in the lib/librte_vhost/Makefile.
-To enable vhost cuse, uncomment vhost cuse and comment vhost user 
manually. In future, a configure will be created for switch between two 
implementations.
+vhost user is turned on by default in the configure file 
config/common_linuxapp.
+To enable vhost cuse, disable vhost user.

 .. code-block:: console

-SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_cuse/vhost-net-cdev.c 
vhost_cuse/virtio-net-cdev.c vhost_cuse/eventfd_copy.c
-#SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_user/vhost-net-user.c 
vhost_user/virtio-net-user.c vhost_user/fd_man.c
+CONFIG_RTE_LIBRTE_VHOST_USER=y

  After vhost is enabled and the implementation is selected, build the 
vhost library.

-- 
1.9.5 (Apple Git-50.3)

[dpdk-dev] Polling too often at lower packet rates?

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Aaron Campbell
> Sent: Wednesday, April 08, 2015 5:36 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Polling too often at lower packet rates?
> 
> Hi,
> 
> I have a machine with 6 DPDK ports (4 igb, 2 ixgbe), with 1.23Mpps traffic 
> offered to only one of the 10G ports (the other 5 are
> unused).  I also have a program with a pretty standard looking DPDK receive 
> loop, where it calls rte_eth_rx_burst() for each
> configured port.  If I configure the loop to read from all 6 ports, it can 
> read the 1.23Mpps rate with no drops.  If I configure the loop to
> poll only 1 port (the ixgbe receiving the traffic), I lose about 1/3rd of the 
> packets (i.e., the NIC drops ~400Kpps).

That seems a bit strange to see packet drops with such low rate.
Tried it with latest DPDK over 1 ixgbe port (X520-4) , 2.8 GHz IVB cpu:

./dpdk.org/x86_64-native-linuxapp-gcc/app/testpmd -c ff -n 4 
--socket-mem=1024,0 -w :04:00.1 -- -i --burst=32
testpmd> start

Tried with 1/1.5/2/3 Mpps  - no packet loss. 

Wonder to what port do you forward your packets?
What stats tells?
Does number of RX packets equal to the number of TX packets?

Konstantin

> 
> Another data point is that if I configure the loop to read from 3 out of the 
> 6 ports, the drop rate is reduced to less than half (i.e., the
> NIC is only dropping ~190Kpps now).  So it seems that in this test, 
> throughput improves by adding NICs, not removing them, which is
> counter-intuitive.  Again, I get no drops when polling all 6 ports.  Note, 
> the burst size is 32.
> 
> I did find a reference to a similar issue in a recent paper
> (http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/ICN2015.pdf), 
> Section III, which states:
> 
> "The DPDK L2FWD application initially only managed to forward 13.8 Mpps in 
> the single direction test at the maximum CPU frequency,
> a similar result can be found in [11]. Reducing the CPU frequency increased 
> the throughput to the expected value of 14.88 Mpps. Our
> investigation of this anomaly revealed that the lack of any processing 
> combined with the fast CPU caused DPDK to poll the NIC too
> often. DPDK does not use interrupts, it utilizes a busy wait loop that polls 
> the NIC until at least one packet is returned. This resulted in
> a high poll rate which affected the throughput. We limited the poll rate to 
> 500,000 poll operations per second (i.e., a batch size of
> about 30 packets) and achieved line rate in the unidirectional test with all 
> frequencies. This effect was only observed with the X520
> NIC, tests with X540 NICs did not show this anomaly.?
> 
> Another reference, from this mailing list last year 
> (http://wiki.dpdk.org/ml/archives/dev/2014-January/001169.html):
> 
> "I suggest you to check average burst sizes on receive queues. Looks like I 
> stumbled upon a similar issue several times. If you are
> calling rte_eth_rx_burst too frequently, NIC begins losing packets no matter 
> how many CPU horse power you have (more you have,
> more it loses, actually). In my case this situation occured when average 
> burst size is less than 20 packets or so. I'm not sure what's the
> reason for this behavior, but I observed it on several applications on Intel 
> 82599 10Gb cards.?
> 
> So I?m wondering if anyone can explain at a lower level what happens when you 
> poll ?too often?, and if there are any practical
> workarounds.  We?re using this same program and DPDK version to process 10G 
> line-rate in other scenarios, so I?m confident that the
> overall packet capture architecture is sound.
> 
> -Aaron

[dpdk-dev] tools brainstorming

[Thomas Monjalon]

2015-04-08 15:53, Wiles, Keith:
> One of the biggest problems with any style is helping the developer
> maintain the style. Using some tool does help and I have used astyle
> before, not bad code formatter. Here is a few that seem to be reasonable.
> 
> http://astyle.sourceforge.net/
> 
> http://uncrustify.sourceforge.net/
> 
> http://sourceforge.net/projects/gcgreatcode/

I'm not sure it's a good idea to convert the codebase automatically.
The coding style must be a reference for new patches and they must be
automatically checked with a dedicated checkpatch tool.
By forbidding patches which don't comply, the codebase will be naturally
converted over time.

I didn't review this proposal yet.
My first comment is that it's too long to read :)
When a consensus is done, it must be added with a patch with custom
checkpatch addition.

[dpdk-dev] tools brainstorming

[Jay Rolette]

"C comments" includes //, right? It's been part of the C standard for a long 
time now...

Sent from my iPhone

> On Apr 8, 2015, at 8:40 AM, Butler, Siobhan A  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: Neil Horman [mailto:nhorman at tuxdriver.com]
>> Sent: Wednesday, April 8, 2015 2:11 PM
>> To: Butler, Siobhan A
>> Cc: Thomas Monjalon; dev at dpdk.org
>> Subject: Re: [dpdk-dev] tools brainstorming
>> 
>>> On Wed, Apr 08, 2015 at 12:16:10PM +, Butler, Siobhan A wrote:
>>> 
>>> 
 -Original Message-
 From: Neil Horman [mailto:nhorman at tuxdriver.com]
 Sent: Wednesday, April 8, 2015 12:44 PM
 To: Butler, Siobhan A
 Cc: Thomas Monjalon; dev at dpdk.org
 Subject: Re: [dpdk-dev] tools brainstorming
 
> On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> Hi all,
> To add to the tools brainstorming - I propose we use the following
> Coding
 Standards as the basis of guidelines on coding style going forward.
> The style outlined below is in alignment with the current
> convention used
 for the majority of the project.
> Any thoughts/suggestions or feedback welcome.
> Thanks
> Siobhan :)
> 
> 
> 
> 
> Coding Style
> ~~
> 
> Description
> ---
> 
> This document specifies the preferred style for source files in
> the DPDK
 source tree.
> It is based on the Linux Kernel coding guidelines and the FreeBSD
> 7.2 Kernel Developer's Manual (see man style(9)), but was heavily
> modified for
 the needs of the DPDK. Many of the style rules are implicit in the
>> examples.
> Be careful to check the examples before assuming that style is
> silent on an
 issue.
> 
> General Guidelines
> --
> 
> The rules and guidelines given in this document cannot cover every
 situation, so the following general guidelines should be used as a 
 fallback:
> The code style should be consistent within each individual file,
> and within each file in a given directory or module - in the case
> of creating new
 files The primary reason for coding standards is to increase code
 readability and comprehensibility, therefore always use whatever
 option will make the code easiest to read.
> 
> The following more specific recommendations apply to all sections,
> both for
 C and assembly code:
> Line length is recommended to be not more than 80 characters,
> including comments. [Tab stop size should be assumed to be at
> least 4-
 characters wide] Indentation should be to no more than 3 levels deep.
> NOTE The above are recommendations, and not hard limits. However,
> it is
 expected that the recommendations should be followed in all but the
 rarest situations.
> C Comment Style
> 
> Usual Comments
> --
> 
> These comments should be used in normal cases. To document a
> public
 API, a doxygen-like format must be used: refer to Doxygen
>> Documentation.
> /*
>  * VERY important single-line comments look like this.
>  */
> 
> /* Most single-line comments look like this. */
> 
> /*
>  * Multi-line comments look like this.  Make them real sentences. Fill
>  * them so they look like real paragraphs.
>  */
> 
> License Header
> --
> 
> Each file should begin with a special comment tag which will
> contain the
 appropriate copyright and license for the file (Generally BSD License).
> After any copyright header, a blank line should be left before any
> other
 contents, e.g. include statements in a C file.
 
 This can become very confusing.  There already is a LICENSE.GPL and
 LICENSE.LGPL file at the top of the project, allowing others to
 insert their own licenses within their files can make it difficult
 for end user to determine if it is legally safe to use a given project.
 
 I'd suggest instead that contributions be disallowed from including
 license files in their code, relying instead on only a single
 license at the top of the project (which should likely be BSD or LGPL, 
 since
>> we're shipping a library).
 
 IANAL, but it seems to me to be dangerous to do anything else.  For
 example, all the code that is dual licensed in the library (like
 rte_pci_dev_ids.h).  It allows for a BSD or GPL license.  If someone
 builds dpdk as a DSO and distributes it under the former, every
 application that links against that re-distribution may arguably
 itself become GPL licensed.  While I'm personally fine with that, I
 can see it as being a big deal to some end users.  Unifying the
 license makes the re-distribution license issue more clear for everyone.
 
 Neil
>>> 
>>> 
>>> Input appreciated Neil thank you, would it be best 

[dpdk-dev] tools brainstorming

[Wiles, Keith]

On 4/8/15, 11:16 AM, "Thomas Monjalon"  wrote:

>2015-04-08 15:53, Wiles, Keith:
>> One of the biggest problems with any style is helping the developer
>> maintain the style. Using some tool does help and I have used astyle
>> before, not bad code formatter. Here is a few that seem to be
>>reasonable.
>> 
>> http://astyle.sourceforge.net/
>> 
>> http://uncrustify.sourceforge.net/
>> 
>> http://sourceforge.net/projects/gcgreatcode/
>
>I'm not sure it's a good idea to convert the codebase automatically.
>The coding style must be a reference for new patches and they must be
>automatically checked with a dedicated checkpatch tool.

I was not suggesting these tools be used automatically only to get code to
comply as it is being imported or patched. If we product a config file for
one of the above tools then everyone can review his code before sending
the patch.

>By forbidding patches which don't comply, the codebase will be naturally
>converted over time.

It is difficult to view patches to determine if they comply, which is the
only problem. Seeing the patched file is easier to see code format
problems IMO.
>
>I didn't review this proposal yet.
>My first comment is that it's too long to read :)
>When a consensus is done, it must be added with a patch with custom
>checkpatch addition.
>

[dpdk-dev] [PATCH v3 5/5] mk: update LDLIBS for app building

[Sergio Gonzalez Monroy]

Given the circular dependencies between eal, malloc, mempool and ring
libraries and that eal does not have proper DT_NEEDED entries, we work
around it by forcing linking against mentioned libraries by preceding
them with --no-as-needed flag when building shared libraries.

This patch also does:
 - Set --start-group/--end-group and --whole-archive/--no-whole-archive
   flags only when linking against static DPDK libs.
 - Set --as-needed for all libraries but eal, malloc, mempool and
   ring when linking against shared DPDK libs.
 - Link against EXECENV_LIBS always with --as-needed flag.

Signed-off-by: Sergio Gonzalez Monroy 
---
 mk/rte.app.mk | 54 ++
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index e8630b6..2d6b2ca 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -59,7 +59,30 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib
 #
 ifeq ($(NO_AUTOLIBS),)

-LDLIBS += --whole-archive
+LDLIBS += --no-as-needed
+ifneq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDLIBS += --start-group
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_EAL),y)
+LDLIBS += -lrte_eal
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_MALLOC),y)
+LDLIBS += -lrte_malloc
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_MEMPOOL),y)
+LDLIBS += -lrte_mempool
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_RING),y)
+LDLIBS += -lrte_ring
+endif
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDLIBS += --as-needed
+endif

 ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
 LDLIBS += -lrte_distributor
@@ -127,7 +150,7 @@ LDLIBS += -lm
 LDLIBS += -lrt
 endif

-ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
+ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
 LDLIBS += -lrte_vhost
 endif

@@ -143,8 +166,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_MLX4_PMD),y)
 LDLIBS += -libverbs
 endif

-LDLIBS += --start-group
-
 ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
 LDLIBS += -lrte_kvargs
 endif
@@ -161,22 +182,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_ETHER),y)
 LDLIBS += -lethdev
 endif

-ifeq ($(CONFIG_RTE_LIBRTE_MALLOC),y)
-LDLIBS += -lrte_malloc
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_MEMPOOL),y)
-LDLIBS += -lrte_mempool
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_RING),y)
-LDLIBS += -lrte_ring
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_EAL),y)
-LDLIBS += -lrte_eal
-endif
-
 ifeq ($(CONFIG_RTE_LIBRTE_CMDLINE),y)
 LDLIBS += -lrte_cmdline
 endif
@@ -196,6 +201,7 @@ endif

 ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
 # plugins (link only if static libraries)
+LDLIBS += --whole-archive

 ifeq ($(CONFIG_RTE_LIBRTE_VMXNET3_PMD),y)
 LDLIBS += -lrte_pmd_vmxnet3_uio
@@ -241,14 +247,14 @@ ifeq ($(CONFIG_RTE_LIBRTE_PMD_AF_PACKET),y)
 LDLIBS += -lrte_pmd_af_packet
 endif

+LDLIBS += --no-whole-archive
+LDLIBS += --end-group
+LDLIBS += --as-needed
+
 endif # plugins

 LDLIBS += $(EXECENV_LDLIBS)

-LDLIBS += --end-group
-
-LDLIBS += --no-whole-archive
-
 endif # ifeq ($(NO_AUTOLIBS),)

 LDLIBS += $(CPU_LDLIBS)
-- 
1.9.3

[dpdk-dev] [PATCH v3 4/5] mk: use LDLIBS when linking shared libraries

[Sergio Gonzalez Monroy]

This patch mainly makes use of the LDLIBS variable when linking shared
libraries, setting proper DT_NEEDED entries.

This patch also fixes a few nits like syntax highlighting, the command
string (O_TO_S_CMD) used for linking shared libraries and the displayed
of dependencies when debugging is enable (D).

Signed-off-by: Sergio Gonzalez Monroy 
---
 mk/rte.lib.mk | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index d96101a..603badf 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -62,16 +62,19 @@ build: _postbuild

 exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1

+_LDLIBS := --as-needed $(LDLIBS) $(EXECENV_LDLIBS) --no-as-needed
+
 ifeq ($(LINK_USING_CC),1)
 # Override the definition of LD here, since we're linking with CC
 LD := $(CC) $(CPU_CFLAGS)
 _CPU_LDFLAGS := $(call linkerprefix,$(CPU_LDFLAGS))
+_LDLIBS := $(call linkerprefix,$(_LDLIBS))
 else
 _CPU_LDFLAGS := $(CPU_LDFLAGS)
 endif

 O_TO_A = $(AR) crus $(LIB) $(OBJS-y)
-O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #'# fix syntax highlight
+O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #')# fix syntax highlight
 O_TO_A_DISP = $(if $(V),"$(O_TO_A_STR)","  AR $(@)")
 O_TO_A_CMD = "cmd_$@ = $(O_TO_A_STR)"
 O_TO_A_DO = @set -e; \
@@ -79,9 +82,11 @@ O_TO_A_DO = @set -e; \
$(O_TO_A) && \
echo $(O_TO_A_CMD) > $(call exe2cmd,$(@))

-O_TO_S = $(LD) $(_CPU_LDFLAGS) -shared $(OBJS-y) -Wl,-soname,$(LIB) -o $(LIB)
-O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
+O_TO_S = $(LD) $(_CPU_LDFLAGS) -L $(RTE_OUTPUT)/lib -Wl,-soname,$(LIB) \
+-shared $(OBJS-y) $(_LDLIBS) -o $(LIB)
+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)"
 O_TO_S_DO = @set -e; \
echo $(O_TO_S_DISP); \
$(O_TO_S) && \
@@ -100,7 +105,7 @@ ifeq ($(LIBABIVER),)
 endif
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
$(if $(D),\
-   @echo -n "$< -> $@ " ; \
+   @echo -n "$? -> $@ " ; \
echo -n "file_missing=$(call boolean,$(file_missing)) " ; \
echo -n "cmdline_changed=$(call boolean,$(call 
cmdline_changed,$(O_TO_S_STR))) " ; \
echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; 
\
@@ -115,7 +120,7 @@ else
 $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
$(if $(D),\
-   @echo -n "$< -> $@ " ; \
+   @echo -n "$? -> $@ " ; \
echo -n "file_missing=$(call boolean,$(file_missing)) " ; \
echo -n "cmdline_changed=$(call boolean,$(call 
cmdline_changed,$(O_TO_A_STR))) " ; \
echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; \
-- 
1.9.3

[dpdk-dev] [PATCH v3 3/5] lib: set LDLIBS for each library

[Sergio Gonzalez Monroy]

When creating shared libraries, each library will be linked against
their dependant libraries, specified by the new LDLIBS variable.

Given the circular dependencies between eal, malloc, mempool and ring,
we work around it by not linking eal against its dependent libraries.
Therefore, eal will not have proper DT_NEEDED entries (ie. no DT_NEEDED
entries for librte_malloc and librte_mempool) and we will have to force
link against them by preceding such libraries with --no-as-needed flag.

This patch sets LDLIBS variable for each library and updates DEPDIRS
of some libraries.

Signed-off-by: Sergio Gonzalez Monroy 
---
 lib/librte_acl/Makefile  | 2 ++
 lib/librte_cfgfile/Makefile  | 2 ++
 lib/librte_cmdline/Makefile  | 2 ++
 lib/librte_distributor/Makefile  | 2 ++
 lib/librte_eal/bsdapp/eal/Makefile   | 2 ++
 lib/librte_eal/linuxapp/eal/Makefile | 2 ++
 lib/librte_ether/Makefile| 5 -
 lib/librte_hash/Makefile | 2 ++
 lib/librte_ip_frag/Makefile  | 3 +++
 lib/librte_ivshmem/Makefile  | 2 ++
 lib/librte_jobstats/Makefile | 2 ++
 lib/librte_kni/Makefile  | 2 ++
 lib/librte_kvargs/Makefile   | 2 ++
 lib/librte_lpm/Makefile  | 2 ++
 lib/librte_malloc/Makefile   | 2 ++
 lib/librte_mbuf/Makefile | 2 ++
 lib/librte_mempool/Makefile  | 2 ++
 lib/librte_meter/Makefile| 2 ++
 lib/librte_pipeline/Makefile | 2 ++
 lib/librte_pmd_af_packet/Makefile| 2 ++
 lib/librte_pmd_bond/Makefile | 6 ++
 lib/librte_pmd_e1000/Makefile| 2 ++
 lib/librte_pmd_enic/Makefile | 3 +++
 lib/librte_pmd_fm10k/Makefile| 2 ++
 lib/librte_pmd_i40e/Makefile | 2 ++
 lib/librte_pmd_ixgbe/Makefile| 2 ++
 lib/librte_pmd_mlx4/Makefile | 2 ++
 lib/librte_pmd_null/Makefile | 2 ++
 lib/librte_pmd_pcap/Makefile | 2 ++
 lib/librte_pmd_ring/Makefile | 4 +++-
 lib/librte_pmd_virtio/Makefile   | 2 ++
 lib/librte_pmd_vmxnet3/Makefile  | 2 ++
 lib/librte_pmd_xenvirt/Makefile  | 3 +++
 lib/librte_port/Makefile | 4 
 lib/librte_power/Makefile| 2 ++
 lib/librte_reorder/Makefile  | 2 ++
 lib/librte_ring/Makefile | 2 ++
 lib/librte_sched/Makefile| 2 ++
 lib/librte_table/Makefile| 4 
 lib/librte_timer/Makefile| 2 ++
 lib/librte_vhost/Makefile| 7 +--
 41 files changed, 99 insertions(+), 4 deletions(-)

diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
index 68dc248..00f5e33 100644
--- a/lib/librte_acl/Makefile
+++ b/lib/librte_acl/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_acl_version.map

 LIBABIVER := 1

+LDLIBS += -lrte_eal -lrte_malloc
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_ACL) += tb_mem.c

diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile
index 032c240..babe7d1 100644
--- a/lib/librte_cfgfile/Makefile
+++ b/lib/librte_cfgfile/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_cfgfile_version.map

 LIBABIVER := 1

+LDLIBS += -lrte_eal
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_cmdline/Makefile b/lib/librte_cmdline/Makefile
index 719dff6..0f7935f 100644
--- a/lib/librte_cmdline/Makefile
+++ b/lib/librte_cmdline/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_cmdline_version.map

 LIBABIVER := 1

+LDLIBS += -lrte_eal
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := cmdline.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_cirbuf.c
diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile
index 4c9af17..b275491 100644
--- a/lib/librte_distributor/Makefile
+++ b/lib/librte_distributor/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_distributor_version.map

 LIBABIVER := 1

+LDLIBS += -lrte_eal -lrte_mbuf
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor.c

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index 2357cfa..8d7a6fc 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -46,6 +46,8 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_ring
 CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_pcap
 CFLAGS += $(WERROR_FLAGS) -O3

+LDLIBS += -lrt
+
 EXPORT_MAP := rte_eal_version.map

 LIBABIVER := 1
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 01f7b70..c351a38 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -53,6 +53,8 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_af_packet
 CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_xenvirt
 CFLAGS += $(WERROR_FLAGS) -O3

+LDLIBS += -lrt
+
 # specific to linuxapp exec-env
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) := eal.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_hugepage_info.c
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index c0e5768..a1059d7 

[dpdk-dev] [PATCH v3 2/5] mk: always generate combined lib linker script

[Sergio Gonzalez Monroy]

After the patch, building DPDK will always generate a linker script
(name use is based on CONFIG_RTE_LIBNAME config option) that behaves
as a combined library when linking against it.

Signed-off-by: Sergio Gonzalez Monroy 
---
 mk/rte.combinedlib.mk | 89 +++
 mk/rte.sdkbuild.mk|  3 ++
 2 files changed, 92 insertions(+)
 create mode 100644 mk/rte.combinedlib.mk

diff --git a/mk/rte.combinedlib.mk b/mk/rte.combinedlib.mk
new file mode 100644
index 000..46d6ee9
--- /dev/null
+++ b/mk/rte.combinedlib.mk
@@ -0,0 +1,89 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+default: all
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+EXT:=.so
+else
+EXT:=.a
+endif
+
+COMBINEDLIB := lib$(RTE_LIBNAME).so
+
+CORE_LIBS := librte_eal librte_mempool librte_malloc librte_ring
+CORE_LIBS := $(addsuffix $(EXT),$(CORE_LIBS))
+
+ALL_LIBS := $(wildcard $(RTE_OUTPUT)/lib/*$(EXT))
+ALL_LIBS := $(filter-out $(CORE_LIBS),$(notdir $(ALL_LIBS)))
+
+# If we change the combined lib name and we build dpdk without doing
+# 'make uninstall', the previous linker script would be present in the dir.
+filter_type = $(if $(shell file $(lib) | grep "ASCII text"),,$(lib))
+LIBS := $(foreach lib,$(ALL_LIBS),$(filter_type))
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT = INPUT (
+else
+LDSCRIPT = GROUP (
+endif
+
+LDSCRIPT += $(CORE_LIBS)
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT += AS_NEEDED (
+endif
+
+# For shared libs we do not care if we link against PMDs here,
+# they will be ignored (ie. after AS_NEEDED) as there are no direct
+# references to them
+LDSCRIPT += $(LIBS)
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT += )
+endif
+
+LDSCRIPT += )
+
+all: FORCE
+   $(Q)echo "$(LDSCRIPT)" > $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+#
+# Clean all generated files
+#
+.PHONY: clean
+clean:
+   $(Q)rm -f $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+.PHONY: FORCE
+FORCE:
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 2b24e74..625e0c4 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -93,6 +93,9 @@ $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
+   @if [ $@ = lib ]; then \
+   $(MAKE) -f $(RTE_SDK)/mk/rte.combinedlib.mk; \
+   fi

 %_clean:
@echo "== Clean $*"
-- 
1.9.3

[dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options

[Sergio Gonzalez Monroy]

Currently, the target/rules to build combined libraries is different
than the one to build individual libraries.

By removing the combined library option as a build configuration option
we simplify the build pocess by having a single point for linking/archiving
libraries in DPDK.

This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
removes the makefiles associated with building a combined library.

The CONFIG_RTE_LIBNAME config option is kept as it will be use to
always generate a linker script that acts as a single combined library.

Signed-off-by: Sergio Gonzalez Monroy 
---
 config/common_bsdapp   |   3 +-
 config/common_linuxapp |   3 +-
 lib/Makefile   |   1 -
 mk/rte.app.mk  |  12 --
 mk/rte.lib.mk  |  35 -
 mk/rte.sdkbuild.mk |   3 --
 mk/rte.sharelib.mk | 101 -
 mk/rte.vars.mk |   4 --
 8 files changed, 2 insertions(+), 160 deletions(-)
 delete mode 100644 mk/rte.sharelib.mk

diff --git a/config/common_bsdapp b/config/common_bsdapp
index a8ba484..ab6be97 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -79,9 +79,8 @@ CONFIG_RTE_FORCE_INTRINSICS=n
 CONFIG_RTE_BUILD_SHARED_LIB=n

 #
-# Combine to one single library
+# Combined library name
 #
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
 CONFIG_RTE_LIBNAME=intel_dpdk

 #
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 0b25f34..1ae4304 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -79,9 +79,8 @@ CONFIG_RTE_FORCE_INTRINSICS=n
 CONFIG_RTE_BUILD_SHARED_LIB=n

 #
-# Combine to one single library
+# Combined library name
 #
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
 CONFIG_RTE_LIBNAME="intel_dpdk"

 #
diff --git a/lib/Makefile b/lib/Makefile
index d94355d..c34cf2f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -77,5 +77,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
 DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
 endif

-include $(RTE_SDK)/mk/rte.sharelib.mk
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 56886dc..e8630b6 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -61,12 +61,6 @@ ifeq ($(NO_AUTOLIBS),)

 LDLIBS += --whole-archive

-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-LDLIBS += -l$(RTE_LIBNAME)
-endif
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
 ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
 LDLIBS += -lrte_distributor
 endif
@@ -137,8 +131,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
 LDLIBS += -lrte_vhost
 endif

-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
 ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
 LDLIBS += -lpcap
 endif
@@ -153,8 +145,6 @@ endif

 LDLIBS += --start-group

-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
 ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
 LDLIBS += -lrte_kvargs
 endif
@@ -253,8 +243,6 @@ endif

 endif # plugins

-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
 LDLIBS += $(EXECENV_LDLIBS)

 LDLIBS += --end-group
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 0d7482d..d96101a 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -87,24 +87,6 @@ O_TO_S_DO = @set -e; \
$(O_TO_S) && \
echo $(O_TO_S_CMD) > $(call exe2cmd,$(@))

-ifeq ($(RTE_BUILD_SHARED_LIB),n)
-O_TO_C = $(AR) crus $(LIB_ONE) $(OBJS-y)
-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)","  AR_C $(@)")
-O_TO_C_DO = @set -e; \
-   $(lib_dir) \
-   $(copy_obj)
-else
-O_TO_C = $(LD) -shared $(OBJS-y) -o $(LIB_ONE)
-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)","  LD_C $(@)")
-O_TO_C_DO = @set -e; \
-   $(lib_dir) \
-   $(copy_obj)
-endif
-
-copy_obj = cp -f $(OBJS-y) $(RTE_OUTPUT)/build/lib;
-lib_dir = [ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib;
 -include .$(LIB).cmd

 #
@@ -129,15 +111,6 @@ endif
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_S_DO))
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-   $(if $(or \
-$(file_missing),\
-$(call cmdline_changed,$(O_TO_C_STR)),\
-$(depfile_missing),\
-$(depfile_newer)),\
-$(O_TO_C_DO))
-endif
 else
 $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
@@ -153,14 +126,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_A_DO))
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-   $(if $(or \
-$(file_missing),\
-$(call cmdline_changed,$(O_TO_C_STR)),\
-$(depfile_missing),\
-$(depfile_newer)),\
-$(O_TO_C_DO))
-endif
 endif

 #
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 3154457..2b24e74 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -93,9 +93,6 @@ $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
-   @if [ 

[dpdk-dev] [PATCH v3 0/5] Enhance build process

[Sergio Gonzalez Monroy]

This patch series has the following goals:
 - Remove config option to build a combined library to simplify maintenance.
 - Add makefile to always generate linker script that behaves like a
   combined library.
 - For shared libraries, explicitly link against dependant libraries (adding
   entries to DT_NEEDED).
 - Update app linking flags for static/shared DPDK libs.

v3:
 - keep CONFIG_RTE_LIBNAME config option.
 - add makefile to always generate a linker script that behaves like a
   combined library.
 - rebase patch

v2:
 - Do not create a core library to solve circular dependencies between
   eal, malloc, mempool and ring libraries. Instead, add DT_NEEDED
   entries for all libraries but eal, then for application linking,
   always link against these libraries by preceding them with
   --no-as-needed flag.

Sergio Gonzalez Monroy (5):
  mk: remove combined library and related options
  mk: always generate combined lib linker script
  lib: set LDLIBS for each library
  mk: use LDLIBS when linking shared libraries
  mk: update LDLIBS for app building

 config/common_bsdapp |   3 +-
 config/common_linuxapp   |   3 +-
 lib/Makefile |   1 -
 lib/librte_acl/Makefile  |   2 +
 lib/librte_cfgfile/Makefile  |   2 +
 lib/librte_cmdline/Makefile  |   2 +
 lib/librte_distributor/Makefile  |   2 +
 lib/librte_eal/bsdapp/eal/Makefile   |   2 +
 lib/librte_eal/linuxapp/eal/Makefile |   2 +
 lib/librte_ether/Makefile|   5 +-
 lib/librte_hash/Makefile |   2 +
 lib/librte_ip_frag/Makefile  |   3 ++
 lib/librte_ivshmem/Makefile  |   2 +
 lib/librte_jobstats/Makefile |   2 +
 lib/librte_kni/Makefile  |   2 +
 lib/librte_kvargs/Makefile   |   2 +
 lib/librte_lpm/Makefile  |   2 +
 lib/librte_malloc/Makefile   |   2 +
 lib/librte_mbuf/Makefile |   2 +
 lib/librte_mempool/Makefile  |   2 +
 lib/librte_meter/Makefile|   2 +
 lib/librte_pipeline/Makefile |   2 +
 lib/librte_pmd_af_packet/Makefile|   2 +
 lib/librte_pmd_bond/Makefile |   6 +++
 lib/librte_pmd_e1000/Makefile|   2 +
 lib/librte_pmd_enic/Makefile |   3 ++
 lib/librte_pmd_fm10k/Makefile|   2 +
 lib/librte_pmd_i40e/Makefile |   2 +
 lib/librte_pmd_ixgbe/Makefile|   2 +
 lib/librte_pmd_mlx4/Makefile |   2 +
 lib/librte_pmd_null/Makefile |   2 +
 lib/librte_pmd_pcap/Makefile |   2 +
 lib/librte_pmd_ring/Makefile |   4 +-
 lib/librte_pmd_virtio/Makefile   |   2 +
 lib/librte_pmd_vmxnet3/Makefile  |   2 +
 lib/librte_pmd_xenvirt/Makefile  |   3 ++
 lib/librte_port/Makefile |   4 ++
 lib/librte_power/Makefile|   2 +
 lib/librte_reorder/Makefile  |   2 +
 lib/librte_ring/Makefile |   2 +
 lib/librte_sched/Makefile|   2 +
 lib/librte_table/Makefile|   4 ++
 lib/librte_timer/Makefile|   2 +
 lib/librte_vhost/Makefile|   7 ++-
 mk/rte.app.mk|  60 ++---
 mk/rte.combinedlib.mk|  89 ++
 mk/rte.lib.mk|  50 -
 mk/rte.sdkbuild.mk   |   4 +-
 mk/rte.sharelib.mk   | 101 ---
 mk/rte.vars.mk   |   4 --
 50 files changed, 229 insertions(+), 189 deletions(-)
 create mode 100644 mk/rte.combinedlib.mk
 delete mode 100644 mk/rte.sharelib.mk

-- 
1.9.3

[dpdk-dev] [RFC PATCH 4/4] Update the rte_ethdev.[ch] files for the new device generic changes.

[Keith Wiles]

rte_ethdev.c (main points):
  - Collect up the globals and static variables in the file into a new 
rte_eth_globals structure.
  - Update the global references to use the new global structure
  - Move parts of the callback routines into eal_common_device.c to all other 
device a common routine
  - Moved the debug macros PROC_PRIMARY_OR_ERR_RET, PROC_PRIMARY_OR_RET, 
FUNC_PTR_OR_ERR_RET and
FUNC_PTR_OR_RET into the rte_common_device.h as a common macro between 
devices.

rte_ethdev.h (main points):
  - Replace the first couple members in rte_eth_dev_info to commmon macro
  - Remove rte_eth_dev_cb_list define an use common rte_dev_cb_list instead
  - Move eth_[rt]x_burst_t to dev_[rt]x_burst_t in eal_common_device.h
  - Move rte_[rt]x_callback typedefs to eal_common_device.h as they are generic
  - Move rte_eth_dev_type to eal_common_device.h and rename to rte_dev_type
  - Move rte_eth_event_type to eal_common_device.h and rename to 
rte_dev_event_type
  - Replace the content of rte_eth_dev with macro RTE_COMMON_DEV in 
eal_common_device.h
Replace part of the content of rte_eth_dev_data with macro 
RTE_COMMON_DEV_DATA
Replace part of the content of rte_eth_dev_info with macro 
RTE_COMMON_DEV_INFO
  - Added the new global device structure to hold device local data instead of 
globals.
  - Some of the simple functions rte_eth_dev_count and others now call 
rte_dev_count() via macro.

The eal_common_device.c and rte_common_device.h could merged into 
eal_common_dev.c and
rte_common_dev.h, which is not done here as to not effect those files.

Signed-off-by: Keith Wiles 
---
 lib/librte_ether/rte_ethdev.c | 290 +-
 lib/librte_ether/rte_ethdev.h | 225 ++--
 2 files changed, 126 insertions(+), 389 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index e20cca5..84cef16 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -77,38 +77,20 @@
 #define PMD_DEBUG_TRACE(fmt, args...)
 #endif

-/* Macros for checking for restricting functions to primary instance only */
-#define PROC_PRIMARY_OR_ERR_RET(retval) do { \
-   if (rte_eal_process_type() != RTE_PROC_PRIMARY) { \
-   PMD_DEBUG_TRACE("Cannot run in secondary processes\n"); \
-   return (retval); \
-   } \
-} while(0)
-#define PROC_PRIMARY_OR_RET() do { \
-   if (rte_eal_process_type() != RTE_PROC_PRIMARY) { \
-   PMD_DEBUG_TRACE("Cannot run in secondary processes\n"); \
-   return; \
-   } \
-} while(0)
-
-/* Macros to check for invlaid function pointers in dev_ops structure */
-#define FUNC_PTR_OR_ERR_RET(func, retval) do { \
-   if ((func) == NULL) { \
-   PMD_DEBUG_TRACE("Function not supported\n"); \
-   return (retval); \
-   } \
-} while(0)
-#define FUNC_PTR_OR_RET(func) do { \
-   if ((func) == NULL) { \
-   PMD_DEBUG_TRACE("Function not supported\n"); \
-   return; \
-   } \
-} while(0)
-
-static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
 struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
-static struct rte_eth_dev_data *rte_eth_dev_data = NULL;
-static uint8_t nb_ports = 0;
+
+static struct rte_eth_global eth_globals = {
+.devs   = _eth_devices[0],
+.data   = NULL,
+.nb_ports   = 0,
+.max_ports  = RTE_MAX_ETHPORTS,
+.dflt_mtu   = ETHER_MTU,
+.dev_size   = sizeof(struct rte_eth_dev),
+.data_size  = sizeof(struct rte_eth_dev_data),
+.mz_dev_data= "rte_eth_dev_data"
+};
+
+struct rte_eth_global * rte_eth_globals = _globals;

 /* spinlock for eth device callbacks */
 static rte_spinlock_t rte_eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
@@ -155,30 +137,11 @@ static struct rte_eth_xstats_name_off 
rte_txq_stats_strings[] = {
sizeof(rte_txq_stats_strings[0]))


-/**
- * The user application callback description.
- *
- * It contains callback address to be registered by user application,
- * the pointer to the parameters for callback, and the event type.
- */
-struct rte_eth_dev_callback {
-   TAILQ_ENTRY(rte_eth_dev_callback) next; /**< Callbacks list */
-   rte_eth_dev_cb_fn cb_fn;/**< Callback address */
-   void *cb_arg;   /**< Parameter for callback */
-   enum rte_eth_event_type event;  /**< Interrupt event type */
-   uint32_t active;/**< Callback is executing */
-};
-
 enum {
STAT_QMAP_TX = 0,
STAT_QMAP_RX
 };

-enum {
-   DEV_DETACHED = 0,
-   DEV_ATTACHED
-};
-
 static inline void
 rte_eth_dev_data_alloc(void)
 {
@@ -186,18 +149,18 @@ rte_eth_dev_data_alloc(void)
const struct rte_memzone *mz;

if (rte_eal_process_type() == RTE_PROC_PRIMARY){
-   mz = rte_memzone_reserve(MZ_RTE_ETH_DEV_DATA,
-

[dpdk-dev] [RFC PATCH 3/4] Update files to build new device generic common files and headers.

[Keith Wiles]

Signed-off-by: Keith Wiles 
---
 lib/librte_eal/bsdapp/eal/Makefile  | 1 +
 lib/librte_eal/common/Makefile  | 1 +
 lib/librte_eal/common/include/rte_log.h | 1 +
 lib/librte_eal/linuxapp/eal/Makefile| 1 +
 4 files changed, 4 insertions(+)

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index 2357cfa..7bb2689 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -78,6 +78,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_devargs.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_dev.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_options.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_thread.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_device.c

 CFLAGS_eal.o := -D_GNU_SOURCE
 #CFLAGS_eal_thread.o := -D_GNU_SOURCE
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 3ea3bbf..c4bf805 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -40,6 +40,7 @@ INC += rte_string_fns.h rte_version.h
 INC += rte_eal_memconfig.h rte_malloc_heap.h
 INC += rte_hexdump.h rte_devargs.h rte_dev.h
 INC += rte_pci_dev_feature_defs.h rte_pci_dev_features.h
+INC += rte_common_device.h

 ifeq ($(CONFIG_RTE_INSECURE_FUNCTION_WARNING),y)
 INC += rte_warnings.h
diff --git a/lib/librte_eal/common/include/rte_log.h 
b/lib/librte_eal/common/include/rte_log.h
index f83a0d9..543deb7 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -77,6 +77,7 @@ extern struct rte_logs rte_logs;
 #define RTE_LOGTYPE_PORT0x2000 /**< Log related to port. */
 #define RTE_LOGTYPE_TABLE   0x4000 /**< Log related to table. */
 #define RTE_LOGTYPE_PIPELINE 0x8000 /**< Log related to pipeline. */
+#define RTE_LOGTYPE_DEV 0x0001 /**< Log related to device. */

 /* these log types can be used in an application */
 #define RTE_LOGTYPE_USER1   0x0100 /**< User-defined log type 1. */
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 01f7b70..935720a 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -90,6 +90,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_common_devargs.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_common_dev.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_common_options.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_common_thread.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_common_device.c

 CFLAGS_eal.o := -D_GNU_SOURCE
 CFLAGS_eal_interrupts.o := -D_GNU_SOURCE
-- 
2.3.0

[dpdk-dev] [RFC PATCH 2/4] Add the new common device header and C file.

[Keith Wiles]

Move a number of device specific define, structures and functions
into a generic device base set of files for all device not just Ethernet.

Signed-off-by: Keith Wiles 
---
 lib/librte_eal/common/eal_common_device.c | 185 +++
 lib/librte_eal/common/include/rte_common_device.h | 617 ++
 2 files changed, 802 insertions(+)
 create mode 100644 lib/librte_eal/common/eal_common_device.c
 create mode 100644 lib/librte_eal/common/include/rte_common_device.h

diff --git a/lib/librte_eal/common/eal_common_device.c 
b/lib/librte_eal/common/eal_common_device.c
new file mode 100644
index 000..a9ef925
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_device.c
@@ -0,0 +1,185 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2014 6WIND S.A.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rte_common_device.h"
+
+void *
+rte_dev_add_callback(struct rte_dev_rxtx_callback ** cbp,
+   void * fn, void *user_param)
+{
+   struct rte_dev_rxtx_callback *cb;
+
+   cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+
+   if (cb == NULL) {
+   rte_errno = ENOMEM;
+   return NULL;
+   }
+
+   cb->fn.vp = fn;
+   cb->param = user_param;
+   cb->next = *cbp;
+   *cbp = cb;
+   return cb;
+}
+
+int
+rte_dev_remove_callback(struct rte_dev_rxtx_callback ** cbp,
+   struct rte_dev_rxtx_callback *user_cb)
+{
+   struct rte_dev_rxtx_callback *cb = *cbp;
+   struct rte_dev_rxtx_callback *prev_cb;
+
+   /* Reset head pointer and remove user cb if first in the list. */
+   if (cb == user_cb) {
+   *cbp = user_cb->next;
+   return 0;
+   }
+
+   /* Remove the user cb from the callback list. */
+   do {
+   prev_cb = cb;
+   cb = cb->next;
+
+   if (cb == user_cb) {
+   prev_cb->next = user_cb->next;
+   return 0;
+   }
+   } while (cb != NULL);
+
+   /* Callback wasn't found. */
+   return (-EINVAL);
+}
+
+int
+rte_dev_callback_register(struct rte_dev_cb_list * cb_list,
+   rte_spinlock_t * lock,
+   enum rte_dev_event_type event,
+   rte_dev_cb_fn cb_fn, void *cb_arg)
+{
+   struct rte_dev_callback *cb;
+
+   rte_spinlock_lock(lock);
+
+   TAILQ_FOREACH(cb, cb_list, next) {
+   if (cb->cb_fn == cb_fn &&
+   cb->cb_arg == cb_arg &&
+   cb->event == event) {
+   break;
+   }
+   }
+
+   /* create a new callback. */
+   if (cb == NULL && (cb = rte_zmalloc("INTR_USER_CALLBACK",
+   sizeof(struct rte_dev_callback), 0)) != NULL) {
+   cb->cb_fn = cb_fn;
+   cb->cb_arg = cb_arg;
+   cb->event = event;
+   TAILQ_INSERT_TAIL(cb_list, cb, next);
+   }
+
+   rte_spinlock_unlock(lock);
+   return ((cb == NULL) ? -ENOMEM : 0);
+}
+
+int
+rte_dev_callback_unregister(struct rte_dev_cb_list * cb_list,
+   rte_spinlock_t * lock,
+   enum rte_dev_event_type event,
+   rte_dev_cb_fn cb_fn, void 

[dpdk-dev] [RFC PATCH 1/4] Rename of device types to be generic device names.

[Keith Wiles]

Rename the RTE_ETH_PCI, VIRTUAL, ... to be RTE_DEV_PCI, ... names.

Signed-off-by: Keith Wiles 
---
 app/test/test_link_bonding.c | 10 +-
 app/test/virtual_pmd.c   |  4 ++--
 examples/link_status_interrupt/main.c|  6 +++---
 lib/librte_pmd_af_packet/rte_eth_af_packet.c |  2 +-
 lib/librte_pmd_bond/rte_eth_bond_api.c   |  6 +++---
 lib/librte_pmd_bond/rte_eth_bond_pmd.c   | 12 ++--
 lib/librte_pmd_bond/rte_eth_bond_private.h   |  2 +-
 lib/librte_pmd_e1000/em_ethdev.c |  8 
 lib/librte_pmd_e1000/em_rxtx.c   |  4 ++--
 lib/librte_pmd_e1000/igb_ethdev.c|  2 +-
 lib/librte_pmd_i40e/i40e_ethdev.c|  4 ++--
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c  |  2 +-
 lib/librte_pmd_mlx4/mlx4.c   |  2 +-
 lib/librte_pmd_null/rte_eth_null.c   |  2 +-
 lib/librte_pmd_pcap/rte_eth_pcap.c   |  2 +-
 lib/librte_pmd_ring/rte_eth_ring.c   |  2 +-
 lib/librte_pmd_virtio/virtio_ethdev.c|  2 +-
 lib/librte_pmd_xenvirt/rte_eth_xenvirt.c |  2 +-
 18 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/app/test/test_link_bonding.c b/app/test/test_link_bonding.c
index 8c24314..1e1bc01 100644
--- a/app/test/test_link_bonding.c
+++ b/app/test/test_link_bonding.c
@@ -1179,7 +1179,7 @@ int test_lsc_interrupt_count;

 static void
 test_bonding_lsc_event_callback(uint8_t port_id __rte_unused,
-   enum rte_eth_event_type type  __rte_unused, void *param 
__rte_unused)
+   enum rte_dev_event_type type  __rte_unused, void *param 
__rte_unused)
 {
pthread_mutex_lock();
test_lsc_interrupt_count++;
@@ -1231,7 +1231,7 @@ test_status_interrupt(void)

/* register link status change interrupt callback */
rte_eth_dev_callback_register(test_params->bonded_port_id,
-   RTE_ETH_EVENT_INTR_LSC, test_bonding_lsc_event_callback,
+   RTE_DEV_EVENT_INTR_LSC, test_bonding_lsc_event_callback,
_params->bonded_port_id);

slave_count = 
rte_eth_bond_active_slaves_get(test_params->bonded_port_id,
@@ -1298,7 +1298,7 @@ test_status_interrupt(void)

/* unregister lsc callback before exiting */
rte_eth_dev_callback_unregister(test_params->bonded_port_id,
-   RTE_ETH_EVENT_INTR_LSC, 
test_bonding_lsc_event_callback,
+   RTE_DEV_EVENT_INTR_LSC, 
test_bonding_lsc_event_callback,
_params->bonded_port_id);

/* Clean up and remove slaves from bonded device */
@@ -2031,7 +2031,7 @@ 
test_roundrobin_verfiy_polling_slave_link_status_change(void)

/* Register link status change interrupt callback */
rte_eth_dev_callback_register(test_params->bonded_port_id,
-   RTE_ETH_EVENT_INTR_LSC, test_bonding_lsc_event_callback,
+   RTE_DEV_EVENT_INTR_LSC, test_bonding_lsc_event_callback,
_params->bonded_port_id);

/* link status change callback for first slave link up */
@@ -2059,7 +2059,7 @@ 
test_roundrobin_verfiy_polling_slave_link_status_change(void)

/* Un-Register link status change interrupt callback */
rte_eth_dev_callback_unregister(test_params->bonded_port_id,
-   RTE_ETH_EVENT_INTR_LSC, test_bonding_lsc_event_callback,
+   RTE_DEV_EVENT_INTR_LSC, test_bonding_lsc_event_callback,
_params->bonded_port_id);


diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index f163562..6143bfb 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -478,7 +478,7 @@ virtual_ethdev_simulate_link_status_interrupt(uint8_t 
port_id,

vrtl_eth_dev->data->dev_link.link_status = link_status;

-   _rte_eth_dev_callback_process(vrtl_eth_dev, RTE_ETH_EVENT_INTR_LSC);
+   _rte_eth_dev_callback_process(vrtl_eth_dev, RTE_DEV_EVENT_INTR_LSC);
 }

 int
@@ -580,7 +580,7 @@ virtual_ethdev_create(const char *name, struct ether_addr 
*mac_addr,
goto err;

/* reserve an ethdev entry */
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   eth_dev = rte_eth_dev_allocate(name, RTE_DEV_PCI);
if (eth_dev == NULL)
goto err;

diff --git a/examples/link_status_interrupt/main.c 
b/examples/link_status_interrupt/main.c
index e6fb218..9e31028 100644
--- a/examples/link_status_interrupt/main.c
+++ b/examples/link_status_interrupt/main.c
@@ -516,14 +516,14 @@ lsi_parse_args(int argc, char **argv)
  *  void.
  */
 static void
-lsi_event_callback(uint8_t port_id, enum rte_eth_event_type type, void *param)
+lsi_event_callback(uint8_t port_id, enum rte_dev_event_type type, void *param)
 {
struct rte_eth_link link;

RTE_SET_USED(param);

printf("\n\nIn registered callback...\n");
-   printf("Event type: %s\n", type == 

[dpdk-dev] [RFC PATCH 0/4] Extending DPDK to have more devices supported

[Keith Wiles]

Hi All,

Here is a set of RFC patches to update DPDK to support a generic set of
devices. The patches that follow create two files eal_common_device.h
and rte_common_device.c and then a few items in rte_ethdev.[ch] were moved
to cleanup those files by moving the device generic values and functions
into a common set of device generic files.

In the rte_common_device.h file are a couple of macros to abstract a few
common items from rte_ethdev.h which are not ethernet specific. These
generic device specific structure members are place into macros to be
placed at the top of each new device type crypto, hardware offload, dpi,
compression and possible others to be defined later.
 Note: could have used nested structures, but required a larger change set.

I did not pull the Rx/Tx Routines into a common function, but it could be
done if everyone agrees. It does not mean every device will use a common
Rx/Tx routine. Without pulling Rx/Tx routines into a common file allows
the device writer to have similar or different set of routines.

These patches do not contain any new devices as these are being work on
today.

More cleanup of ethdev could be done to remove NIC specific features not
supported in all devices and someone needs to do that cleanup IMO.

The code is untested and I wanted to get something our for others to poke at
today and more could be pulled out of ethdev as well. I/We will be looking
at testing the code as we get more completed.

I have not finished up the crypto APIs yet, but I am planning to work on
those additions today. The crypto code we are using is the Quick Assist code
found on 01.org, but we need to update the code to be move DPDK friendly.

The QAT code does have a modified like API similar to Linux Kernel crypto API
and I want to review that code first.

Regards,
++Keith

Keith Wiles (4):
  Rename of device types to be generic device names.
  Add the new common device header and C file.
  Update files to build new device generic common files and headers.
  Update the rte_ethdev.[ch] files for the new device generic changes.

 app/test/test_link_bonding.c  |  10 +-
 app/test/virtual_pmd.c|   4 +-
 examples/link_status_interrupt/main.c |   6 +-
 lib/librte_eal/bsdapp/eal/Makefile|   1 +
 lib/librte_eal/common/Makefile|   1 +
 lib/librte_eal/common/eal_common_device.c | 185 +++
 lib/librte_eal/common/include/rte_common_device.h | 617 ++
 lib/librte_eal/common/include/rte_log.h   |   1 +
 lib/librte_eal/linuxapp/eal/Makefile  |   1 +
 lib/librte_ether/rte_ethdev.c | 290 ++
 lib/librte_ether/rte_ethdev.h | 225 +++-
 lib/librte_pmd_af_packet/rte_eth_af_packet.c  |   2 +-
 lib/librte_pmd_bond/rte_eth_bond_api.c|   6 +-
 lib/librte_pmd_bond/rte_eth_bond_pmd.c|  12 +-
 lib/librte_pmd_bond/rte_eth_bond_private.h|   2 +-
 lib/librte_pmd_e1000/em_ethdev.c  |   8 +-
 lib/librte_pmd_e1000/em_rxtx.c|   4 +-
 lib/librte_pmd_e1000/igb_ethdev.c |   2 +-
 lib/librte_pmd_i40e/i40e_ethdev.c |   4 +-
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c   |   2 +-
 lib/librte_pmd_mlx4/mlx4.c|   2 +-
 lib/librte_pmd_null/rte_eth_null.c|   2 +-
 lib/librte_pmd_pcap/rte_eth_pcap.c|   2 +-
 lib/librte_pmd_ring/rte_eth_ring.c|   2 +-
 lib/librte_pmd_virtio/virtio_ethdev.c |   2 +-
 lib/librte_pmd_xenvirt/rte_eth_xenvirt.c  |   2 +-
 26 files changed, 969 insertions(+), 426 deletions(-)
 create mode 100644 lib/librte_eal/common/eal_common_device.c
 create mode 100644 lib/librte_eal/common/include/rte_common_device.h

-- 
2.3.0

[dpdk-dev] tools brainstorming

[Stephen Hemminger]

On Wed, 8 Apr 2015 16:29:54 -0600
Jay Rolette  wrote:

> "C comments" includes //, right? It's been part of the C standard for a long 
> time now...

Yes but.
I like to use checkpatch and checkpatch enforces kernel style which does not 
allow // for
comments.

[dpdk-dev] [PATCH] Add toeplitz hash algorithm

[Stephen Hemminger]

On Wed,  8 Apr 2015 15:06:13 -0400
Vladimir Medvedkin  wrote:

> Software implementation of the Toeplitz hash function used by RSS.
> Can be used either for packet distribution on single queue NIC
> or for simulating of RSS computation on specific NIC (for example
> after GRE header decapsulating).
> 
> Signed-off-by: Vladimir Medvedkin 

> +enum rte_thash_flag {
> + RTE_THASH_L3 = 0,   //calculate hash tacking into account only l3 
> header
> + RTE_THASH_L4//calculate hash tacking into account l4 + l4 
> headers
> +};
> +
> +/**
> + * Prepare special converted key to use with rte_softrss_be()
> + * @param orig
> + *   pointer to original RSS key
> + * @param targ
> + *   pointer to target RSS key
> + */
> +
> +static inline void
> +rte_convert_rss_key(uint32_t *orig, uint32_t *targ)
orig should be const

> +{
> + int i;
> + for (i = 0; i < 10; i++) {
> + targ[i] = rte_be_to_cpu_32(orig[i]);
> + }
> +}

> +static inline uint32_t
> +rte_softrss(uint32_t sip, uint32_t dip, uint16_t sp, uint16_t dp, enum 
> rte_thash_flag flag, uint32_t *rss_key)

rss_key should be const

> +{
> + uint32_t ret = 0;
> + int i;
> + for (i = 0; i < 32; i++) {
blank line after declaration please

> + if (sip & (1 << (31 - i))) {
> + ret ^= (rte_cpu_to_be_32(*rss_key) << 
> i)|(uint32_t)((uint64_t)(rte_cpu_to_be_32(*(rss_key + 1))) >> (32 - i));

Long expression > 80 characters.
Repeated multiple times (should be inline)
Extra parens ()
Extension to 64 bits is only to avoid compiler warning?


> + }
> + }
> + rss_key++;
> + for (i = 0; i < 32; i++) {
> + if (dip & (1 << (31 - i))) {
> + ret ^= (rte_cpu_to_be_32(*rss_key) << 
> i)|(uint32_t)((uint64_t)(rte_cpu_to_be_32(*(rss_key + 1))) >> (32 - i));
> + }
> + }
> +if (flag == RTE_THASH_L4) {
> + rss_key++;
> + for (i = 0; i < 32; i++) {
> + if (((sp<<16)|dp) & (1 << (31 - i))) {
> + ret ^= (rte_cpu_to_be_32(*rss_key) << 
> i)|(uint32_t)((uint64_t)(rte_cpu_to_be_32(*(rss_key + 1))) >> (32 - i));
> + }
> + }
> + }
> + return ret;
> +}
> +
> +/**
> + * Optimized implementation.
> + * If you want the calculated hash value matches NIC RSS value
> + * you have to use special converted key.
> + * All ip's and ports have to be CPU byte order.
> + * @param sip
> + *   Source ip address.
> + * @param dip
> + *   Destination ip address.
> + * @param sp
> + *   Source TCP|UDP port.
> + * @param dp
> + *   Destination TCP|UDP port.
> + * @param flag
> + *   RTE_THASH_L3:   calculate hash tacking into account only sip and dip
> + *   RTE_THASH_L4:   calculate hash tacking into account sip, dip, sp and dp
> + * @param *rss_key
> + *   Pointer to 40-byte RSS hash key.
> + * @return
> + *   Calculated hash value.
> + */
> +
> +static inline uint32_t
> +rte_softrss_be(uint32_t sip, uint32_t dip, uint16_t sp, uint16_t dp, enum 
> rte_thash_flag flag, uint32_t *rss_key)
> +{

Same problems as previous code.
Also lots of copy paste (see Do Not Repeat Yourself principle).

[dpdk-dev] [RFC] ethdev function to update MAC multicast addresses filtered by a port

[Ivan Boule]

This RFC describes a proposed change in the ethdev API for updating
the set of multicast MAC addresses that are filtered by a port.

The change consists in adding a new function "update_mc_addr_list" that
takes the whole set of multicast MAC addresses to be filtered by a port,
if any.

In case the whole set of multicast addresses is too large for the device
resources used to record them, the ethdev function "update_mc_addr_list" 
must transparently enable the allmulticast feature of the port, if such 
a feature is supported/enabled by the device.

Reason for Change
-

With the current ethdev API, the receipt of multicast packets on a given 
port can only be enabled by invoking the "rte_eth_allmulticast_enable()" 
function.
This approach may not work on Virtual Functions in SR-IOV architectures
when the host PF driver does not allow this operation on VFs.
In such a case, joined multicast addresses must be individually added 
into the set of multicast MAC addresses that are filtered by the [VF] port.

For this purpose, a new function "update_mc_addr_list()" must be 
introduced into the set of functions exported by a Poll Mode Driver.
Each time a DPDK application joins (respectively leaves) an IP multicast
group, it must add (respectively remove) the associated multicast MAC 
address from the set of multicast address to be filtered, and invoke the 
function "update_mc_addr_list()" with the updated list of multicast 
addresses on each relevant port.

Proposed API extension
--

The new function "update_mc_addr_list" is added into the "eth_dev_ops"
data structure:

typedef int (*eth_update_mc_addr_list_t)(struct rte_eth_dev *dev,
 struct ether_addr *mc_addr_set,
 uint32_t nb_mc_addr);

It is exported through the following new function:

/**
  * Update the set of multicast addresses to filter on an Ethernet device.
  *
  * @param port_id
  *   The port identifier of the Ethernet device.
  * @param mc_addr_set
  *   The array of multicast addresses to filter. Equal to NULL when the 
function
  *   is invoked to flush all multicast MAC addresses filtered by the port.
  * @param nb_mc_addr
  *   The number of multicast addresses in the *mc_addr_set* array. 
Equal to 0
  *   when the function is invoked to flush the set of multicast MAC 
addresses.
  * @return
  *   - (0) if successful.
  *   - (-ENOTSUP) if hardware doesn't support multicast filtering.
  *   - (-ENODEV) if *port_id* invalid.
  */
int rte_eth_dev_update_mc_addr_list(uint8_t port_id,
struct ether_addr *mc_addr_set,
uint32_t nb_mc_addr);

-- 
Ivan Boule
6WIND Development Engineer

[dpdk-dev] tools brainstorming

[Wiles, Keith]

On 4/8/15, 5:43 AM, "Butler, Siobhan A"  wrote:

>Hi all,
>To add to the tools brainstorming - I propose we use the following Coding
>Standards as the basis of guidelines on coding style going forward.
>The style outlined below is in alignment with the current convention used
>for the majority of the project.
>Any thoughts/suggestions or feedback welcome.
>Thanks
>Siobhan :)
>
>

Have we looked at astyle or some code formatter to help get alignment?
>
>
>Coding Style
>~~
>
>Description
>---
>
>This document specifies the preferred style for source files in the DPDK
>source tree. 
>It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2
>Kernel Developer's Manual (see man style(9)),
>but was heavily modified for the needs of the DPDK. Many of the style
>rules are implicit in the examples.
>Be careful to check the examples before assuming that style is silent on
>an issue. 
>
>General Guidelines
>--
>
>The rules and guidelines given in this document cannot cover every
>situation, so the following general guidelines should be used as a
>fallback: 
>The code style should be consistent within each individual file, and
>within each file in a given directory or module - in the case of creating
>new files 
>The primary reason for coding standards is to increase code readability
>and comprehensibility, therefore always use whatever option will make the
>code easiest to read.
>
>The following more specific recommendations apply to all sections, both
>for C and assembly code:
>Line length is recommended to be not more than 80 characters, including
>comments. [Tab stop size should be assumed to be at least 4-characters
>wide] 
>Indentation should be to no more than 3 levels deep.
>NOTE The above are recommendations, and not hard limits. However, it is
>expected that the recommendations should be followed in all but the
>rarest situations.
>C Comment Style
>
>Usual Comments
>--
>
>These comments should be used in normal cases. To document a public API,
>a doxygen-like format must be used: refer to Doxygen Documentation.
> /*
>  * VERY important single-line comments look like this.
>  */
> 
> /* Most single-line comments look like this. */
> 
> /*
>  * Multi-line comments look like this.  Make them real sentences. Fill
>  * them so they look like real paragraphs.
>  */
>
>License Header
>--
>
>Each file should begin with a special comment tag which will contain the
>appropriate copyright and license for the file (Generally BSD License).
>After any copyright header, a blank line should be left before any other
>contents, e.g. include statements in a C file.
>
>C Preprocessor Directives
>-
>
>Header Includes
>
>In DPDK sources, the include files should be ordered as following:
> libc includes (system includes first)
> DPDK EAL includes
> DPDK misc libraries includes
> application-specific includes
>
>Example: 
> #include 
> #include 
> 
> #include 
> 
> #include 
> #include 
> 
> #include "application.h"
>
>
>Global pathnames are defined in . Pathnames local to the program
>go in "pathnames.h" in the local directory.
> #include 
>
>
>Leave another blank line before the user include files.
> #include "pathnames.h" /* Local includes in double quotes. */
>
>NOTE Please avoid, as much as possible, including headers from other
>headers file. Doing so should be properly explained and justified.
>Headers should be protected against multiple inclusion with the usual:
> #ifndef _FILE_H_
> #define _FILE_H_
> 
> /* Code */
> 
> #endif /* _FILE_H_ */
>
>
>Macros
>
>Do not ``#define`` or declare names in the implementation namespace
>except for implementing application interfaces.
>
>The names of ``unsafe`` macros (ones that have side effects), and the
>names of macros for manifest constants, are all in uppercase.
>
>The expansions of expression-like macros are either a single token or
>have outer parentheses. If a macro is an inline expansion of a function,
>the function name is all in lowercase and the macro has the same name all
>in uppercase. Right-justify the backslashes;
>it makes it easier to read. If the macro encapsulates a compound
>statement, enclose it in a do loop, so that it can be used safely in if
>statements. 
>Any final statement-terminating semicolon should be supplied by the macro
>invocation rather than the macro, to make parsing easier for
>pretty-printers and editors.
> #define MACRO(x, y) do {\
> variable = (x) + (y);   \
> (y) += 2;   \
> }while (0)
>
>NOTE Wherever possible, enums and typedefs should be preferred to macros,
>since they provide additional degrees
>of type-safety and can allow compilers to emit extra warnings about
>unsafe code. 
>
>Conditional Compilation
>---
>
>When code is conditionally compiled using #ifdef or #if, a comment may be

[dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua?

[Xie, Huawei]

On 4/7/2015 10:23 PM, Luke Gorrie wrote:
> Hi Michael,
>
> I'm writing to follow up the previous discussion about memory barriers in
> virtio-net device implementations, and Cc'ing the DPDK list because I
> believe this is relevant to them too.
>
> First, thanks again for getting in touch and reviewing our code.
>
> I have now found a missed case where we *do* require a hardware memory
> barrier on x86 in our vhost/virtio-net device. That is when checking the
> interrupt suppression flag after updating used->idx. This is needed because
> x86 can reorder the write to used->idx after the read from avail->flags,
> and that causes the guest to see a stale value of used->idx after it
> toggles interrupt suppression.
luke:
1. host read the flag. 2 guest toggles the flag 3.guest checks the used.
4. host update used.
Is this your case?

>
> If I may spell out my mental model, for the sake of being corrected and/or
> as an example of how third party developers are reading and interpreting
> the Virtio-net spec:
>
> Relating this to Virtio 1.0, the most relevant section is 3.2.1 (Supplying
> Buffers to the Device) which calls for two "suitable memory barriers". The
> spec talks about these from the driver perspective, but they are both
> relevant to the device side too.
>
> The first barrier (write to descriptor table before write to used->idx) is
> implicit on x86 because writes by the same core are not reordered. This
> means that no explicit hardware barrier is needed. (A compiler barrier may
> be needed, however.)
>
> The second memory barrier (write to used->idx before reading avail->flags)
> is not implicit on x86 because stores are reordered after loads. So an
> explicit hardware memory barrier is needed.
>
> I hope that is a correct assessment of the situation. (Forgive my
> x86centricity, I am sure that seems very foreign to kernel hackers.)
>
> If this assessment is correct then the DPDK developers might also want to
> review librte_vhost/vhost_rxtx.c and consider adding a hardware memory
> barrier between writing used->idx and reading avail->flags.
>
> Cheers,
> -Luke
>
> P.S. I notice that the Linux virtio-net driver does not seem to tolerate
> spurious interrupts, even though the Virtio 1.0 spec requires this
> ("must"). On 3.13.11-ckt15 I see them trigger an "irq nobody cared" kernel
> log message and then the irq is disabled. If that sounds suspicious I can
> supply more information.
>
>

[dpdk-dev] tools brainstorming

[Stephen Hemminger]

The userspace code has to be BSD ( no GPL ).
The Linux kernel code must be GPLv2 or BSD/GPL license.
The other kernel code should be BSD/GPL.


On Wed, Apr 8, 2015 at 11:58 AM, Matthew Hall  wrote:

> On Wed, Apr 08, 2015 at 11:16:03AM -0700, Stephen Hemminger wrote:
> > I prefer the file just say that it is BSD or GPL and refer to license
> files
> > in the package. That way if something has to change it doesn't need a
> > massive license sweep
>
> Hi guys,
>
> I hope we're also enforcing some requirement that all user-space files that
> are expected to be used inside of the address space apps must be BSD, MIT,
> or
> other license which allows binary redistribution, as part of these
> standards.
> Or we could end up causing a lot of pain for the app developers if somebody
> puts a bunch of GPL files into the user-space code which blocks their
> usage.
>
> For the Linux kernel side files, we probably need to say BSD, MIT, or GPLv2
> specifically, and not GPLv3, I think that's what Linus is using, or it
> could
> be a problem to upstream any of those as DPDK usage grows.
>
> For the BSD kernel side files, if any, probably need to be sure we're
> compatible with at least FreeBSD and NetBSD, and probably also OpenBSD.
>
> Matthew.
>

[dpdk-dev] [RFC PATCH] librte_pmd_e1000: igb and em1000 PCI Port Hotplug changes

[Bernard Iremonger]

This patch depends on the Port Hotplug Framework.
It implements the eth_dev_uninit functions for rte_em_pmd,
rte_igb_pmd and rte_igbvf_pmd.

Signed-off-by: Bernard Iremonger 
---
 lib/librte_pmd_e1000/e1000_ethdev.h |4 +-
 lib/librte_pmd_e1000/em_ethdev.c|   36 -
 lib/librte_pmd_e1000/igb_ethdev.c   |   73 +-
 lib/librte_pmd_e1000/igb_pf.c   |   29 +-
 4 files changed, 135 insertions(+), 7 deletions(-)

diff --git a/lib/librte_pmd_e1000/e1000_ethdev.h 
b/lib/librte_pmd_e1000/e1000_ethdev.h
index c451faa..51720b9 100644
--- a/lib/librte_pmd_e1000/e1000_ethdev.h
+++ b/lib/librte_pmd_e1000/e1000_ethdev.h
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -298,6 +298,8 @@ void eth_igbvf_tx_init(struct rte_eth_dev *dev);
  */
 void igb_pf_host_init(struct rte_eth_dev *eth_dev);

+void igb_pf_host_uninit(struct rte_eth_dev *eth_dev);
+
 void igb_pf_mbx_process(struct rte_eth_dev *eth_dev);

 int igb_pf_host_configure(struct rte_eth_dev *eth_dev);
diff --git a/lib/librte_pmd_e1000/em_ethdev.c b/lib/librte_pmd_e1000/em_ethdev.c
index 76f45c9..2f68251 100644
--- a/lib/librte_pmd_e1000/em_ethdev.c
+++ b/lib/librte_pmd_e1000/em_ethdev.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -280,13 +280,45 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
return (0);
 }

+static int
+eth_em_dev_uninit(struct rte_eth_dev *eth_dev)
+{
+   struct rte_pci_device *pci_dev;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (eth_dev->pci_dev == NULL)
+   return -EINVAL;
+
+   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+   return -EPERM;
+
+   pci_dev = eth_dev->pci_dev;
+
+   eth_dev->dev_ops = NULL;
+   eth_dev->rx_pkt_burst = NULL;
+   eth_dev->tx_pkt_burst = NULL;
+
+   rte_free(eth_dev->data->mac_addrs);
+   eth_dev->data->mac_addrs = NULL;
+
+   /* disable uio intr before callback unregister */
+   rte_intr_disable(&(pci_dev->intr_handle));
+   rte_intr_callback_unregister(&(pci_dev->intr_handle),
+   eth_em_interrupt_handler, (void *)eth_dev);
+
+   return 0;
+}
+
 static struct eth_driver rte_em_pmd = {
{
.name = "rte_em_pmd",
.id_table = pci_id_em_map,
-   .drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
+   .drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC |
+   RTE_PCI_DRV_DETACHABLE,
},
.eth_dev_init = eth_em_dev_init,
+   .eth_dev_uninit = eth_em_dev_uninit,
.dev_private_size = sizeof(struct e1000_adapter),
 };

diff --git a/lib/librte_pmd_e1000/igb_ethdev.c 
b/lib/librte_pmd_e1000/igb_ethdev.c
index b3892a5..f7e3da6 100644
--- a/lib/librte_pmd_e1000/igb_ethdev.c
+++ b/lib/librte_pmd_e1000/igb_ethdev.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -608,6 +608,48 @@ err_late:
return (error);
 }

+static int
+eth_igb_dev_uninit(struct rte_eth_dev *eth_dev)
+{
+   struct rte_pci_device *pci_dev;
+   struct e1000_hw *hw;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if ((eth_dev == NULL) ||
+   (eth_dev->data == NULL) ||
+   (eth_dev->data->dev_private == NULL) ||
+   (eth_dev->pci_dev == NULL))
+   return -EINVAL;
+
+   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+   return -EPERM;
+
+   hw = E1000_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+   pci_dev = eth_dev->pci_dev;
+
+   eth_dev->dev_ops = NULL;
+   eth_dev->rx_pkt_burst = NULL;
+   eth_dev->tx_pkt_burst = NULL;
+
+   /* Reset any pending lock */
+   igb_reset_swfw_lock(hw);
+
+   rte_free(eth_dev->data->mac_addrs);
+   eth_dev->data->mac_addrs = NULL;
+
+   /* uninitialize PF if max_vfs not zero */
+   igb_pf_host_uninit(eth_dev);
+
+   /* disable uio intr before callback unregister */
+   rte_intr_disable(&(pci_dev->intr_handle));
+   rte_intr_callback_unregister(&(pci_dev->intr_handle),
+   eth_igb_interrupt_handler, (void *)eth_dev);
+
+   return 0;
+}
+
+
 /*
  * Virtual Function device init
  */
@@ -679,13 +721,37 @@ eth_igbvf_dev_init(struct rte_eth_dev *eth_dev)
return 0;
 }

+static int

[dpdk-dev] [PATCH] Add toeplitz hash algorithm

[Vladimir Medvedkin]

Software implementation of the Toeplitz hash function used by RSS.
Can be used either for packet distribution on single queue NIC
or for simulating of RSS computation on specific NIC (for example
after GRE header decapsulating).

Signed-off-by: Vladimir Medvedkin 
---
 lib/librte_hash/Makefile|   1 +
 lib/librte_hash/rte_thash.h | 179 
 2 files changed, 180 insertions(+)
 create mode 100644 lib/librte_hash/rte_thash.h

diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile
index 3696cb1..083a9e5 100644
--- a/lib/librte_hash/Makefile
+++ b/lib/librte_hash/Makefile
@@ -50,6 +50,7 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include := rte_hash.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_hash_crc.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_jhash.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_fbk_hash.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_thash.h

 # this lib needs eal
 DEPDIRS-$(CONFIG_RTE_LIBRTE_HASH) += lib/librte_eal lib/librte_malloc
diff --git a/lib/librte_hash/rte_thash.h b/lib/librte_hash/rte_thash.h
new file mode 100644
index 000..1acfa3a
--- /dev/null
+++ b/lib/librte_hash/rte_thash.h
@@ -0,0 +1,179 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_THASH_H
+#define _RTE_THASH_H
+
+/**
+ * @file
+ *
+ * toeplitz hash functions.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * Software implementation of the Toeplitz hash function used by RSS.
+ * Can be used either for packet distribution on single queue NIC
+ * or for simulating of RSS computation on specific NIC (for example
+ * after GRE header decapsulating)
+ */
+
+#include 
+#include 
+
+enum rte_thash_flag {
+   RTE_THASH_L3 = 0,   //calculate hash tacking into account only l3 
header
+   RTE_THASH_L4//calculate hash tacking into account l4 + l4 
headers
+};
+
+/**
+ * Prepare special converted key to use with rte_softrss_be()
+ * @param orig
+ *   pointer to original RSS key
+ * @param targ
+ *   pointer to target RSS key
+ */
+
+static inline void
+rte_convert_rss_key(uint32_t *orig, uint32_t *targ)
+{
+   int i;
+   for (i = 0; i < 10; i++) {
+   targ[i] = rte_be_to_cpu_32(orig[i]);
+   }
+}
+
+/**
+ * Generic implementation. Can be used with original rss_key
+ * All ip's and ports have to be CPU byte order.
+ * @param sip
+ *   Source ip address.
+ * @param dip
+ *   Destination ip address.
+ * @param sp
+ *   Source TCP|UDP port.
+ * @param dp
+ *   Destination TCP|UDP port.
+ * @param flag
+ *   RTE_THASH_L3: calculate hash tacking into account only sip and dip
+ *   RTE_THASH_L4: calculate hash tacking into account sip, dip, sp and dp
+ * @param *rss_key
+ *   Pointer to 40-byte RSS hash key.
+ * @return
+ *   Calculated hash value.
+ */
+
+static inline uint32_t
+rte_softrss(uint32_t sip, uint32_t dip, uint16_t sp, uint16_t dp, enum 
rte_thash_flag flag, uint32_t *rss_key)
+{
+   uint32_t ret = 0;
+   int i;
+   for (i = 0; i < 32; i++) {
+   if (sip & (1 << (31 - i))) {
+   ret ^= (rte_cpu_to_be_32(*rss_key) << 
i)|(uint32_t)((uint64_t)(rte_cpu_to_be_32(*(rss_key + 1))) >> (32 - i));
+   }
+   }
+   rss_key++;
+   for (i = 0; i < 32; i++) {
+  

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Wednesday, April 8, 2015 2:11 PM
> To: Butler, Siobhan A
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> On Wed, Apr 08, 2015 at 12:16:10PM +, Butler, Siobhan A wrote:
> >
> >
> > > -Original Message-
> > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > Sent: Wednesday, April 8, 2015 12:44 PM
> > > To: Butler, Siobhan A
> > > Cc: Thomas Monjalon; dev at dpdk.org
> > > Subject: Re: [dpdk-dev] tools brainstorming
> > >
> > > On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> > > > Hi all,
> > > > To add to the tools brainstorming - I propose we use the following
> > > > Coding
> > > Standards as the basis of guidelines on coding style going forward.
> > > > The style outlined below is in alignment with the current
> > > > convention used
> > > for the majority of the project.
> > > > Any thoughts/suggestions or feedback welcome.
> > > > Thanks
> > > > Siobhan :)
> > > > 
> > > >
> > > >
> > > >
> > > > Coding Style
> > > > ~~
> > > >
> > > > Description
> > > > ---
> > > >
> > > > This document specifies the preferred style for source files in
> > > > the DPDK
> > > source tree.
> > > > It is based on the Linux Kernel coding guidelines and the FreeBSD
> > > > 7.2 Kernel Developer's Manual (see man style(9)), but was heavily
> > > > modified for
> > > the needs of the DPDK. Many of the style rules are implicit in the
> examples.
> > > > Be careful to check the examples before assuming that style is
> > > > silent on an
> > > issue.
> > > >
> > > > General Guidelines
> > > > --
> > > >
> > > > The rules and guidelines given in this document cannot cover every
> > > situation, so the following general guidelines should be used as a 
> > > fallback:
> > > > The code style should be consistent within each individual file,
> > > > and within each file in a given directory or module - in the case
> > > > of creating new
> > > files The primary reason for coding standards is to increase code
> > > readability and comprehensibility, therefore always use whatever
> > > option will make the code easiest to read.
> > > >
> > > > The following more specific recommendations apply to all sections,
> > > > both for
> > > C and assembly code:
> > > > Line length is recommended to be not more than 80 characters,
> > > > including comments. [Tab stop size should be assumed to be at
> > > > least 4-
> > > characters wide] Indentation should be to no more than 3 levels deep.
> > > > NOTE The above are recommendations, and not hard limits. However,
> > > > it is
> > > expected that the recommendations should be followed in all but the
> > > rarest situations.
> > > > C Comment Style
> > > >
> > > > Usual Comments
> > > > --
> > > >
> > > > These comments should be used in normal cases. To document a
> > > > public
> > > API, a doxygen-like format must be used: refer to Doxygen
> Documentation.
> > > >  /*
> > > >   * VERY important single-line comments look like this.
> > > >   */
> > > >
> > > >  /* Most single-line comments look like this. */
> > > >
> > > >  /*
> > > >   * Multi-line comments look like this.  Make them real sentences. Fill
> > > >   * them so they look like real paragraphs.
> > > >   */
> > > >
> > > > License Header
> > > > --
> > > >
> > > > Each file should begin with a special comment tag which will
> > > > contain the
> > > appropriate copyright and license for the file (Generally BSD License).
> > > > After any copyright header, a blank line should be left before any
> > > > other
> > > contents, e.g. include statements in a C file.
> > > >
> > >
> > > This can become very confusing.  There already is a LICENSE.GPL and
> > > LICENSE.LGPL file at the top of the project, allowing others to
> > > insert their own licenses within their files can make it difficult
> > > for end user to determine if it is legally safe to use a given project.
> > >
> > > I'd suggest instead that contributions be disallowed from including
> > > license files in their code, relying instead on only a single
> > > license at the top of the project (which should likely be BSD or LGPL, 
> > > since
> we're shipping a library).
> > >
> > > IANAL, but it seems to me to be dangerous to do anything else.  For
> > > example, all the code that is dual licensed in the library (like
> > > rte_pci_dev_ids.h).  It allows for a BSD or GPL license.  If someone
> > > builds dpdk as a DSO and distributes it under the former, every
> > > application that links against that re-distribution may arguably
> > > itself become GPL licensed.  While I'm personally fine with that, I
> > > can see it as being a big deal to some end users.  Unifying the
> > > license makes the re-distribution license issue more clear for everyone.
> > >
> > > Neil
> >
> >
> > Input appreciated Neil thank you, would it be best to include this in 

[dpdk-dev] tools brainstorming

[Wiles, Keith]

On 4/8/15, 5:43 AM, "Butler, Siobhan A"  wrote:

>Hi all,
>To add to the tools brainstorming - I propose we use the following Coding
>Standards as the basis of guidelines on coding style going forward.
>The style outlined below is in alignment with the current convention used
>for the majority of the project.
>Any thoughts/suggestions or feedback welcome.
>Thanks
>Siobhan :)
>
>
>
>
>Coding Style
>~~
>
>Description
>---
>
>This document specifies the preferred style for source files in the DPDK
>source tree. 
>It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2
>Kernel Developer's Manual (see man style(9)),
>but was heavily modified for the needs of the DPDK. Many of the style
>rules are implicit in the examples.
>Be careful to check the examples before assuming that style is silent on
>an issue. 
>
>General Guidelines
>--
>
>The rules and guidelines given in this document cannot cover every
>situation, so the following general guidelines should be used as a
>fallback: 
>The code style should be consistent within each individual file, and
>within each file in a given directory or module - in the case of creating
>new files 
>The primary reason for coding standards is to increase code readability
>and comprehensibility, therefore always use whatever option will make the
>code easiest to read.
>
>The following more specific recommendations apply to all sections, both
>for C and assembly code:
>Line length is recommended to be not more than 80 characters, including
>comments. [Tab stop size should be assumed to be at least 4-characters
>wide] 
>Indentation should be to no more than 3 levels deep.
>NOTE The above are recommendations, and not hard limits. However, it is
>expected that the recommendations should be followed in all but the
>rarest situations.
>C Comment Style
>
>Usual Comments
>--
>
>These comments should be used in normal cases. To document a public API,
>a doxygen-like format must be used: refer to Doxygen Documentation.
> /*
>  * VERY important single-line comments look like this.
>  */
> 
> /* Most single-line comments look like this. */
> 
> /*
>  * Multi-line comments look like this.  Make them real sentences. Fill
>  * them so they look like real paragraphs.
>  */

Did you mean to have the ?*? aligned, if so good, if not then it does not
make sense to not align them. The indent of one space here does not help
convey any information IMO.
>
>License Header
>--
>
>Each file should begin with a special comment tag which will contain the
>appropriate copyright and license for the file (Generally BSD License).
>After any copyright header, a blank line should be left before any other
>contents, e.g. include statements in a C file.
>
>C Preprocessor Directives
>-
>
>Header Includes
>
>In DPDK sources, the include files should be ordered as following:
> libc includes (system includes first)
> DPDK EAL includes
> DPDK misc libraries includes
> application-specific includes
>
>Example: 
> #include 
> #include 
> 
> #include 
> 
> #include 
> #include 
> 
> #include "application.h"
>
>
>Global pathnames are defined in . Pathnames local to the program
>go in "pathnames.h" in the local directory.
> #include 
>
>
>Leave another blank line before the user include files.
> #include "pathnames.h" /* Local includes in double quotes. */
>
>NOTE Please avoid, as much as possible, including headers from other
>headers file. Doing so should be properly explained and justified.
>Headers should be protected against multiple inclusion with the usual:
> #ifndef _FILE_H_
> #define _FILE_H_
> 
> /* Code */
> 
> #endif /* _FILE_H_ */
>
>
>Macros
>
>Do not ``#define`` or declare names in the implementation namespace
>except for implementing application interfaces.
>
>The names of ``unsafe`` macros (ones that have side effects), and the
>names of macros for manifest constants, are all in uppercase.
>
>The expansions of expression-like macros are either a single token or
>have outer parentheses. If a macro is an inline expansion of a function,
>the function name is all in lowercase and the macro has the same name all
>in uppercase. Right-justify the backslashes;
>it makes it easier to read. If the macro encapsulates a compound
>statement, enclose it in a do loop, so that it can be used safely in if
>statements. 
>Any final statement-terminating semicolon should be supplied by the macro
>invocation rather than the macro, to make parsing easier for
>pretty-printers and editors.
> #define MACRO(x, y) do {\
> variable = (x) + (y);   \
> (y) += 2;   \
> }while (0)

I have seen this  ?while( /*CONSTCOND*/0 )? (I think that is the comment)
plus I have see this ?while((0))? as gcc complained about a constant in
the while(). This one maybe fixed at this point in the compilers.
>
>NOTE Wherever 

[dpdk-dev] [PATCH v3 1/5] mbuf: fix clone support when application uses private mbuf data

[Ananyev, Konstantin]

Hi Olivier,

> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, April 08, 2015 10:44 AM
> To: Ananyev, Konstantin; dev at dpdk.org
> Cc: zoltan.kiss at linaro.org; Richardson, Bruce
> Subject: Re: [PATCH v3 1/5] mbuf: fix clone support when application uses 
> private mbuf data
> 
> Hi Konstantin,
> 
> On 04/07/2015 07:17 PM, Ananyev, Konstantin wrote:
> >> Just to be sure we're on the same line:
> >>
> >> - before the patch series
> >>
> >> - private area was working before that patch series if clones were not
> >>   used. To use a private are, the user had to provide another
> >>   function derived from pktmbuf_init() to change m->buf_addr and
> >>   m->buf_len.
> >> - using both private area + clones was broken
> >>
> >> - after the patch series
> >>
> >> - private area is working with or without clone. But yo use it,
> >>   the user still has to provide another function to change
> >>   m->buf_addr, m->buf_len *and m->priv_size*.
> >>
> >> The series just fixes the fact that "clones + priv" was not working.
> >> It does not address the problem that providing a new pktmbuf_init()
> >> function is required to use privata area. To fix this, I think it
> >> could require a API evolution that should be part of another series.
> >
> > I don't think we need new pktmbuf_init().
> > We just need to update it, so both pktmbuf_init() and detach() setup
> > buf_addr, buf_len (and priv_size) to exactly the same values.
> > If they don't do that, it means that you can't use attach/detach with
> > mempools created with pktmbuf_init() any more.
> >
> > BTW, another thing that I just realised:
> > examples/ipv4_multicast and examples/ip_fragmentation/ -
> > both create a pool of mbufs with elem_size < 2K and don't populate 
> > mempool's private area -
> > so mbp_priv->mbuf_data_room_size == 0, for them.
> >
> > So that code in detach():
> >
> >   + mbp_priv = rte_mempool_get_priv(mp);
> >   + m->priv_size = mp->elt_size - RTE_PKTMBUF_HEADROOM -
> >   + mbp_priv->mbuf_data_room_size -
> >   + sizeof(struct rte_mbuf);
> >
> >
> > Would break both these samples.
> > I suppose we need to handle situation when mp->elt_size < 
> > RTE_PKTMBUF_HEADROOM + sizeof(struct rte_mbuf),
> > (and probably also when mbuf_data_room_size == 0) correctly.
> 
> Indeed. I think a mbuf pool (even with buf_len == 0 like in
> ip_fragmentation example) should have a pool with a private area and
> should call rte_pktmbuf_pool_init() to populate it. So
> rte_pktmbuf_pool_init() has to be fixed first to use elt_size
> and support the buf_len < RTE_PKTMBUF_HEADROOM, then we can
> update frag/multicast examples.
> 
> Unfortunately, we don't know the size of the mbuf private area
> in rte_pktmbuf_pool_init() if the opaque arg (data_room_size)
> is 0, which is the default. I think it should be replaced by a structure
> containing data_room_size and mbuf_priv_size, but it would break
> applications that are setting data_room_size.

Yes, same thoughts here.

> I don't see any good
> solution to do that while keeping a backward compatibility for
> rte_pktmbuf_pool_init(), but as the current API is not ideal,
> I think it's worth changing it and add something in the release
> note.

If no one else has a better alternative than that, then I suppose it is good 
enough. 

> 
> We may also want to introduce a new helper as discussed previously:
> 
> struct rte_mempool *
> rte_pktmbuf_pool_create(const char *name, unsigned n, unsigned elt_size,
>   unsigned cache_size, size_t mbuf_priv_size,
>   rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
>   int socket_id, unsigned flags)
> 
> Any comment?

Looks good to me.
Should we also introduce rte_pktmbuf_pool_xmem_create()? 
Konstantin

> 
> 
> >
> > Konstantin

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Butler, Siobhan A
> Sent: Wednesday, April 8, 2015 1:16 PM
> To: Neil Horman
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> 
> 
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Wednesday, April 8, 2015 12:44 PM
> > To: Butler, Siobhan A
> > Cc: Thomas Monjalon; dev at dpdk.org
> > Subject: Re: [dpdk-dev] tools brainstorming
> >
> > On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> > > Hi all,
> > > To add to the tools brainstorming - I propose we use the following
> > > Coding
> > Standards as the basis of guidelines on coding style going forward.
> > > The style outlined below is in alignment with the current convention
> > > used
> > for the majority of the project.
> > > Any thoughts/suggestions or feedback welcome.
> > > Thanks
> > > Siobhan :)
> > > 
> > >
> > >
> > >
> > > Coding Style
> > > ~~
> > >
> > > Description
> > > ---
> > >
> > > This document specifies the preferred style for source files in the
> > > DPDK
> > source tree.
> > > It is based on the Linux Kernel coding guidelines and the FreeBSD
> > > 7.2 Kernel Developer's Manual (see man style(9)), but was heavily
> > > modified for
> > the needs of the DPDK. Many of the style rules are implicit in the examples.
> > > Be careful to check the examples before assuming that style is
> > > silent on an
> > issue.
> > >
> > > General Guidelines
> > > --
> > >
> > > The rules and guidelines given in this document cannot cover every
> > situation, so the following general guidelines should be used as a fallback:
> > > The code style should be consistent within each individual file, and
> > > within each file in a given directory or module - in the case of
> > > creating new
> > files The primary reason for coding standards is to increase code
> > readability and comprehensibility, therefore always use whatever
> > option will make the code easiest to read.
> > >
> > > The following more specific recommendations apply to all sections,
> > > both for
> > C and assembly code:
> > > Line length is recommended to be not more than 80 characters,
> > > including comments. [Tab stop size should be assumed to be at least
> > > 4-
> > characters wide] Indentation should be to no more than 3 levels deep.
> > > NOTE The above are recommendations, and not hard limits. However, it
> > > is
> > expected that the recommendations should be followed in all but the
> > rarest situations.
> > > C Comment Style
> > >
> > > Usual Comments
> > > --
> > >
> > > These comments should be used in normal cases. To document a public
> > API, a doxygen-like format must be used: refer to Doxygen
> Documentation.
> > >  /*
> > >   * VERY important single-line comments look like this.
> > >   */
> > >
> > >  /* Most single-line comments look like this. */
> > >
> > >  /*
> > >   * Multi-line comments look like this.  Make them real sentences. Fill
> > >   * them so they look like real paragraphs.
> > >   */
> > >
> > > License Header
> > > --
> > >
> > > Each file should begin with a special comment tag which will contain
> > > the
> > appropriate copyright and license for the file (Generally BSD License).
> > > After any copyright header, a blank line should be left before any
> > > other
> > contents, e.g. include statements in a C file.
> > >
Apologies, my mistake the tag format is now out of date - and should be removed 
from the style guide.
Siobhan

> >
> > This can become very confusing.  There already is a LICENSE.GPL and
> > LICENSE.LGPL file at the top of the project, allowing others to insert
> > their own licenses within their files can make it difficult for end
> > user to determine if it is legally safe to use a given project.
> >
> > I'd suggest instead that contributions be disallowed from including
> > license files in their code, relying instead on only a single license
> > at the top of the project (which should likely be BSD or LGPL, since we're
> shipping a library).
> >
> > IANAL, but it seems to me to be dangerous to do anything else.  For
> > example, all the code that is dual licensed in the library (like
> > rte_pci_dev_ids.h).  It allows for a BSD or GPL license.  If someone
> > builds dpdk as a DSO and distributes it under the former, every
> > application that links against that re-distribution may arguably
> > itself become GPL licensed.  While I'm personally fine with that, I
> > can see it as being a big deal to some end users.  Unifying the
> > license makes the re-distribution license issue more clear for everyone.
> >
> > Neil
> 
> 
> Input appreciated Neil thank you, would it be best to include this in one of
> the community conference calls?
> IANAL either ( yet at least :) ) - we can certainly consult with someone who
> has the expertise.
> If others are interested in discussing this we can get added to the 

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Wednesday, April 8, 2015 12:44 PM
> To: Butler, Siobhan A
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> > Hi all,
> > To add to the tools brainstorming - I propose we use the following Coding
> Standards as the basis of guidelines on coding style going forward.
> > The style outlined below is in alignment with the current convention used
> for the majority of the project.
> > Any thoughts/suggestions or feedback welcome.
> > Thanks
> > Siobhan :)
> > 
> >
> >
> >
> > Coding Style
> > ~~
> >
> > Description
> > ---
> >
> > This document specifies the preferred style for source files in the DPDK
> source tree.
> > It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2
> > Kernel Developer's Manual (see man style(9)), but was heavily modified for
> the needs of the DPDK. Many of the style rules are implicit in the examples.
> > Be careful to check the examples before assuming that style is silent on an
> issue.
> >
> > General Guidelines
> > --
> >
> > The rules and guidelines given in this document cannot cover every
> situation, so the following general guidelines should be used as a fallback:
> > The code style should be consistent within each individual file, and
> > within each file in a given directory or module - in the case of creating 
> > new
> files The primary reason for coding standards is to increase code readability
> and comprehensibility, therefore always use whatever option will make the
> code easiest to read.
> >
> > The following more specific recommendations apply to all sections, both for
> C and assembly code:
> > Line length is recommended to be not more than 80 characters,
> > including comments. [Tab stop size should be assumed to be at least 4-
> characters wide] Indentation should be to no more than 3 levels deep.
> > NOTE The above are recommendations, and not hard limits. However, it is
> expected that the recommendations should be followed in all but the rarest
> situations.
> > C Comment Style
> >
> > Usual Comments
> > --
> >
> > These comments should be used in normal cases. To document a public
> API, a doxygen-like format must be used: refer to Doxygen Documentation.
> >  /*
> >   * VERY important single-line comments look like this.
> >   */
> >
> >  /* Most single-line comments look like this. */
> >
> >  /*
> >   * Multi-line comments look like this.  Make them real sentences. Fill
> >   * them so they look like real paragraphs.
> >   */
> >
> > License Header
> > --
> >
> > Each file should begin with a special comment tag which will contain the
> appropriate copyright and license for the file (Generally BSD License).
> > After any copyright header, a blank line should be left before any other
> contents, e.g. include statements in a C file.
> >
> 
> This can become very confusing.  There already is a LICENSE.GPL and
> LICENSE.LGPL file at the top of the project, allowing others to insert their
> own licenses within their files can make it difficult for end user to 
> determine
> if it is legally safe to use a given project.
> 
> I'd suggest instead that contributions be disallowed from including license
> files in their code, relying instead on only a single license at the top of 
> the
> project (which should likely be BSD or LGPL, since we're shipping a library).
> 
> IANAL, but it seems to me to be dangerous to do anything else.  For
> example, all the code that is dual licensed in the library (like
> rte_pci_dev_ids.h).  It allows for a BSD or GPL license.  If someone builds
> dpdk as a DSO and distributes it under the former, every application that 
> links
> against that re-distribution may arguably itself become GPL licensed.  While
> I'm personally fine with that, I can see it as being a big deal to some end
> users.  Unifying the license makes the re-distribution license issue more 
> clear
> for everyone.
> 
> Neil


Input appreciated Neil thank you, would it be best to include this in one of 
the community conference calls?
IANAL either ( yet at least :) ) - we can certainly consult with someone who 
has the expertise.
If others are interested in discussing this we can get added to the agenda for 
an upcoming call.

Is more detailed explanation/notice on the licensing structure required?
Thanks,
Siobhan 

[dpdk-dev] tools brainstorming

[Matthew Hall]

On Wed, Apr 08, 2015 at 11:16:03AM -0700, Stephen Hemminger wrote:
> I prefer the file just say that it is BSD or GPL and refer to license files 
> in the package. That way if something has to change it doesn't need a 
> massive license sweep

Hi guys,

I hope we're also enforcing some requirement that all user-space files that 
are expected to be used inside of the address space apps must be BSD, MIT, or 
other license which allows binary redistribution, as part of these standards. 
Or we could end up causing a lot of pain for the app developers if somebody 
puts a bunch of GPL files into the user-space code which blocks their usage.

For the Linux kernel side files, we probably need to say BSD, MIT, or GPLv2 
specifically, and not GPLv3, I think that's what Linus is using, or it could 
be a problem to upstream any of those as DPDK usage grows.

For the BSD kernel side files, if any, probably need to be sure we're 
compatible with at least FreeBSD and NetBSD, and probably also OpenBSD.

Matthew.

[dpdk-dev] [PATCH v3 1/5] mbuf: fix clone support when application uses private mbuf data

[Olivier MATZ]

Hi Konstantin,

On 04/07/2015 07:17 PM, Ananyev, Konstantin wrote:
>> Just to be sure we're on the same line:
>>
>> - before the patch series
>>
>> - private area was working before that patch series if clones were not
>>   used. To use a private are, the user had to provide another
>>   function derived from pktmbuf_init() to change m->buf_addr and
>>   m->buf_len.
>> - using both private area + clones was broken
>>
>> - after the patch series
>>
>> - private area is working with or without clone. But yo use it,
>>   the user still has to provide another function to change
>>   m->buf_addr, m->buf_len *and m->priv_size*.
>>
>> The series just fixes the fact that "clones + priv" was not working.
>> It does not address the problem that providing a new pktmbuf_init()
>> function is required to use privata area. To fix this, I think it
>> could require a API evolution that should be part of another series.
>
> I don't think we need new pktmbuf_init().
> We just need to update it, so both pktmbuf_init() and detach() setup
> buf_addr, buf_len (and priv_size) to exactly the same values.
> If they don't do that, it means that you can't use attach/detach with
> mempools created with pktmbuf_init() any more.
>
> BTW, another thing that I just realised:
> examples/ipv4_multicast and examples/ip_fragmentation/ -
> both create a pool of mbufs with elem_size < 2K and don't populate mempool's 
> private area -
> so mbp_priv->mbuf_data_room_size == 0, for them.
>
> So that code in detach():
>
>   +   mbp_priv = rte_mempool_get_priv(mp);
>   +   m->priv_size = mp->elt_size - RTE_PKTMBUF_HEADROOM -
>   +   mbp_priv->mbuf_data_room_size -
>   +   sizeof(struct rte_mbuf);
>
>
> Would break both these samples.
> I suppose we need to handle situation when mp->elt_size < 
> RTE_PKTMBUF_HEADROOM + sizeof(struct rte_mbuf),
> (and probably also when mbuf_data_room_size == 0) correctly.

Indeed. I think a mbuf pool (even with buf_len == 0 like in
ip_fragmentation example) should have a pool with a private area and
should call rte_pktmbuf_pool_init() to populate it. So
rte_pktmbuf_pool_init() has to be fixed first to use elt_size
and support the buf_len < RTE_PKTMBUF_HEADROOM, then we can
update frag/multicast examples.

Unfortunately, we don't know the size of the mbuf private area
in rte_pktmbuf_pool_init() if the opaque arg (data_room_size)
is 0, which is the default. I think it should be replaced by a structure
containing data_room_size and mbuf_priv_size, but it would break
applications that are setting data_room_size. I don't see any good
solution to do that while keeping a backward compatibility for
rte_pktmbuf_pool_init(), but as the current API is not ideal,
I think it's worth changing it and add something in the release
note.

We may also want to introduce a new helper as discussed previously:

struct rte_mempool *
rte_pktmbuf_pool_create(const char *name, unsigned n, unsigned elt_size,
unsigned cache_size, size_t mbuf_priv_size,
rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
int socket_id, unsigned flags)

Any comment?


>
> Konstantin

[dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options

[Stephen Hemminger]

On Wed,  8 Apr 2015 16:07:21 +0100
Sergio Gonzalez Monroy  wrote:

> Currently, the target/rules to build combined libraries is different
> than the one to build individual libraries.
> 
> By removing the combined library option as a build configuration option
> we simplify the build pocess by having a single point for linking/archiving
> libraries in DPDK.
> 
> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> removes the makefiles associated with building a combined library.
> 
> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> always generate a linker script that acts as a single combined library.
> 
> Signed-off-by: Sergio Gonzalez Monroy 

No. We use combined library and it greatly simplfies the application
linking process.

[dpdk-dev] tools brainstorming

[Stephen Hemminger]

Thanks for doing this, it is a great start.
I admit strong bias towards Linux kernel style.

Could you use one of the standard markup styles so that it could get put in 
documentation?


> License Header
> --

I prefer the file just say that it is BSD or GPL and refer to license files in 
the
package. That way if something has to change it doesn't need a massive license 
sweep


> 
> Macros
> 
> Do not ``#define`` or declare names in the implementation namespace except 
> for implementing application interfaces. 
> 
> The names of ``unsafe`` macros (ones that have side effects), and the names 
> of macros for manifest constants, are all in uppercase. 
> 
> The expansions of expression-like macros are either a single token or have 
> outer parentheses. If a macro is an inline expansion of a function, 
> the function name is all in lowercase and the macro has the same name all in 
> uppercase. Right-justify the backslashes; 
> it makes it easier to read. If the macro encapsulates a compound statement, 
> enclose it in a do loop, so that it can be used safely in if statements. 
> Any final statement-terminating semicolon should be supplied by the macro 
> invocation rather than the macro, to make parsing easier for pretty-printers 
> and editors. 
>  #define MACRO(x, y) do {\
>  variable = (x) + (y);   \
>  (y) += 2;   \
>  }while (0)
^ bad whitespace

it is important that all examples in documentation are perfect.


> C Function Definition, Declaration and Use
> 
> Prototypes
> 
> It is recommended, but not required that all functions are prototyped 
> somewhere. 
> 
> Any function prototypes for private functions (that is, functions not used 
> elsewhere) go at the top of the first source module. Functions 
> local to one source module should be declared static. 

I find prototypes for private functions to be redundant and error prone.
The do nothing. Better to just put private functions in the correct order.


You also need to raise the issue that all global names need to be prefaced by a 
unique string.
I see places in drivers where global names leak out causing possible later name 
collision.

> Definitions
> ---
> 
> The function type should be on a line by itself preceding the function. The 
> opening brace of the function body should be on a line by itself. 
>  static char *
>  function(int a1, int a2, float fl, int a4)
>  {

Not a big fan of that style. Prefer it on same line.


> 
> Indentation is a hard tab, that is, a tab character, not a sequence of 
> spaces. 

Also no spaces before tabs.

> NOTE General rule in DPDK, use tabs for indentation, spaces for alignment. 
> If you have to wrap a long statement, put the operator at the end of the 
> line, and indent again. For control statements (if, while, etc.), 
> it is recommended that the next line be indented by two tabs, rather than 
> one, to prevent confusion as to whether the second line of the 
> control statement forms part of the statement body or not. For non-control 
> statements, this issue does not apply, so they can be indented 
> by a single tab. However, a two-tab indent is recommended in this case also 
> to keep consistency across all statement types. 
>  while (really_long_variable_name_1 == really_long_variable_name_2 &&
>  var3 == var4){
>  x = y + z;  /* control stmt body lines up with second line of */
>  a = b + c;  /* control statement itself if single indent used */
>  }
>  
>  if (really_long_variable_name_1 == really_long_variable_name_2 &&
>  var3 == var4){  /* two tabs used */

No. Should line up with really_long_variable_name_1

>  x = y + z;  /* statement body no longer lines up */
>  a = b + c;
>  }
>  
>  z = a + really + long + statement + that + needs +
>  two + lines + gets + indented + on + the + 
>  second + and + subsequent + lines;
> 
> 
> Do not add whitespace at the end of a line. 
> 
> Closing and opening braces go on the same line as the else keyword. Braces 
> that are not necessary should be left out. 
>  if (test)
>  stmt;
>  else if (bar) {
>  stmt;
>  stmt;
>  } else
>  stmt;
> 
> 
> Function Calls
> --
> 
> Do not use spaces after function names. Commas should have a space after 
> them. No spaces after ``(`` or ``[`` or preceding the ``]`` or ``)`` 
> characters. 
>  error = function(a1, a2);
>  if (error != 0)
>  exit(error);
> 
> 
> Operators
> -
> 
> Unary operators do not require spaces, binary operators do. Do not use 
> parentheses unless they are required for precedence or unless the 
> statement is confusing without them. Remember that other people may be more 
> easily confused than you. 
> 
> Exit
> 
> Exits should be 0 on success, or 1 on failure. 
>  exit(0);/*
>   * Avoid 

[dpdk-dev] [RFC PATCH] librte_pmd_ixgbe: changes to support PCI Port Hotplug

[Bernard Iremonger]

This patch depends on the Port Hotplug Framework.
It implements the eth_dev_uninit functions for rte_ixgbe_pmd and
rte_ixgbevf_pmd.pmd.

Signed-off-by: Bernard Iremonger 
---
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c |   87 +-
 lib/librte_pmd_ixgbe/ixgbe_ethdev.h |4 +-
 lib/librte_pmd_ixgbe/ixgbe_pf.c |   30 -
 3 files changed, 116 insertions(+), 5 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index 5caee22..464398a 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -117,6 +117,7 @@
 #define IXGBE_QUEUE_STAT_COUNTERS (sizeof(hw_stats->qprc) / 
sizeof(hw_stats->qprc[0]))

 static int eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev);
+static int eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev);
 static int  ixgbe_dev_configure(struct rte_eth_dev *dev);
 static int  ixgbe_dev_start(struct rte_eth_dev *dev);
 static void ixgbe_dev_stop(struct rte_eth_dev *dev);
@@ -183,6 +184,7 @@ static void ixgbe_dcb_init(struct ixgbe_hw *hw,struct 
ixgbe_dcb_config *dcb_conf

 /* For Virtual Function support */
 static int eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev);
+static int eth_ixgbevf_dev_uninit(struct rte_eth_dev *eth_dev);
 static int  ixgbevf_dev_configure(struct rte_eth_dev *dev);
 static int  ixgbevf_dev_start(struct rte_eth_dev *dev);
 static void ixgbevf_dev_stop(struct rte_eth_dev *dev);
@@ -917,6 +919,49 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
return 0;
 }

+static int
+eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev)
+{
+   struct rte_pci_device *pci_dev;
+   struct ixgbe_hw *hw;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if ((eth_dev == NULL) ||
+   (eth_dev->data == NULL) ||
+   (eth_dev->data->dev_private == NULL) ||
+   (eth_dev->pci_dev == NULL))
+   return -EINVAL;
+
+   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+   return -EPERM;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+   pci_dev = eth_dev->pci_dev;
+
+   eth_dev->dev_ops = NULL;
+   eth_dev->rx_pkt_burst = NULL;
+   eth_dev->tx_pkt_burst = NULL;
+
+   /* Unlock any pending hardware semaphore */
+   ixgbe_swfw_lock_reset(hw);
+
+   /* disable uio intr before callback unregister */
+   rte_intr_disable(&(pci_dev->intr_handle));
+   rte_intr_callback_unregister(&(pci_dev->intr_handle),
+   ixgbe_dev_interrupt_handler, (void *)eth_dev);
+
+   /* uninitialize PF if max_vfs not zero */
+   ixgbe_pf_host_uninit(eth_dev);
+
+   rte_free(eth_dev->data->mac_addrs);
+   eth_dev->data->mac_addrs = NULL;
+
+   rte_free(eth_dev->data->hash_mac_addrs);
+   eth_dev->data->hash_mac_addrs = NULL;
+
+   return 0;
+}

 /*
  * Negotiate mailbox API version with the PF.
@@ -1087,13 +1132,48 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)
return 0;
 }

+/*
+ * Virtual Function device uninit
+ */
+static int
+eth_ixgbevf_dev_uninit(struct rte_eth_dev *eth_dev)
+{
+   struct ixgbe_hw *hw;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if ((eth_dev == NULL) ||
+   (eth_dev->data == NULL) ||
+   (eth_dev->data->dev_private == NULL))
+   return -EINVAL;
+
+   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+   return -EPERM;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+   eth_dev->dev_ops = NULL;
+   eth_dev->rx_pkt_burst = NULL;
+   eth_dev->tx_pkt_burst = NULL;
+
+   /* Disable the interrupts for VF */
+   ixgbevf_intr_disable(hw);
+
+   rte_free(eth_dev->data->mac_addrs);
+   eth_dev->data->mac_addrs = NULL;
+
+   return 0;
+}
+
 static struct eth_driver rte_ixgbe_pmd = {
{
.name = "rte_ixgbe_pmd",
.id_table = pci_id_ixgbe_map,
-   .drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
+   .drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC |
+   RTE_PCI_DRV_DETACHABLE,
},
.eth_dev_init = eth_ixgbe_dev_init,
+   .eth_dev_uninit = eth_ixgbe_dev_uninit,
.dev_private_size = sizeof(struct ixgbe_adapter),
 };

@@ -1104,9 +1184,10 @@ static struct eth_driver rte_ixgbevf_pmd = {
{
.name = "rte_ixgbevf_pmd",
.id_table = pci_id_ixgbevf_map,
-   .drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+   .drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_DETACHABLE,
},
.eth_dev_init = eth_ixgbevf_dev_init,
+   .eth_dev_uninit = 

[dpdk-dev] Polling too often at lower packet rates?

[Stephen Hemminger]

We use adaptive polling loop similar to l3fwd-power example.
See:


http://video.fosdem.org/2015/devroom-network_management_and_sdn/

On Wed, Apr 8, 2015 at 9:35 AM, Aaron Campbell  wrote:

> Hi,
>
> I have a machine with 6 DPDK ports (4 igb, 2 ixgbe), with 1.23Mpps traffic
> offered to only one of the 10G ports (the other 5 are unused).  I also have
> a program with a pretty standard looking DPDK receive loop, where it calls
> rte_eth_rx_burst() for each configured port.  If I configure the loop to
> read from all 6 ports, it can read the 1.23Mpps rate with no drops.  If I
> configure the loop to poll only 1 port (the ixgbe receiving the traffic), I
> lose about 1/3rd of the packets (i.e., the NIC drops ~400Kpps).
>
> Another data point is that if I configure the loop to read from 3 out of
> the 6 ports, the drop rate is reduced to less than half (i.e., the NIC is
> only dropping ~190Kpps now).  So it seems that in this test, throughput
> improves by adding NICs, not removing them, which is counter-intuitive.
> Again, I get no drops when polling all 6 ports.  Note, the burst size is 32.
>
> I did find a reference to a similar issue in a recent paper (
> http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/ICN2015.pdf),
> Section III, which states:
>
> "The DPDK L2FWD application initially only managed to forward 13.8 Mpps in
> the single direction test at the maximum CPU frequency, a similar result
> can be found in [11]. Reducing the CPU frequency increased the throughput
> to the expected value of 14.88 Mpps. Our investigation of this anomaly
> revealed that the lack of any processing combined with the fast CPU caused
> DPDK to poll the NIC too often. DPDK does not use interrupts, it utilizes a
> busy wait loop that polls the NIC until at least one packet is returned.
> This resulted in a high poll rate which affected the throughput. We limited
> the poll rate to 500,000 poll operations per second (i.e., a batch size of
> about 30 packets) and achieved line rate in the unidirectional test with
> all frequencies. This effect was only observed with the X520 NIC, tests
> with X540 NICs did not show this anomaly.?
>
> Another reference, from this mailing list last year (
> http://wiki.dpdk.org/ml/archives/dev/2014-January/001169.html):
>
> "I suggest you to check average burst sizes on receive queues. Looks like
> I stumbled upon a similar issue several times. If you are calling
> rte_eth_rx_burst too frequently, NIC begins losing packets no matter how
> many CPU horse power you have (more you have, more it loses, actually). In
> my case this situation occured when average burst size is less than 20
> packets or so. I'm not sure what's the reason for this behavior, but I
> observed it on several applications on Intel 82599 10Gb cards.?
>
> So I?m wondering if anyone can explain at a lower level what happens when
> you poll ?too often?, and if there are any practical workarounds.  We?re
> using this same program and DPDK version to process 10G line-rate in other
> scenarios, so I?m confident that the overall packet capture architecture is
> sound.
>
> -Aaron

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

Hi all,
To add to the tools brainstorming - I propose we use the following Coding 
Standards as the basis of guidelines on coding style going forward.
The style outlined below is in alignment with the current convention used for 
the majority of the project.
Any thoughts/suggestions or feedback welcome.
Thanks
Siobhan :)




Coding Style
~~

Description
---

This document specifies the preferred style for source files in the DPDK source 
tree. 
It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2 Kernel 
Developer's Manual (see man style(9)), 
but was heavily modified for the needs of the DPDK. Many of the style rules are 
implicit in the examples. 
Be careful to check the examples before assuming that style is silent on an 
issue. 

General Guidelines
--

The rules and guidelines given in this document cannot cover every situation, 
so the following general guidelines should be used as a fallback: 
The code style should be consistent within each individual file, and within 
each file in a given directory or module - in the case of creating new files 
The primary reason for coding standards is to increase code readability and 
comprehensibility, therefore always use whatever option will make the code 
easiest to read. 

The following more specific recommendations apply to all sections, both for C 
and assembly code: 
Line length is recommended to be not more than 80 characters, including 
comments. [Tab stop size should be assumed to be at least 4-characters wide] 
Indentation should be to no more than 3 levels deep. 
NOTE The above are recommendations, and not hard limits. However, it is 
expected that the recommendations should be followed in all but the rarest 
situations. 
C Comment Style

Usual Comments
--

These comments should be used in normal cases. To document a public API, a 
doxygen-like format must be used: refer to Doxygen Documentation. 
 /*
  * VERY important single-line comments look like this.
  */

 /* Most single-line comments look like this. */

 /*
  * Multi-line comments look like this.  Make them real sentences. Fill
  * them so they look like real paragraphs.
  */

License Header
--

Each file should begin with a special comment tag which will contain the 
appropriate copyright and license for the file (Generally BSD License). 
After any copyright header, a blank line should be left before any other 
contents, e.g. include statements in a C file. 

C Preprocessor Directives
-

Header Includes

In DPDK sources, the include files should be ordered as following: 
 libc includes (system includes first) 
 DPDK EAL includes 
 DPDK misc libraries includes 
 application-specific includes 

Example: 
 #include 
 #include 

 #include 

 #include 
 #include 

 #include "application.h"


Global pathnames are defined in . Pathnames local to the program go in 
"pathnames.h" in the local directory. 
 #include 


Leave another blank line before the user include files. 
 #include "pathnames.h" /* Local includes in double quotes. */

NOTE Please avoid, as much as possible, including headers from other headers 
file. Doing so should be properly explained and justified. 
Headers should be protected against multiple inclusion with the usual: 
 #ifndef _FILE_H_
 #define _FILE_H_

 /* Code */

 #endif /* _FILE_H_ */


Macros

Do not ``#define`` or declare names in the implementation namespace except for 
implementing application interfaces. 

The names of ``unsafe`` macros (ones that have side effects), and the names of 
macros for manifest constants, are all in uppercase. 

The expansions of expression-like macros are either a single token or have 
outer parentheses. If a macro is an inline expansion of a function, 
the function name is all in lowercase and the macro has the same name all in 
uppercase. Right-justify the backslashes; 
it makes it easier to read. If the macro encapsulates a compound statement, 
enclose it in a do loop, so that it can be used safely in if statements. 
Any final statement-terminating semicolon should be supplied by the macro 
invocation rather than the macro, to make parsing easier for pretty-printers 
and editors. 
 #define MACRO(x, y) do {\
 variable = (x) + (y);   \
 (y) += 2;   \
 }while (0)

NOTE Wherever possible, enums and typedefs should be preferred to macros, since 
they provide additional degrees 
of type-safety and can allow compilers to emit extra warnings about unsafe 
code. 

Conditional Compilation
---

When code is conditionally compiled using #ifdef or #if, a comment may be added 
following the matching #endif or #else to 
permit the reader to easily discern where conditionally compiled code regions 
end. This comment should be used only for 
(subjectively) long regions, regions greater than 20 lines, 

[dpdk-dev] [PATCH 2/2] tools: fix comment in bind script

[Stephen Hemminger]

From: Stephen Hemminger 

The function documentation was obviously copied and not updated.

Signed-off-by: Stephen Hemminger 
---
 tools/dpdk_nic_bind.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
index 8523f82..b7bd877 100755
--- a/tools/dpdk_nic_bind.py
+++ b/tools/dpdk_nic_bind.py
@@ -391,7 +391,7 @@ def unbind_all(dev_list, force=False):
 unbind_one(d, force)

 def bind_all(dev_list, driver, force=False):
-"""Unbind method, takes a list of device locations"""
+"""Bind method, takes a list of device locations"""
 global devices

 dev_list = map(dev_id_from_dev_name, dev_list)
-- 
2.1.4

[dpdk-dev] [PATCH 1/2] enic: silence log message

[Stephen Hemminger]

From: Stephen Hemminger 

Silence is normal. drivers should speak only when spoken to and not
be chatty.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_pmd_enic/enic_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/librte_pmd_enic/enic_main.c b/lib/librte_pmd_enic/enic_main.c
index 0892b3e..508621e 100644
--- a/lib/librte_pmd_enic/enic_main.c
+++ b/lib/librte_pmd_enic/enic_main.c
@@ -1048,8 +1048,6 @@ int enic_probe(struct enic *enic)
struct rte_pci_device *pdev = enic->pdev;
int err = -1;

-   dev_debug(enic, " Initializing ENIC PMD version %s\n", DRV_VERSION);
-
enic->bar0.vaddr = (void *)pdev->mem_resource[0].addr;
enic->bar0.len = pdev->mem_resource[0].len;

-- 
2.1.4

[dpdk-dev] [PATCH 0/2] small changes

[Stephen Hemminger]

These are trivial patches found by review

Stephen Hemminger (2):
  enic: silence log message
  tools: fix comment in bind script

 lib/librte_pmd_enic/enic_main.c | 2 --
 tools/dpdk_nic_bind.py  | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

-- 
2.1.4

[dpdk-dev] tools brainstorming

[Neil Horman]

On Wed, Apr 08, 2015 at 12:16:10PM +, Butler, Siobhan A wrote:
> 
> 
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Wednesday, April 8, 2015 12:44 PM
> > To: Butler, Siobhan A
> > Cc: Thomas Monjalon; dev at dpdk.org
> > Subject: Re: [dpdk-dev] tools brainstorming
> > 
> > On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> > > Hi all,
> > > To add to the tools brainstorming - I propose we use the following Coding
> > Standards as the basis of guidelines on coding style going forward.
> > > The style outlined below is in alignment with the current convention used
> > for the majority of the project.
> > > Any thoughts/suggestions or feedback welcome.
> > > Thanks
> > > Siobhan :)
> > > 
> > >
> > >
> > >
> > > Coding Style
> > > ~~
> > >
> > > Description
> > > ---
> > >
> > > This document specifies the preferred style for source files in the DPDK
> > source tree.
> > > It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2
> > > Kernel Developer's Manual (see man style(9)), but was heavily modified for
> > the needs of the DPDK. Many of the style rules are implicit in the examples.
> > > Be careful to check the examples before assuming that style is silent on 
> > > an
> > issue.
> > >
> > > General Guidelines
> > > --
> > >
> > > The rules and guidelines given in this document cannot cover every
> > situation, so the following general guidelines should be used as a fallback:
> > > The code style should be consistent within each individual file, and
> > > within each file in a given directory or module - in the case of creating 
> > > new
> > files The primary reason for coding standards is to increase code 
> > readability
> > and comprehensibility, therefore always use whatever option will make the
> > code easiest to read.
> > >
> > > The following more specific recommendations apply to all sections, both 
> > > for
> > C and assembly code:
> > > Line length is recommended to be not more than 80 characters,
> > > including comments. [Tab stop size should be assumed to be at least 4-
> > characters wide] Indentation should be to no more than 3 levels deep.
> > > NOTE The above are recommendations, and not hard limits. However, it is
> > expected that the recommendations should be followed in all but the rarest
> > situations.
> > > C Comment Style
> > >
> > > Usual Comments
> > > --
> > >
> > > These comments should be used in normal cases. To document a public
> > API, a doxygen-like format must be used: refer to Doxygen Documentation.
> > >  /*
> > >   * VERY important single-line comments look like this.
> > >   */
> > >
> > >  /* Most single-line comments look like this. */
> > >
> > >  /*
> > >   * Multi-line comments look like this.  Make them real sentences. Fill
> > >   * them so they look like real paragraphs.
> > >   */
> > >
> > > License Header
> > > --
> > >
> > > Each file should begin with a special comment tag which will contain the
> > appropriate copyright and license for the file (Generally BSD License).
> > > After any copyright header, a blank line should be left before any other
> > contents, e.g. include statements in a C file.
> > >
> > 
> > This can become very confusing.  There already is a LICENSE.GPL and
> > LICENSE.LGPL file at the top of the project, allowing others to insert their
> > own licenses within their files can make it difficult for end user to 
> > determine
> > if it is legally safe to use a given project.
> > 
> > I'd suggest instead that contributions be disallowed from including license
> > files in their code, relying instead on only a single license at the top of 
> > the
> > project (which should likely be BSD or LGPL, since we're shipping a 
> > library).
> > 
> > IANAL, but it seems to me to be dangerous to do anything else.  For
> > example, all the code that is dual licensed in the library (like
> > rte_pci_dev_ids.h).  It allows for a BSD or GPL license.  If someone builds
> > dpdk as a DSO and distributes it under the former, every application that 
> > links
> > against that re-distribution may arguably itself become GPL licensed.  While
> > I'm personally fine with that, I can see it as being a big deal to some end
> > users.  Unifying the license makes the re-distribution license issue more 
> > clear
> > for everyone.
> > 
> > Neil
> 
> 
> Input appreciated Neil thank you, would it be best to include this in one of 
> the community conference calls?
> IANAL either ( yet at least :) ) - we can certainly consult with someone who 
> has the expertise.
> If others are interested in discussing this we can get added to the agenda 
> for an upcoming call.
> 
> Is more detailed explanation/notice on the licensing structure required?
> Thanks,
> Siobhan 
> 
If you want to discuss it on the community call I think that would be fine,
certainly, but it seems that on this forum is the real place to encourage

[dpdk-dev] Running DPDK Binaries on a different Target

[Neil Horman]

On Wed, Apr 08, 2015 at 02:03:05PM +0530, Venkat Thummala wrote:
> Hi Neil,
> 
> Thanks for the quick response.
> 
> The issue got fixed by setting CONFIG_RTE_MACHINE to "default".
> 
Default is the lowest common demoninator system that dpdk supports (core2 duo).
So if you're system is superior to that processor, you're ok.

> Though, this fixed the CRASH issue, I am observing inconsistent behavior
> with ACL tables.
> 
> With the same traffic and same ACL rule, on ONE machine the ACL rule is
> being HIT, where as on the OTHER machine the rule never HITS.
> 
> Is this because of the "default" machine option?
> 
Possibly, the machine type changes the method of lookup for ACL rules, though it
should remain consistent in terms of which rules are hit.  
> Regards
> Venkat
> 
> 
> On 7 April 2015 at 20:05, Neil Horman  wrote:
> 
> > On Tue, Apr 07, 2015 at 05:30:15PM +0530, Venkat Thummala wrote:
> > > Attaching the CPU Info.
> > >
> > > On 7 April 2015 at 17:28, Venkat Thummala <
> > venkat.thummala.1978 at gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I have built a DPDK application [based on version 2.0] and run on the
> > > > native machine successfully.
> > > >
> > > > I have tried running the binary on a different machine, but it
> > resulted in
> > > > a CRASH with the following back trace.
> > > >
> > > > Please find the CPU info of the machines from the attachment.
> > > >
> > > > cpuinfo-1 - Native Machine
> > > > cpuinfo-2 - Non Native Machine
> > > >
> > > > Could someone please help me in understanding the issue here and
> > making it
> > > > work?
> > > >
> > > > Regards
> > > > Venkat
> > > >
> > > > Program terminated with signal SIGILL, Illegal instruction.
> > > > #0  0x004209f2 in rte_cpu_get_flag_enabled (feature=2147483656,
> > > > feature at entry=RTE_CPUFLAG_EM64T)
> > > > at
> > > >
> > /home/vthummala/src/vwlc/dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_cpuflags.h:303
> > > > 303return (regs[feat->reg] >> feat->bit) & 1;
> >
> > Looks like this somehow compiled into an instruction that the native system
> > understands but the system you're running on doesn't.  disassemble the
> > code here
> > to see what instruction that is to confirm, then you either need to:
> >
> > 1) Change the machine you're compiling for to be more specific to your
> > target
> > system
> >
> > or
> >
> > 2) Understand that the hardware you're targeting doesn't support dpdk
> >
> > Neil
> >
> > > > (gdb) bt
> > > > #0  0x004209f2 in rte_cpu_get_flag_enabled (feature=2147483656,
> > > > feature at entry=RTE_CPUFLAG_EM64T)
> > > > at
> > > >
> > /home/vthummala/src/vwlc/dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_cpuflags.h:303
> > > > #1  0x00420a1b in rte_hash_crc_set_alg (alg=6 '\006')
> > > > at
> > > >
> > /home/vthummala/src/vwlc/dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:429
> > > > #2  rte_hash_crc_init_alg () at
> > > >
> > /home/vthummala/src/vwlc/dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:445
> > > > #3  0x0054968d in __libc_csu_init ()
> > > > #4  0x7fc3ca474e55 in group_nodes_into_DFAstates
> > > > (dests_ch=0x940f507ab10ff0c8, dests_node=0x4a8b44de74c084c0,
> > > > state=0x4420528b48a8ebc9,
> > > > dfa=) at regexec.c:3614
> > > > #5  build_trtable (dfa=0x840fc139c0014468, state=0x4420528b48a8ebc9) at
> > > > regexec.c:3354
> > > > #6  0x41d589495541f689 in ?? ()
> > > > #7  0x00251630258d4c54 in ?? ()
> > > > #8  0x002517302d8d4855 in ?? ()
> > > > #9  0xc148db31e5294c53 in ?? ()
> > > > #10 0x65e808ec834803fd in ?? ()
> > > > #11 0x1e74ed8548ffed48 in ?? ()
> > > > #12 0x00841f0f in ?? ()
> > > >
> > >
> >

[dpdk-dev] tools brainstorming

[Neil Horman]

On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> Hi all,
> To add to the tools brainstorming - I propose we use the following Coding 
> Standards as the basis of guidelines on coding style going forward.
> The style outlined below is in alignment with the current convention used for 
> the majority of the project.
> Any thoughts/suggestions or feedback welcome.
> Thanks
> Siobhan :)
> 
> 
> 
> 
> Coding Style
> ~~
> 
> Description
> ---
> 
> This document specifies the preferred style for source files in the DPDK 
> source tree. 
> It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2 Kernel 
> Developer's Manual (see man style(9)), 
> but was heavily modified for the needs of the DPDK. Many of the style rules 
> are implicit in the examples. 
> Be careful to check the examples before assuming that style is silent on an 
> issue. 
> 
> General Guidelines
> --
> 
> The rules and guidelines given in this document cannot cover every situation, 
> so the following general guidelines should be used as a fallback: 
> The code style should be consistent within each individual file, and within 
> each file in a given directory or module - in the case of creating new files 
> The primary reason for coding standards is to increase code readability and 
> comprehensibility, therefore always use whatever option will make the code 
> easiest to read. 
> 
> The following more specific recommendations apply to all sections, both for C 
> and assembly code: 
> Line length is recommended to be not more than 80 characters, including 
> comments. [Tab stop size should be assumed to be at least 4-characters wide] 
> Indentation should be to no more than 3 levels deep. 
> NOTE The above are recommendations, and not hard limits. However, it is 
> expected that the recommendations should be followed in all but the rarest 
> situations. 
> C Comment Style
> 
> Usual Comments
> --
> 
> These comments should be used in normal cases. To document a public API, a 
> doxygen-like format must be used: refer to Doxygen Documentation. 
>  /*
>   * VERY important single-line comments look like this.
>   */
>  
>  /* Most single-line comments look like this. */
>  
>  /*
>   * Multi-line comments look like this.  Make them real sentences. Fill
>   * them so they look like real paragraphs.
>   */
> 
> License Header
> --
> 
> Each file should begin with a special comment tag which will contain the 
> appropriate copyright and license for the file (Generally BSD License). 
> After any copyright header, a blank line should be left before any other 
> contents, e.g. include statements in a C file. 
> 

This can become very confusing.  There already is a LICENSE.GPL and LICENSE.LGPL
file at the top of the project, allowing others to insert their own licenses
within their files can make it difficult for end user to determine if it is
legally safe to use a given project.

I'd suggest instead that contributions be disallowed from including license
files in their code, relying instead on only a single license at the top of the
project (which should likely be BSD or LGPL, since we're shipping a library).

IANAL, but it seems to me to be dangerous to do anything else.  For example, all
the code that is dual licensed in the library (like rte_pci_dev_ids.h).  It
allows for a BSD or GPL license.  If someone builds dpdk as a DSO and
distributes it under the former, every application that links against that
re-distribution may arguably itself become GPL licensed.  While I'm personally
fine with that, I can see it as being a big deal to some end users.  Unifying
the license makes the re-distribution license issue more clear for everyone.

Neil

[dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua?

[Luke Gorrie]

On 7 April 2015 at 17:30, Michael S. Tsirkin  wrote:

> Just guessing from the available info:
>
> I think you refer to this:
> The driver MUST handle spurious interrupts from the device.
>
> The intent is to be able to handle some spurious interrupts once in a
> while.  AFAIK linux triggers the message if it gets a huge number of
> spurious interrupts for an extended period of time.
> For example, this will trigger if the device does not clear interrupt
> line after interrupt register read.
>

Thanks for that info.

The only spurious interrupt that I think we need is one when vhost-user
reconnects. That would be to cover the case where the vswitch is restarted
after writing used->idx but before sending the interrupt.

Or perhaps there is a better solution to that case?

Looking forward to getting an upstream vhost-user reconnect. one thing at a
time.. :)

Cheers,
-Luke

[dpdk-dev] [PATCH] enic: disable debug traces

[Sujith Sankar (ssujith)]

On 07/04/15 11:10 pm, "Thomas Monjalon"  wrote:

>The function name is printed in each enic_ethdev function.
>Disable it by default with a new build option.
>
>Signed-off-by: Thomas Monjalon 
>---
> config/common_bsdapp  | 1 +
> config/common_linuxapp| 1 +
> lib/librte_pmd_enic/enic_ethdev.c | 4 
> 3 files changed, 6 insertions(+)
>
>diff --git a/config/common_bsdapp b/config/common_bsdapp
>index a8ba484..c2374c0 100644
>--- a/config/common_bsdapp
>+++ b/config/common_bsdapp
>@@ -214,6 +214,7 @@ CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
> # Compile burst-oriented Cisco ENIC PMD driver
> #
> CONFIG_RTE_LIBRTE_ENIC_PMD=y
>+CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
> 
> #
> # Compile burst-oriented VIRTIO PMD driver
>diff --git a/config/common_linuxapp b/config/common_linuxapp
>index 0b25f34..0078dc9 100644
>--- a/config/common_linuxapp
>+++ b/config/common_linuxapp
>@@ -211,6 +211,7 @@ CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
> # Compile burst-oriented Cisco ENIC PMD driver
> #
> CONFIG_RTE_LIBRTE_ENIC_PMD=y
>+CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
> 
> #
> # Compile burst-oriented VIRTIO PMD driver
>diff --git a/lib/librte_pmd_enic/enic_ethdev.c
>b/lib/librte_pmd_enic/enic_ethdev.c
>index 4950ede..18fadfb 100644
>--- a/lib/librte_pmd_enic/enic_ethdev.c
>+++ b/lib/librte_pmd_enic/enic_ethdev.c
>@@ -48,8 +48,12 @@
> #include "vnic_enet.h"
> #include "enic.h"
> 
>+#ifdef RTE_LIBRTE_ENIC_DEBUG
> #define ENICPMD_FUNC_TRACE() \
>   RTE_LOG(DEBUG, PMD, "ENICPMD trace: %s\n", __func__)
>+#else
>+#define ENICPMD_FUNC_TRACE() do {} while (0)
>+#endif
> 
> /*
>  * The set of PCI devices this driver supports
>-- 
>2.2.2
>
Acked-by: Sujith Sankar 
>

[dpdk-dev] [PATCH v2] Restore support for virtio on FreeBSD

[Raz Amir]

Fixes: 8a312224bcde ("eal/bsd: fix fd leak")

Signed-off-by: Raz Amir 
---
 lib/librte_eal/bsdapp/eal/eal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 871d5f4..e20f915 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -426,7 +426,7 @@ rte_eal_iopl_init(void)
fd = open("/dev/io", O_RDWR);
if (fd < 0)
return -1;
-   close(fd);
+   /* keep fd open for iopl */
return 0;
 }

-- 
2.1.2

[dpdk-dev] [PATCH] Restore support for virtio on FreeBSD

[Raz Amir]

Signed-off-by: Raz Amir 
---
 lib/librte_eal/bsdapp/eal/eal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 871d5f4..e20f915 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -426,7 +426,7 @@ rte_eal_iopl_init(void)
fd = open("/dev/io", O_RDWR);
if (fd < 0)
return -1;
-   close(fd);
+   /* keep fd open for iopl */
return 0;
 }

-- 
2.1.2