[dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

[Jose Gavine Cueto]

Hi,

I'm writing a very simple packet dump application that can be described by
the following diagram:

 ---
|pktdump|
 
| PMD lib extension |
| (extlib)  |
 
| DPDK PMD lib  |
 

pktdump - very simple app. built with gcc and linked with pmd lib extension
and dpdk libs.
pmd lib extension - an extension of dpdk pmd library, which provides some
higher-level APIs
dpdk pmd lib - pmd lib provided by Intel

I have an issue where in when I run the pktdump app. it's lcore threads
stops executing at varying number of times.  Sometimes it doesn't even run.
But this only happens if I use the PMD lib extension.  On the other hand,
if pktdump is directly built with pmd lib extension code while pmd lib
extension is built as an extapp, it works very well.  I wonder what's the
difference, code-wise there is none, the only difference I can see is how
they are built (extapp, extlib).

The pmd lib extension's lcore threads basically do simple forwarding (rx ->
tx).  So rte_eth_rx_burst is called when receiving packets and
rte_eth_tx_burst when transmitting packets.  These runs on an lcore thread.

snippet of code that runs on lcore:

void burst_fwd(...){
 num_rx = rte_eth_rx_burst(...)
 ...
 rte_eth_tx_burst(...)
}

Any tips on how to debug this, some quick inspections may help.  Is there
some specific build options for building libraries, because this only
happens on extlib.

[dpdk-dev] Request for a feature in PMD

[Prashant Upadhyaya]

Hi Gal, Daniel, Etai,

Thanks for your suggestion.
I could use the refcnt for my usecase effectively.

I just bumped up the refcount by 1 when I don't want to free it. The 
rte_pktmbuf_free automatically decreases it by 1 and frees the packet only when 
the refcount reaches zero.
So this is a pretty neat use of refcnt. I wonder if this usecase should be 
documented in the userguide somewhere.

Regards
-Prashant

From: Daniel Kaminsky [mailto:daniel.kamin...@infinitelocality.com]
Sent: Sunday, October 27, 2013 6:08 PM
To: Prashant Upadhyaya
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Request for a feature in PMD

Hi Prashant,

>From your description it seems that you can use rte pktmbuf_refcnt_update 
>method. Increase the reference count by one before sending the mbuf, and 
>decrease it when you finish with it.

Regards,
Daniel Kaminsky

On Sun, Oct 27, 2013 at 2:06 PM, Prashant Upadhyaya mailto:prashant.upadhyaya at aricent.com>> wrote:
Hi,

I have a feature request in the PMD.

Today, when I want to send a packet out, I hand over an mbuf to the PMD API.
The PMD API then takes care of transferring the data and free's the mbuf to the 
relevant pool.

What I am looking for is a facility that I should be able to specify somewhere 
in the header of mbuf that the PMD API must not free this buffer after doing 
the transmission.
The user will take care of freeing this buffer on his own depending on his own 
application logic (ofcourse if the user does not do so, it is a bug in his 
application for the buffer leak)

Why do I want this ? I was porting a usecase from Cavium Octeon SDK which uses 
the PKO api's to send a packet out.
PKO is the packet output unit of Cavium processor to which you submit the 
buffers to send and it frees it for you (just like our PMD in DPDK)
However PKO API gives me a nice facility where I can tell PKO not to free the 
buffer with the help of a bit.
This is particularly useful when the same buffer has to be sent out multiple 
times.

Now to port the above usecase in DPDK, I had to make a copy of the buffer and 
submit it to the PMD (because it _will_ free it) to give the application the 
similar flavour as PKO in DPDK. However the copy is a performance penalty. It 
would be nice if PMD itself gives this facility.

Would request the opinion of PMD developers regarding the above.

Regards
-Prashant





===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===





===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===

[dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

[Jose Gavine Cueto]

Hi,

Could someone help me ?  Or at least let me know if what I'm doing (diagram
above) is right with regard to using a external dpdk library ?  I assume
dpdk external libraries can be treated as norma C libraries.

