[dpdk-dev] Question about log levels and rte_panic

I have some code I have been debugging that does a rte_panic() at some point. The problem is it just appeared to exit without printing the panic message. I tracked it down to rte_vlog() doing the following test. if ((level > rte_logs.level) || !(logtype & rte_logs.type)) return 0; The r

[dpdk-dev] vm_power_manager uses channel_commands.h which is not placed in installed copy of DPDK

Hello, I found a peculiarity in the vm_power_manager example on DPDK 2.2 if you use an installed copy of DPDK to compile the examples instead of the master copy (while trying to update some outdated stuff in my build system). mhall at mvs-01:~/dpdk/examples/vm_power_manager$ fgrep -ir channel_c

[dpdk-dev] [PATCH 3/3] rte_epoll_wait: allow EINTR to be passed to caller

Otherwise the caller will not be able to handle a return from a signal handler. Signed-off-by: Matthew Hall --- lib/librte_eal/linuxapp/eal/eal_interrupts.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c b/lib/librte_eal/li

[dpdk-dev] [PATCH 2/3] eal_interrupts: mark EAL interrupt thread as a daemon thread

This thread should not be stuck in an active state when the application is shutting down. Signed-off-by: Matthew Hall --- lib/librte_eal/linuxapp/eal/eal_interrupts.c | 39 +--- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal

[dpdk-dev] [PATCH 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread

There is no good way to shut down this thread from an application signal handler. Here we add an rte_eal_intr_exit() function to allow this. Signed-off-by: Matthew Hall --- lib/librte_eal/common/include/rte_eal.h | 9 + lib/librte_eal/linuxapp/eal/eal_interrupts.c | 11 +++

[dpdk-dev] DPDK (and rte_*alloc family) friendly Valgrind

On Thu, 2016-02-11 at 08:34 +0100, Thomas Monjalon wrote: > 2016-02-10 22:54, Luca Boccassi: > I created a set of patches for Valgrind that add support for the > > rte_*alloc family of functions. We use it for memcheck (I added support > > for other all the other Valgrind tools like cachegrind as

[dpdk-dev] DPDK (and rte_*alloc family) friendly Valgrind

On Fri, 2016-02-12 at 22:47 -0800, Matthew Hall wrote: > 2016-02-10 22:54, Luca Boccassi: > > I created a set of patches for Valgrind that add support for the rte_*alloc > > family of functions. We use it for memcheck > > Hi Luca, > > This is awesome stuff: > > ==18730== Source and destination

[dpdk-dev] DPDK (and rte_*alloc family) friendly Valgrind

On Feb 13, 2016, at 4:30 AM, Luca Boccassi wrote: > I have not, however, implemented support for NUMA sockets. There is no > such concept inside Valgrind's framework at the moment, so it would be a > monumental task. There is a way to mark the mallocs and frees from inside a custom allocator ins

[dpdk-dev] Question about log levels and rte_panic

> On Feb 13, 2016, at 9:43 AM, Wiles, Keith wrote: > > I would expect EMERG, ALERT and CRIT messages to be printed regardless of the > log-level value I wouldn't expect that based on the traditional custom of syslog daemons. If you specify a filter configuration, such as setlogmask or some cu

[dpdk-dev] [PATCH] i40e: fix for default flexible payload registers settings

> -Original Message- > From: Chilikin, Andrey > Sent: Wednesday, September 30, 2015 10:16 AM > To: dev at dpdk.org > Cc: Chilikin, Andrey > Subject: [PATCH] i40e: fix for default flexible payload registers settings > > This patch applies new default values to flexible payload configuration