> -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
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
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
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
> 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
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
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 +++
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
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
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
10 matches
Mail list logo