Cheers,
Pepe


On Wed, Oct 30, 2013 at 8:18 AM, Jose Gavine Cueto wrote:

> Hi,
>
> I'm writing a very simple packet dump application that can be described by
> the following diagram:
>
>  ---
> |pktdump|
>  
> | PMD lib extension |
> | (extlib)  |
>  
> | DPDK PMD lib  |
>  
>
> pktdump - very simple app. built with gcc and linked with pmd lib
> extension and dpdk libs.
> pmd lib extension - an extension of dpdk pmd library, which provides some
> higher-level APIs
> dpdk pmd lib - pmd lib provided by Intel
>
> I have an issue where in when I run the pktdump app. it's lcore threads
> stops executing at varying number of times.  Sometimes it doesn't even run.
> But this only happens if I use the PMD lib extension.  On the other hand,
> if pktdump is directly built with pmd lib extension code while pmd lib
> extension is built as an extapp, it works very well.  I wonder what's the
> difference, code-wise there is none, the only difference I can see is how
> they are built (extapp, extlib).
>
> The pmd lib extension's lcore threads basically do simple forwarding (rx
> -> tx).  So rte_eth_rx_burst is called when receiving packets and
> rte_eth_tx_burst when transmitting packets.  These runs on an lcore thread.
>
> snippet of code that runs on lcore:
>
> void burst_fwd(...){
>  num_rx = rte_eth_rx_burst(...)
>  ...
>  rte_eth_tx_burst(...)
> }
>
> Any tips on how to debug this, some quick inspections may help.  Is there
> some specific build options for building libraries, because this only
> happens on extlib.
>



-- 
To stop learning is like to stop loving.

[dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

[Prashant Upadhyaya]

Hi Pepe,

How about this -- compile the libraries yourself and then link your application 
with them just like the original usecase where you find the problem.
If this works, then the problem is with the precompiled libraries you were 
picking from somewhere.

Regards
-Prashant


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jose Gavine Cueto
Sent: Wednesday, October 30, 2013 12:22 PM
To: dev at dpdk.org
Subject: Re: [dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

Hi,

Could someone help me ?  Or at least let me know if what I'm doing (diagram
above) is right with regard to using a external dpdk library ?  I assume dpdk 
external libraries can be treated as norma C libraries.

Cheers,
Pepe


On Wed, Oct 30, 2013 at 8:18 AM, Jose Gavine Cueto wrote:

> Hi,
>
> I'm writing a very simple packet dump application that can be
> described by the following diagram:
>
>  ---
> |pktdump|
>  
> | PMD lib extension |
> | (extlib)  |
>  
> | DPDK PMD lib  |
>  
>
> pktdump - very simple app. built with gcc and linked with pmd lib
> extension and dpdk libs.
> pmd lib extension - an extension of dpdk pmd library, which provides
> some higher-level APIs dpdk pmd lib - pmd lib provided by Intel
>
> I have an issue where in when I run the pktdump app. it's lcore
> threads stops executing at varying number of times.  Sometimes it doesn't 
> even run.
> But this only happens if I use the PMD lib extension.  On the other
> hand, if pktdump is directly built with pmd lib extension code while
> pmd lib extension is built as an extapp, it works very well.  I wonder
> what's the difference, code-wise there is none, the only difference I
> can see is how they are built (extapp, extlib).
>
> The pmd lib extension's lcore threads basically do simple forwarding
> (rx
> -> tx).  So rte_eth_rx_burst is called when receiving packets and
> rte_eth_tx_burst when transmitting packets.  These runs on an lcore thread.
>
> snippet of code that runs on lcore:
>
> void burst_fwd(...){
>  num_rx = rte_eth_rx_burst(...)
>  ...
>  rte_eth_tx_burst(...)
> }
>
> Any tips on how to debug this, some quick inspections may help.  Is
> there some specific build options for building libraries, because this
> only happens on extlib.
>



--
To stop learning is like to stop loving.




===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===

[dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

[Jose Gavine Cueto]

Hi Prashant,

Are you referring to the rte_* libraries ?  I had actually compiled them
using the setup script ($(RTE_SDK)/tools/setup.sh) and then linked the PMD
lib extension I've made and then linked the pktdump eventually, before
seeing the problem.  However, building it all as an app. didn't show any
issue.

I will try to redo the building/linking just to make sure.

Thank you!


On Wed, Oct 30, 2013 at 2:57 PM, Prashant Upadhyaya <
prashant.upadhyaya at aricent.com> wrote:

> Hi Pepe,
>
> How about this -- compile the libraries yourself and then link your
> application with them just like the original usecase where you find the
> problem.
> If this works, then the problem is with the precompiled libraries you were
> picking from somewhere.
>
> Regards
> -Prashant
>
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jose Gavine Cueto
> Sent: Wednesday, October 30, 2013 12:22 PM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib
>
> Hi,
>
> Could someone help me ?  Or at least let me know if what I'm doing (diagram
> above) is right with regard to using a external dpdk library ?  I assume
> dpdk external libraries can be treated as norma C libraries.
>
> Cheers,
> Pepe
>
>
> On Wed, Oct 30, 2013 at 8:18 AM, Jose Gavine Cueto  >wrote:
>
> > Hi,
> >
> > I'm writing a very simple packet dump application that can be
> > described by the following diagram:
> >
> >  ---
> > |pktdump|
> >  
> > | PMD lib extension |
> > | (extlib)  |
> >  
> > | DPDK PMD lib  |
> >  
> >
> > pktdump - very simple app. built with gcc and linked with pmd lib
> > extension and dpdk libs.
> > pmd lib extension - an extension of dpdk pmd library, which provides
> > some higher-level APIs dpdk pmd lib - pmd lib provided by Intel
> >
> > I have an issue where in when I run the pktdump app. it's lcore
> > threads stops executing at varying number of times.  Sometimes it
> doesn't even run.
> > But this only happens if I use the PMD lib extension.  On the other
> > hand, if pktdump is directly built with pmd lib extension code while
> > pmd lib extension is built as an extapp, it works very well.  I wonder
> > what's the difference, code-wise there is none, the only difference I
> > can see is how they are built (extapp, extlib).
> >
> > The pmd lib extension's lcore threads basically do simple forwarding
> > (rx
> > -> tx).  So rte_eth_rx_burst is called when receiving packets and
> > rte_eth_tx_burst when transmitting packets.  These runs on an lcore
> thread.
> >
> > snippet of code that runs on lcore:
> >
> > void burst_fwd(...){
> >  num_rx = rte_eth_rx_burst(...)
> >  ...
> >  rte_eth_tx_burst(...)
> > }
> >
> > Any tips on how to debug this, some quick inspections may help.  Is
> > there some specific build options for building libraries, because this
> > only happens on extlib.
> >
>
>
>
> --
> To stop learning is like to stop loving.
>
>
>
>
>
> ===
> Please refer to http://www.aricent.com/legal/email_disclaimer.html
> for important disclosures regarding this electronic communication.
>
> ===
>



-- 
To stop learning is like to stop loving.

[dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

[Prashant Upadhyaya]

Hi Pepe,

Please also make sure that you are following the correct makefile templates (as 
present in examples) when you build your app separately.
If you don't, then you will naturally miss out on some flags and that can prove 
fatal because your app will see some code differently in the header files of 
rte than what the library was built with based on the compiler flags.

Regards
-Prashant


From: Jose Gavine Cueto [mailto:peped...@gmail.com]
Sent: Wednesday, October 30, 2013 12:34 PM
To: Prashant Upadhyaya
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

Hi Prashant,

Are you referring to the rte_* libraries ?  I had actually compiled them using 
the setup script ($(RTE_SDK)/tools/setup.sh) and then linked the PMD lib 
extension I've made and then linked the pktdump eventually, before seeing the 
problem.  However, building it all as an app. didn't show any issue.

I will try to redo the building/linking just to make sure.

Thank you!

On Wed, Oct 30, 2013 at 2:57 PM, Prashant Upadhyaya mailto:prashant.upadhyaya at aricent.com>> wrote:
Hi Pepe,

How about this -- compile the libraries yourself and then link your application 
with them just like the original usecase where you find the problem.
If this works, then the problem is with the precompiled libraries you were 
picking from somewhere.

Regards
-Prashant


-Original Message-
From: dev [mailto:dev-bounces at dpdk.org] On 
Behalf Of Jose Gavine Cueto
Sent: Wednesday, October 30, 2013 12:22 PM
To: dev at dpdk.org
Subject: Re: [dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

Hi,

Could someone help me ?  Or at least let me know if what I'm doing (diagram
above) is right with regard to using a external dpdk library ?  I assume dpdk 
external libraries can be treated as norma C libraries.

Cheers,
Pepe


On Wed, Oct 30, 2013 at 8:18 AM, Jose Gavine Cueto mailto:pepedocs at gmail.com>>wrote:

> Hi,
>
> I'm writing a very simple packet dump application that can be
> described by the following diagram:
>
>  ---
> |pktdump|
>  
> | PMD lib extension |
> | (extlib)  |
>  
> | DPDK PMD lib  |
>  
>
> pktdump - very simple app. built with gcc and linked with pmd lib
> extension and dpdk libs.
> pmd lib extension - an extension of dpdk pmd library, which provides
> some higher-level APIs dpdk pmd lib - pmd lib provided by Intel
>
> I have an issue where in when I run the pktdump app. it's lcore
> threads stops executing at varying number of times.  Sometimes it doesn't 
> even run.
> But this only happens if I use the PMD lib extension.  On the other
> hand, if pktdump is directly built with pmd lib extension code while
> pmd lib extension is built as an extapp, it works very well.  I wonder
> what's the difference, code-wise there is none, the only difference I
> can see is how they are built (extapp, extlib).
>
> The pmd lib extension's lcore threads basically do simple forwarding
> (rx
> -> tx).  So rte_eth_rx_burst is called when receiving packets and
> rte_eth_tx_burst when transmitting packets.  These runs on an lcore thread.
>
> snippet of code that runs on lcore:
>
> void burst_fwd(...){
>  num_rx = rte_eth_rx_burst(...)
>  ...
>  rte_eth_tx_burst(...)
> }
>
> Any tips on how to debug this, some quick inspections may help.  Is
> there some specific build options for building libraries, because this
> only happens on extlib.
>



--
To stop learning is like to stop loving.



===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===



--
To stop learning is like to stop loving.




===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===

[dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib

[Jose Gavine Cueto]

Hi Prashant,

Thanks, I will investigate. Though the following is how the pktdump
application and pmd lib ext are built, just to give you an overview.

*pmd lib Makefile*

include $(RTE_SDK)/mk/rte.vars.mk

LIB = libpmd.a

CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)

SRCS-y := ... sources here


include $(RTE_SDK)/mk/rte.extlib.mk
:
*pktdump app Makefile*
*
*
include $(RTE_SDK)/mk/rte.vars.mk

APP = pktdump

LDFLAGS += -lpmd

CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
CFLAGS += -I$(IDIR)
CFLAGS += -g

SRCS-y := pktdump.c

include $(RTE_SDK)/mk/rte.extapp.mk

So I'm basically using simple Makefiles for both the lib and app (
rte.extlib.mk, rte.extapp.mk).

Thanks,
Pepe


On Wed, Oct 30, 2013 at 3:13 PM, Prashant Upadhyaya <
prashant.upadhyaya at aricent.com> wrote:

>  Hi Pepe,
>
> ** **
>
> Please also make sure that you are following the correct makefile
> templates (as present in examples) when you build your app separately.
>
> If you don?t, then you will naturally miss out on some flags and that can
> prove fatal because your app will see some code differently in the header
> files of rte than what the library was built with based on the compiler
> flags.
>
> ** **
>
> Regards
>
> -Prashant
>
> ** **
>
> ** **
>
> *From:* Jose Gavine Cueto [mailto:pepedocs at gmail.com]
> *Sent:* Wednesday, October 30, 2013 12:34 PM
> *To:* Prashant Upadhyaya
> *Cc:* dev at dpdk.org
>
> *Subject:* Re: [dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib***
> *
>
> ** **
>
> Hi Prashant,
>
> ** **
>
> Are you referring to the rte_* libraries ?  I had actually compiled them
> using the setup script ($(RTE_SDK)/tools/setup.sh) and then linked the PMD
> lib extension I've made and then linked the pktdump eventually, before
> seeing the problem.  However, building it all as an app. didn't show any
> issue.
>
> ** **
>
> I will try to redo the building/linking just to make sure.  
>
> ** **
>
> Thank you!
>
> ** **
>
> On Wed, Oct 30, 2013 at 2:57 PM, Prashant Upadhyaya <
> prashant.upadhyaya at aricent.com> wrote:
>
> Hi Pepe,
>
> How about this -- compile the libraries yourself and then link your
> application with them just like the original usecase where you find the
> problem.
> If this works, then the problem is with the precompiled libraries you were
> picking from somewhere.
>
> Regards
> -Prashant
>
>
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jose Gavine Cueto
> Sent: Wednesday, October 30, 2013 12:22 PM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] rte_eth_rx_burst stops running on dpdk extlib
>
> Hi,
>
> Could someone help me ?  Or at least let me know if what I'm doing (diagram
> above) is right with regard to using a external dpdk library ?  I assume
> dpdk external libraries can be treated as norma C libraries.
>
> Cheers,
> Pepe
>
>
> On Wed, Oct 30, 2013 at 8:18 AM, Jose Gavine Cueto  >wrote:
>
> > Hi,
> >
> > I'm writing a very simple packet dump application that can be
> > described by the following diagram:
> >
> >  ---
> > |pktdump|
> >  
> > | PMD lib extension |
> > | (extlib)  |
> >  
> > | DPDK PMD lib  |
> >  
> >
> > pktdump - very simple app. built with gcc and linked with pmd lib
> > extension and dpdk libs.
> > pmd lib extension - an extension of dpdk pmd library, which provides
> > some higher-level APIs dpdk pmd lib - pmd lib provided by Intel
> >
> > I have an issue where in when I run the pktdump app. it's lcore
> > threads stops executing at varying number of times.  Sometimes it
> doesn't even run.
> > But this only happens if I use the PMD lib extension.  On the other
> > hand, if pktdump is directly built with pmd lib extension code while
> > pmd lib extension is built as an extapp, it works very well.  I wonder
> > what's the difference, code-wise there is none, the only difference I
> > can see is how they are built (extapp, extlib).
> >
> > The pmd lib extension's lcore threads basically do simple forwarding
> > (rx
> > -> tx).  So rte_eth_rx_burst is called when receiving packets and
> > rte_eth_tx_burst when transmitting packets.  These runs on an lcore
> thread.
> >
> > snippet of code that runs on lcore:
> >
> > void burst_fwd(...){
> >  num_rx = rte_eth_rx_burst(...)
> >  ...
> >  rte_eth_tx_burst(...)
> > }
> >
> > Any tips on how to debug this, some quick inspections may help.  Is
> > there some specific build options for building libraries, because this
> > only happens on extlib.
> >
>
>
>
> --
> To stop learning is like to stop loving.
>
>
>
> 
>
>
> ===
> Please refer to http://www.aricent.com/legal/email_disclaimer.html
> for important disclosures regarding this electronic communication.
>
> ===

