hope that future Intel commits don't come with a censored commit history...
it isn't very friendly when you're trying to get help tracking down bugs and
fixing stuff from the community side.
Thanks,
Matthew.
On Mon, Oct 13, 2014 at 10:47:12PM -0700, Matthew Hall wrote:
> Hi,
On Fri, Oct 24, 2014 at 08:10:40AM +, O'driscoll, Tim wrote:
> At the moment, within Intel we test with KVM, Xen and ESXi. We've never
> tested with VirtualBox. So, maybe this is an error on the Supported NICs
> page, or maybe somebody else is testing that configuration.
So, one of the most
On Fri, Oct 24, 2014 at 12:10:20PM +0200, Thomas Monjalon wrote:
> I'm the author of this page. I think I've written VirtualBox to show where
> virtio is implemented. You interpreted this as "supported environment", so
> I'm removing it. Thanks for testing and reporting.
Of course, I'm very sorr
On Fri, Oct 24, 2014 at 06:36:29PM +0530, Stephen Hemminger wrote:
> The code is fairly consistent in returning -1 for cases of not a NUMA socket,
> bogus port value. It is interpreted as SOCKET_ID_ANY in several places.
> The examples mostly check for -1 and use socket 0 as a fallback.
> Probably
On Mon, Oct 27, 2014 at 03:13:39PM +0100, Thomas Monjalon wrote:
> You didn't answer to my previous comment on this.
> I think these definitions are useless. 64 is 64.
Putting labels on the constants gives meaning to them as well as a numeric
value. Not doing so is an antipattern referred to as "
On Wed, Oct 29, 2014 at 03:27:58AM +, Qiu, Michael wrote:
> I just saw one return path with value '0', and no any other place
> return a negative value, so it is better to be designed as one
> non-return function,
>
> +void
> +rte_eal_hugepage_free(void)
> +{
> + struct hugepage_file *h
On Wed, Oct 29, 2014 at 01:47:39PM +0800, linhaifeng wrote:
> +int
> +rte_eal_hugepage_free(void)
> +{
> + struct hugepage_file *hugepg_tbl = g_hugepage_table.hugepg_tbl;
> + unsigned i;
> + unsigned nr_hugefiles = g_hugepage_table.nr_hugefiles;
> + int ret = 0;
> +
> + for (i =
On Wed, Oct 29, 2014 at 11:32:12AM -0400, Neil Horman wrote:
> >
> Well, abnormal termination results in abnormal consequences. You expect
> garbage to get left behind of a program crashes, so I wouldn't really worry
> about that too much. If you really wanted to you can register chained
> hand
Signed-off-by: Matthew Hall
---
lib/librte_eal/linuxapp/eal/eal_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 5fe3961..ddb0535 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b
5PM -0700, Matthew Hall wrote:
>> On Wed, Oct 29, 2014 at 11:32:12AM -0400, Neil Horman wrote:
>> > >
>> > Well, abnormal termination results in abnormal consequences. You
>expect
>> > garbage to get left behind of a program crashes, so I wouldn't
>rea
On Thu, Oct 30, 2014 at 09:18:23AM +, Gonzalez Monroy, Sergio wrote:
> I would say that D) is a good balance, although not being the simplest.
A, or D. Depending on things such as, "If you run the DPDK on Random Platform
X," where X could be something like Power CPUs or other weird stuff, wil
On Fri, Oct 31, 2014 at 10:45:07AM +, Gonzalez Monroy, Sergio wrote:
> That flow work still presents some issues as they may be features that are
> incompatible between each other and would need to be in different DPDK
> copies.
>
> Regards,
> Sergio
So I think the two questions are:
1) Wi
On Mon, Sep 01, 2014 at 02:32:40PM +0530, Anand S Angadi wrote:
> >Hello everyone,
> >I am using fedora 16, i want to Add additional Grub entry with hugepages
> >enabled permanently can u tell me how can i add?
> >and wher can i add?
Try /etc/default/grub .
On Wed, Oct 21, 2015 at 11:03:41AM +0200, Thomas Monjalon wrote:
> Compilation must be tested with GCC and clang, as static and shared libraries
> and for 32-bit and 64-bit targets.
Is this process scripted somewhere?
Matthew.
On Fri, Oct 23, 2015 at 03:51:48PM +0200, Michal Jastrzebski wrote:
> From: Michal Kobylinski
>
> The current DPDK implementation for LPM for IPv4 and IPv6 limits the
> number of next hops to 256, as the next hop ID is an 8-bit long field.
> Proposed extension increase number of next hops for IP
On Fri, Oct 23, 2015 at 09:33:05AM -0700, Stephen Hemminger wrote:
> On Fri, 23 Oct 2015 09:20:33 -0700
> Matthew Hall wrote:
>
> > On Fri, Oct 23, 2015 at 03:51:48PM +0200, Michal Jastrzebski wrote:
> > > From: Michal Kobylinski
> > >
> > > The cu
On 10/23/15 9:20 AM, Matthew Hall wrote:
> On Fri, Oct 23, 2015 at 03:51:48PM +0200, Michal Jastrzebski wrote:
>> From: Michal Kobylinski
>>
>> The current DPDK implementation for LPM for IPv4 and IPv6 limits the
>> number of next hops to 256, as the next ho
> I can't apply patch 0001-... , could You check it please?
I generated it from a rebase of my own copy of DPDK against DPDK upstream
master.
So I'm not sure why it would not apply against latest DPDK master.
But I will try it and see what could be the reason.
Matthew.
On Wed, Oct 28, 2015 at 12:20:22PM +0530, Padam Jeet Singh wrote:
> Any hint what could I be doing wrong here?
When this kind of stuff doesn't work it often will depend on the exact version
of card, chip, etc. if there are any errata.
So you might want to collect the specifics of the board with
On Mon, Oct 26, 2015 at 11:40:46AM -0700, Matthew Hall wrote:
> > I can't apply patch 0001-... , could You check it please?
>
> I generated it from a rebase of my own copy of DPDK against DPDK upstream
> master.
>
> So I'm not sure why it would not apply against
On Fri, Oct 30, 2015 at 12:00:18PM +, Bruce Richardson wrote:
> Matthew's patches were attachments, I don't think they came through in
> patchwork
> correctly :-(, but that is the relevant link there anyway.]
Let me know if there is something I can do better there. I was having a
difficult
On Fri, Oct 30, 2015 at 01:23:52PM +, O'Driscoll, Tim wrote:
> That makes sense. So maybe what we're converging on is the following:
> - The scope of the Architecture Board covers all projects hosted on dpdk.org.
> - The Architecture Board will approve new projects to be hosted on dpdk.org.
> -
On Fri, Oct 30, 2015 at 09:55:16PM +, Bruce Richardson wrote:
> We'll see what we can do in 2.3 timeframe.
Thanks for taking all of this up and helping us make a solid plan. I'll do my
best to help out from the community side. I have done some lightweight
functionality tests of my patched LP
On Tue, Sep 01, 2015 at 04:37:18PM +0200, Martin Dra?ar wrote:
> Dne 1.9.2015 v 15:45 De Lara Guarch, Pablo napsal(a):
> > 82574L NIC uses em PMD, which does not support more than 1 queue.
> > Therefore RSS is disabled in the NIC and then you cannot have RSS hashes.
> >
> > Thanks,
> > Pablo
>
>
On Tue, Sep 08, 2015 at 11:43:38PM +, Ale Mansoor wrote:
> When using l2fwd example using igb_uio, the performance numbers I got were
> very low (<100 PPS) and when I tried using vmxnet3-usermap from dpdk.org, it
> does not even seem to compile under the Linux 3.x Kernel.
Not everybody will
On Fri, Sep 11, 2015 at 07:18:20PM +0300, Vladislav Zolotarov wrote:
> We thought about linearization too. It's doable with extra mempool and it
> may be optional so that those that don't need could compile it out and/or
> disable it in a runtime...
High-level question. How realistic is sending a
On Fri, Sep 11, 2015 at 05:42:48PM +, Ananyev, Konstantin wrote:
> As I remember, with freebsd stack when TSO is on it was not unusual to see
> chains of ~30 segments.
> That's over port with 'normal' mtu (1.5K).
> Konstantin
This makes things quite tricky, because the TSO logic itself would
You have to use a patched valgrind.
Search the mailing list archives for some further details of the patches.
Matthew.
On Wed, Jul 13, 2016 at 09:53:46AM +, Eelco Chaudron wrote:
> Hi All,
>
> Has some one successfully ran DPDK 16.04 with Valgrind (latest SVN copy)?
> I???m still getting i
On Tue, Jul 26, 2016 at 02:53:13PM +, Luca Boccassi wrote:
> While working on uploading DPDK to Ubuntu and Debian, we were wondering
> if anyone had any thoughts/opinions on enabling compiler hardening flags
> for the DPDK libraries and the possible performance implications.
Most of the C prof
On Wed, Jul 27, 2016 at 12:58:12PM +, Mcnamara, John wrote:
> Hi Matthew,
>
> Maybe you kick this off and submit something to the new howto section of the
> docs with whatever tuning tips you have so far.
>
> Then we can get people to contribute over time until we have something more
> usef
On Wed, Jun 01, 2016 at 03:00:11PM +, Wiles, Keith wrote:
> The INI file is too flat and I wanted a hierarchy in the data, the JSON data
> is similar and XML is just hard to read.
I don't think it's fair to say JSON lacks hierarchy. Personally it is working
great in my current application. T
On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote:
> Would this work better in the long run, does a fixed structure still make
> sense?
This right here is why I suggested libjson-c as an example. It has a nice API
like this already:
http://json-c.github.io/json-c/json-c-0.12/doc/html
On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote:
> struct key_vals {
> char *key;
> union {
> ulong longval;
> void *ptrval;
> } value;
> };
>
> struct config {
> size_t count;
> struct key_vals kvp[0];
> };
This sort of code i
On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote:
> > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy any
> > performance advantage because it's just for config.
> >
> What!? I can't even parse that sentence.
I would not want to have to use the structure you p
On Fri, Jun 03, 2016 at 03:07:49PM +, Mcnamara, John wrote:
> What changes should be backported
> -
>
> * Bug fixes that don't break the ABI.
>
>
> What changes should not be backported
> -
>
> * API or ABI breaking changes
On Fri, Jun 03, 2016 at 09:52:40PM +0300, Arnon Warshavsky wrote:
> What about the data types of the values?
> I would assume that as a library it can provide the service of typed
> get/set and not leave conversion and validation to the app.
>
> rte_map_get_int(map,section,key)
> rte_map_get_doubl
On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote:
> If I understand your code above the API would pass in a default value if one
> did not exist in the storage, which I guess is reasonable. Anyone think this
> is a good idea or not?
This model has worked very well in my code at least
On Fri, Jun 03, 2016 at 03:18:04PM -0400, Neil Horman wrote:
> I'm not opposed to default values, but it seems to me that if we are splitting
> out a configuration storage library from dpdk, part of the initzliation of
> that
> library can be installing default values. That is to say, instead of
On Fri, Jun 03, 2016 at 07:23:39PM +, Wiles, Keith wrote:
> If someone needs or wants default values in the API call then a wrapper
> functions around the basic keystore APIs can be done by the developer or we
> can add a new set of APIs to provide that type of feature, just like the
> varia
On Mon, Nov 02, 2015 at 11:51:23PM +0100, Thomas Monjalon wrote:
> But it is simpler to say that having an API depending of some options
> is a "no-design" which could seriously slow down the DPDK adoption.
What about something similar to how Java JNI works? It needed to support
multiple Java JRE
On Tue, Nov 03, 2015 at 11:44:22AM +, Zoltan Kiss wrote:
> Also, there could be places in the code where we change a set of
> continuous fields in the mbuf. E.g. ixgbe vector pmd receive
> function takes advantage of 128 bit vector registers and fill out
> rx_descriptor_fields1 with one instruc
In my development environment I set up an at-boot provisioning script that
does it. I recommend using scripts and not shelling out from C code. ;)
On Wed, Nov 11, 2015 at 04:13:01PM +, Montorsi, Francesco wrote:
> Hi,
> Is there a way to permanently (i.e., have the configuration automatically
On Thu, Nov 12, 2015 at 02:05:08PM -0800, Stephen Hemminger wrote:
> Looking at the Coverity scan for DPDK, it looks like all the base
> drivers are marked to be ignored.
>
> Although the changes to base drivers should not be done directly through
> DPDK list. I think it is still valuable to have
Signed-off-by: Matthew Hall
---
lib/librte_eal/common/include/rte_log.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_log.h
b/lib/librte_eal/common/include/rte_log.h
index ede0dca..be961d0 100644
--- a/lib/librte_eal/common/include
This is a simple but very helpful patch for app developers. It allows a wider
range of log levels from in the rte_log framework.
It allows developers to avoid resorting to a lot of external log frameworks in
their DPDK code.
Matthew Hall (6):
librte_log: add function to retrieve log_level
Signed-off-by: Matthew Hall
---
lib/librte_eal/common/include/rte_log.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/common/include/rte_log.h
b/lib/librte_eal/common/include/rte_log.h
index ede0dca..9dad24e 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib
Signed-off-by: Matthew Hall
---
lib/librte_eal/common/include/rte_log.h | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_log.h
b/lib/librte_eal/common/include/rte_log.h
index 9dad24e..7dc19e1 100644
--- a/lib/librte_eal
Signed-off-by: Matthew Hall
---
lib/librte_eal/common/eal_common_log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_log.c
b/lib/librte_eal/common/eal_common_log.c
index 1ae8de7..510eeff 100644
--- a/lib/librte_eal/common/eal_common_log.c
Signed-off-by: Matthew Hall
---
lib/librte_eal/common/include/rte_log.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_log.h
b/lib/librte_eal/common/include/rte_log.h
index 7dc19e1..4a70ce5 100644
--- a/lib/librte_eal/common/include
Signed-off-by: Matthew Hall
---
lib/librte_eal/common/include/rte_log.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_log.h
b/lib/librte_eal/common/include/rte_log.h
index 4a70ce5..d7e11f1 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib
Signed-off-by: Matthew Hall
---
lib/librte_eal/linuxapp/eal/eal_log.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_log.c
b/lib/librte_eal/linuxapp/eal/eal_log.c
index 0b133c3..dbeff75 100644
--- a/lib/librte_eal/linuxapp/eal/eal_log.c
+++ b/lib/librte_eal
On Fri, Nov 13, 2015 at 12:12:04AM +, Mcnamara, John wrote:
> If people haven't already done so I would urge them to sign up and view/fix
> the defects.
>
> https://scan.coverity.com/users/sign_up
> https://scan.coverity.com/projects/4005 (DPDK)
Hi John,
I got signed up. Thanks for
On Fri, Nov 13, 2015 at 11:40:09AM +, Bruce Richardson wrote:
> I don't think this patch is necessary, as all it adds is a single extra line
> to
> a comment.
>
> /Bruce
This one was previously merged. So indeed we can toss it.
This is what happens when you are restricted to 1 AM coding.
M
On Fri, Nov 13, 2015 at 12:49:36PM +0100, Thomas Monjalon wrote:
> I'm sad for you Bruce: you only see an empty line where you could catch
> the beauty of the star ;)
+1
> Matthew, obviously you failed your send.
You might find a more polite way than calling contributions failures. ;)
> As a ge
On Fri, Nov 13, 2015 at 11:48:41AM +, Ananyev, Konstantin wrote:
> Actually another question: are existing 8 levels not enough?
> Konstantin
Depends who you ask. I was modeling it based upon the following:
https://docs.oracle.com/javase/7/docs/api/java/util/logging/Level.html
The reason I ad
On Fri, Nov 13, 2015 at 08:07:41AM -0800, Stephen Hemminger wrote:
> I understand the motivation but the existing levels match syslog
> which are what you want for a production application.
>
> The new levels are only for developer logs. I don't think we want all
> the developer levels beyond debu
On Fri, Nov 13, 2015 at 11:44:03AM +, Bruce Richardson wrote:
> Why 11 log levels - it seems an odd number?
> Also, not sure about the {fine, finer, finest} names. My thinking would be to
> just start numbering them after DEBUG, so RTE_LOG_L9, RTE_LOG_L10 etc., which
> would allow us to add on
On Fri, Nov 13, 2015 at 08:41:43AM -0800, Stephen Hemminger wrote:
> -1
> This is already done by syslog and friends and adds more cruft to log
> messages.
On the console it is not.
Matthew.
On Fri, Nov 13, 2015 at 07:21:24PM +, Mcnamara, John wrote:
> Hi Matthew,
>
> I definitely be interested in getting SonarQube working with DPDK. We can
> sync up on this as soon as the 2.2 bush fires die down.
>
> John.
Awesome! Looking forward to it.
On Fri, Nov 13, 2015 at 11:38:22AM -0800, Stephen Hemminger wrote:
> It looked like SonarQube was both non-free for doing any real scans,
> and the default C rules were oriented towards a completely different
> Windows oriented coding style.
I was using the free version to do SA dashboad for a tea
On Mon, Nov 16, 2015 at 05:31:29PM -0800, Stephen Hemminger wrote:
> The DPDK 2.2 driver uses:
> wthresh = 0
> hthresh = 0
> pthresh = 32
Stephen,
I thought the zero values lead to doing the auto-config by the driver itself?
Matthew.
I was trying to rebase my DPDK onto v2.1.0 and I came across some very
confusing code in examples/l3fwd/main.c .
So... this code used the RTE_NEXT_ABI macros on a change which does not appear
to affect the API... on a function that is marked always_inline ???
Maybe I missed something but this s
On Sat, Nov 21, 2015 at 11:44:20AM +0100, Thomas Monjalon wrote:
> The new mbuf provides packet type instead of flags.
> So the processing in this function is changed and the variable name is
> different to reflect this.
But the data type of the variable is the same, and this is an internal
alway
Hello,
There are some really weird errors if you try to compile pktgen using DPDK
2.1.0. No matter what I try, the logic in the DPDK external app *.mk files
seems to mess up the value of RTE_OUTPUT.
I tried tracing through the *.mk and I found various places where it was set
right and various
On Sun, Nov 22, 2015 at 09:59:30PM +0100, Thomas Monjalon wrote:
> > So again I am confused what advantage we got from RTE_NEXT_ABI here, and
> > how
> > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a
> > binary variable.
>
> I don't understand what is not clear here.
I was reading through the deprecations in rte_eth_stats to see if I could fix
the pktgen. Of course many fields were marked with __rte_deprecated .
However I found this one field which said deprecated in its comment, but it
lacked __rte_deprecated .
Is the comment wrong, or is the field definit
On Mon, Nov 23, 2015 at 01:13:32AM +0100, Thomas Monjalon wrote:
> If your change is sent upstream, you must rely on the new ABI because the old
> one
> will be removed when your change will be integrated.
> If it is a local change, it depends on which ABI you want to use.
I submitted separately
Signed-off-by: Matthew Hall
---
app/pktgen-stats.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/app/pktgen-stats.c b/app/pktgen-stats.c
index f1de4d7..f552ac2 100644
--- a/app/pktgen-stats.c
+++ b/app/pktgen-stats.c
@@ -305,8 +305,6 @@ pktgen_page_stats(void
I would like to reindent it using the following astyle command, with a few
small hand edits past that level, to get it closer to most other DPDK code as
the inconsistent mix of tabs, spaces, etc. makes it difficult to read and
debug when it has issues.
Obviously the upstream Lua and common/wr_*
On Wed, Jul 08, 2015 at 02:21:42PM +0100, Bruce Richardson wrote:
> Irrespective of whether or not we change the underlying hash table
> implementation
> this looks a good change to me. The rte_hash structure should not be used
> directly
> by any applications - the APIs all take pointers to the
On Thu, Jul 09, 2015 at 09:12:23AM +0100, Bruce Richardson wrote:
> Thanks for the feedback Matthew. Can you suggest a function prototype for such
> a walk operation that would make it useful for you. While we can keep the
> hash structure public, I'd prefer if we could avoid it, as it makes making
Not sure for Mr. Kim, but for me, performance is actually not my main
inspiration to use DPDK. I began using it in about 2011 when I got a training
on it from the 6WIND guys before it became open source. What impressed me most
was how much simpler it was to troubleshoot, debug, maintain, and add
On Wed, Jun 03, 2015 at 07:54:11PM -0700, Alexander Duyck wrote:
> However the ones that are going straight into my spam folder list an IPv6
> address that is rated neutral by the SPF:
> Received: from dpdk.org ([2001:4b98:dc0:41:216:3eff:fe72:dd13])
> by mx.google.com with ESMTP id cy1si1
On Wed, Jun 03, 2015 at 08:07:57PM -0700, Matthew Hall wrote:
> Hello,
>
> I can confirm your claims. When I enabled IPv6 on my mail server Google began
> dropping or severely graylisting 100% of the mail until the IPv6 subnet was
> added to the SPF record. This needs to get fi
On Fri, Jun 05, 2015 at 10:27:21AM -0500, Jay Rolette wrote:
> Is there some mechanism available that the KNI kernel thread could sleep
> periodically, but somehow be awoken from user space?
This is wildly unvalidated, but futex and SysV semaphore appear to be
accessible from the kernel side. Sys
>From Cunming:
> I'm trying to understand the motivation.
>
> I don't think you're going to gracefully exit intr thread but leave all
> other eal threads live. We don't have API to new launch intr thread again.
The doc comment added for rte_eal_intr_exit already explains this. According
to the
On Thu, Mar 17, 2016 at 10:19:24AM -0700, Stephen Hemminger wrote:
> > > A better patch would be to move the data structure into the
> > > code block used, and get rid of the useless else (rte_panic never
> > > returns);
> > > and fix the indentation, and use C99 initialization which should make
On Mon, Mar 21, 2016 at 10:56:18AM -0700, Stephen Hemminger wrote:
> The mk environment in DPDK puts files in build/ directory
> so it makes sense to have a .gitignore file to skip that
> directory.
The last time I proposed such a patch it was rejected. It is sad when
community patches are second
On Mon, Mar 21, 2016 at 03:58:44PM +0800, Liang, Cunming wrote:
> the default termination handler
I am not so experienced with this "default termination handler". Can someone
clarify what it is so I could comment better about it?
> If EINTR is caused by some non-term purpose signals, are you goi
On Thu, Apr 07, 2016 at 12:16:34PM +0200, Marc Sune wrote:
> I keep not understanding the ABI policy, and particularly why ABI changes
> have to be announced once cycle before _if_ there is already at least one
> ABI change proposed. DPDK applications will have to recompile anyway.
>
> This aspect
On Thu, Apr 07, 2016 at 02:51:35PM +0300, Panu Matilainen wrote:
> LTS releases could help the situation somewhat, but then again
> people tend to still want those new fancy things backported (you
> know, have the cake and eat it too) but that can't be done because
> of ABI breakage, so they're for
On Wed, Aug 31, 2016 at 05:26:41PM +, Bodek, Zbigniew wrote:
> I've seen some GPL stuff, mostly kernel modules from
> Intel. So what with the above mentioned OpenSSL?
The modules are that way to be compatible with the kernel. The rest is BSD.
See: http://dpdk.org/dev on Licenses.
Matthew.
On Mon, Feb 01, 2016 at 01:51:29AM +0100, Nikita Kozlov wrote:
> Hello,
> I wanted to know if there was something new or if I can help on this topic ?
> I'm using rte_lpm in a project so I may (at least) do some tests or reviews.
If you search the archive of the list some patch came out recently w
On Mon, Feb 01, 2016 at 04:47:56PM +, David Harton (dharton) wrote:
> Hi folks,
>
> I didn't see any follow up to this response.
>
> My original concern was rte_eth_stats_get() moving away from a more
> conventional based definition (note, I believe Matthew Hall
On Wed, Feb 10, 2016 at 07:05:40PM -0800, Seth Arnold wrote:
> - ixgbe driver in the package is very different from the driver in the
> Linux kernel -- when bugs in one are found, who is in charge of copying
> the fixes between the two code bases?
It's not the Linux driver. It's from BSD becau
Signed-off-by: Matthew Hall
---
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index 06b26a9..b33ccdb 100644
--- a/lib/librte_eal/linuxapp/eal
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 overlap in memcpy(0x6851c00, 0x6851c00, 4144)
==18730==at 0x4C30573:
> 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
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
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
I had all kinds of very weird failures using the 64 bit clang target related to
missing CPUFLAGS. For a while I hacked around it by adding a whole ton of -D
for missing RTE CPUFLAGS macros. But then some further DPDK changes came and
caused clang bud failures I could not debug and I had to give
On Tue, Feb 16, 2016 at 12:57:24PM +, De Lara Guarch, Pablo wrote:
> We suspect this might be an architecture dependent issue.
> Could you tell us which CPU you are using?
>
> Thanks,
> Pablo
When it happens to me I am using a Skylake Core i7-6700K.
Matthew.
On Wed, Feb 17, 2016 at 11:07:40AM +, De Lara Guarch, Pablo wrote:
> It looks like old versions of clang are not able to identify correctly the
> newer CPUs:
>
> LLVM (http://llvm.org/):
> LLVM version 3.6.2
>
> Optimized build.
> Built Aug 18 2015 (08:39:18).
> Default target: x86_6
On Thu, Nov 17, 2016 at 09:20:50AM +, Mcnamara, John wrote:
> One committer to master represents a single point of failure and at times can
> be inefficient.
I have a lot more issues because of slow or inconclusive review of patches
than I do because of committers. Often times they just get
On Wed, Oct 05, 2016 at 01:26:30PM +, Montorsi, Francesco wrote:
> Correct, but in my experience DPDK never creates such a long line of log
> message...
>
> Francesco
This comment is fatally flawed. Many of us write our applications using these
functions. I have things which hex-dump packe
On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote:
> There were some debates about software statistics disabling.
> Should they be always on or possibly disabled when compiled?
> We need to take a decision shortly and discuss (or agree) this proposal:
> http://dpdk.org/ml/archiv
Hi all,
I am getting some odd behavior compiling the DPDK v2.0.0 tag with clang:
/* deprecated options */
#pragma GCC poison RTE_MBUF_SCATTER_GATHER
#pragma GCC poison RTE_MBUF_REFCNT
In file included from dpdk/lib/librte_mbuf/rte_mbuf.c:58:
dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoni
201 - 300 of 316 matches
Mail list logo