[dpdk-dev] [PATCH] config: fix combined/shared lib

[Olivier MATZ]

Hi Thomas,

 > - Configuration for combined and shared library was only in
 >   the template defconfig_x86_64-default-linuxapp-gcc.
> - CONFIG_RTE_LIBNAME was in the wrong section
> - CONFIG_RTE_LIBNAME quotes were not properly removed in "make context"
> - RTE_LIBNAME had no quote in "C context" (include/rte_config.h)

acked

Just one remark about the commit log: if I understand well, the
issue related to the quote not properly removed in "make context"
is triggered by the quotes you added in the defconfig. I would reword
the commit log a bit to highlight it.

Regards,
Olivier

[dpdk-dev] [PATCH] config: fix combined/shared lib

[Thomas Monjalon]

30/10/2013 09:53, Olivier MATZ :
> acked
> 
> Just one remark about the commit log: if I understand well, the
> issue related to the quote not properly removed in "make context"
> is triggered by the quotes you added in the defconfig. I would reword
> the commit log a bit to highlight it.

I've pushed it with a reword as you suggested.
Thanks for the review.
-- 
Thomas

[dpdk-dev] [PATCH] doc: add scatter gather functions in doxygen

[Thomas Monjalon]

Some functions are available only if
RTE_MBUF_SCATTER_GATHER and RTE_MBUF_REFCNT_ATOMIC are enabled.
So they must configured for doxygen parser.

Signed-off-by: Thomas Monjalon 
---
 doc/doxy-api.conf |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/doxy-api.conf b/doc/doxy-api.conf
index 5d3e4ca..28a0f84 100644
--- a/doc/doxy-api.conf
+++ b/doc/doxy-api.conf
@@ -46,7 +46,9 @@ INPUT   = doc/doxy-api-index.md \
   lib/librte_timer
 FILE_PATTERNS   = rte_*.h \
   cmdline.h
-PREDEFINED  = __DOXYGEN__
+PREDEFINED  = __DOXYGEN__ \
+  RTE_MBUF_SCATTER_GATHER \
+  RTE_MBUF_REFCNT_ATOMIC

 OPTIMIZE_OUTPUT_FOR_C   = YES
 EXTRACT_STATIC  = YES
-- 
1.7.10.4

[dpdk-dev] [PATCH] config: remove unused KNI debug option

[Thomas Monjalon]

The option RTE_LIBRTE_KNI_DEBUG has no effect so it should be removed.
The right options are:
- RTE_KNI_KO_DEBUG
- RTE_KNI_VHOST_DEBUG_RX
- RTE_KNI_VHOST_DEBUG_TX

Signed-off-by: Thomas Monjalon 
---
 config/defconfig_i686-default-linuxapp-gcc   |1 -
 config/defconfig_i686-default-linuxapp-icc   |1 -
 config/defconfig_x86_64-default-linuxapp-gcc |1 -
 config/defconfig_x86_64-default-linuxapp-icc |1 -
 4 files changed, 4 deletions(-)

diff --git a/config/defconfig_i686-default-linuxapp-gcc 
b/config/defconfig_i686-default-linuxapp-gcc
index 1894896..de31dc6 100644
--- a/config/defconfig_i686-default-linuxapp-gcc
+++ b/config/defconfig_i686-default-linuxapp-gcc
@@ -287,7 +287,6 @@ CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
 # KNI is not supported on 32-bit
 #
 CONFIG_RTE_LIBRTE_KNI=n
-CONFIG_RTE_LIBRTE_KNI_DEBUG=n
 CONFIG_RTE_KNI_KO_DEBUG=n
 CONFIG_RTE_KNI_VHOST=n
 CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
diff --git a/config/defconfig_i686-default-linuxapp-icc 
b/config/defconfig_i686-default-linuxapp-icc
index b100560..238e488 100644
--- a/config/defconfig_i686-default-linuxapp-icc
+++ b/config/defconfig_i686-default-linuxapp-icc
@@ -286,7 +286,6 @@ CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
 # KNI is not supported on 32-bit
 #
 CONFIG_RTE_LIBRTE_KNI=n
-CONFIG_RTE_LIBRTE_KNI_DEBUG=n
 CONFIG_RTE_KNI_KO_DEBUG=n
 CONFIG_RTE_KNI_VHOST=n
 CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
diff --git a/config/defconfig_x86_64-default-linuxapp-gcc 
b/config/defconfig_x86_64-default-linuxapp-gcc
index cb8e405..54337a8 100644
--- a/config/defconfig_x86_64-default-linuxapp-gcc
+++ b/config/defconfig_x86_64-default-linuxapp-gcc
@@ -286,7 +286,6 @@ CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
 # Compile librte_kni
 #
 CONFIG_RTE_LIBRTE_KNI=y
-CONFIG_RTE_LIBRTE_KNI_DEBUG=n
 CONFIG_RTE_KNI_KO_DEBUG=n
 CONFIG_RTE_KNI_VHOST=n
 CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
diff --git a/config/defconfig_x86_64-default-linuxapp-icc 
b/config/defconfig_x86_64-default-linuxapp-icc
index 167ed74..931a1a7 100644
--- a/config/defconfig_x86_64-default-linuxapp-icc
+++ b/config/defconfig_x86_64-default-linuxapp-icc
@@ -285,7 +285,6 @@ CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
 # Compile librte_kni
 #
 CONFIG_RTE_LIBRTE_KNI=y
-CONFIG_RTE_LIBRTE_KNI_DEBUG=n
 CONFIG_RTE_KNI_KO_DEBUG=n
 CONFIG_RTE_KNI_VHOST=n
 CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
-- 
1.7.10.4

[dpdk-dev] [PATCH] eal: remove unused macro for blacklist

[Thomas Monjalon]

This macro was used for blacklist parsing but is not used anymore
since commit 5a55b9ac91face71e9d665eecc716201d28745b0.

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/linuxapp/eal/eal.c |   12 
 1 file changed, 12 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 05998e9..866013d 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -105,18 +105,6 @@

 #define BITS_PER_HEX 4

-#define GET_BLACKLIST_FIELD(in, fd, lim, dlm)   \
-{   \
-   unsigned long val;  \
-   char *end;  \
-   errno = 0;  \
-   val = strtoul((in), &end, 16);  \
-   if (errno != 0 || end[0] != (dlm) || val > (lim))   \
-   return (-EINVAL);   \
-   (fd) = (typeof (fd))val;\
-   (in) = end + 1; \
-}
-
 /* Allow the application to print its usage message too if set */
 static rte_usage_hook_trte_application_usage_hook = NULL;

-- 
1.7.10.4

[dpdk-dev] [PATCH v2] doc: add mbuf cloning functions in doxygen

[Thomas Monjalon]

Some functions are available only if RTE_MBUF_SCATTER_GATHER is enabled.
So it must be configured for doxygen parser.

Signed-off-by: Thomas Monjalon 
---
 doc/doxy-api.conf |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/doxy-api.conf b/doc/doxy-api.conf
index 5d3e4ca..7ea692a 100644
--- a/doc/doxy-api.conf
+++ b/doc/doxy-api.conf
@@ -46,7 +46,8 @@ INPUT   = doc/doxy-api-index.md \
   lib/librte_timer
 FILE_PATTERNS   = rte_*.h \
   cmdline.h
-PREDEFINED  = __DOXYGEN__
+PREDEFINED  = __DOXYGEN__ \
+  RTE_MBUF_SCATTER_GATHER

 OPTIMIZE_OUTPUT_FOR_C   = YES
 EXTRACT_STATIC  = YES
-- 
1.7.10.4