On Tue, Sep 09, 2014 at 11:42:40AM +, De Lara Guarch, Pablo wrote:
> That 4 is not shifted, so it is actually 4 entries/bucket. Actually, the
> maximum number of entries you can use is 16, as bucket will be as big as a
> cache line. However, regardless the number of entries, memory size will
On Tue, Sep 09, 2014 at 07:54:19AM -0700, Stephen Hemminger wrote:
> Porting Linux stack to DPDK opens up a licensing can of worms.
> Linux code is GPLv2, and DPDK code is BSD. Any combination of the two would
> end up
> being covered by the Linux GPLv2 license.
It would be a can of worms for a
On Tue, Sep 09, 2014 at 08:00:32AM -0700, Jim Thompson wrote:
> BPF JIT, or even pflua[1] should be straight-forward to put on top of DPDK.
> (It?s straight-forward to do on top of netmap.)
>
> jim
The pflua guys made a user-space copy of Linux BPF JIT. I'm planning to use
that because it was
On Tue, Sep 09, 2014 at 10:30:01PM +0100, Alexander Nasonov wrote:
> sys/net/bpfjit.c in NetBSD should be very easy to adapt to Linux.
> I was often testing it on Linux in userspace (without mbuf support).
> At the moment, I'm only allowed to work on some NetBSD projects and
> I can't adapt bpfjit
Signed-off-by: Matthew Hall
---
lib/librte_eal/common/eal_common_log.c | 7 +++
lib/librte_eal/common/include/rte_log.h | 6 ++
2 files changed, 13 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_log.c
b/lib/librte_eal/common/eal_common_log.c
index e4df0b9..d979f28 100644
On Sun, Sep 14, 2014 at 01:34:46AM -0700, Matthew Hall wrote:
> Signed-off-by: Matthew Hall
> ---
> lib/librte_eal/common/eal_common_log.c | 7 +++
> lib/librte_eal/common/include/rte_log.h | 6 ++
> 2 files changed, 13 insertions(+)
I forgot to mention in the comme
age-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
>> Sent: Sunday, September 14, 2014 9:35 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH] librte_log: add function to retrieve
>log_level
>>
>> Signed-off-by: Matthew Hall
&
ot; wrote:
>> -Original Message-
>> From: Matthew Hall [mailto:mhall at mhcomputing.net]
>> Sent: Monday, September 15, 2014 9:17 AM
>> To: Richardson, Bruce; dev at dpdk.org
>> Subject: RE: [dpdk-dev] [PATCH] librte_log: add function to retrieve
>log_level
>
On Thu, Sep 18, 2014 at 07:13:43AM +0300, Vadim Suraev wrote:
> Hi,
> I've published the source code of Linux kernel IP stack ported to user space
> and integrated with DPDK (1.6 currently).
> I includes also some example applications & test scripts as well as
> documentation
> about what & how is
On Thu, Sep 18, 2014 at 03:29:11PM +0200, Thomas Monjalon wrote:
> void is missing here
Ah yes, sorry for missing it.
Thanks for correcting and applying, glad to have it available upstream.
Matthew.
I fixed some of the clang errors a few weeks ago. But some of my patches got
sent back due to issues seen by others and I didn't have time to fix them yet.
--
Sent from my mobile device.
On September 22, 2014 6:18:51 AM PDT, Neil Horman
wrote:
>On Mon, Sep 22, 2014 at 09:36:33AM +,
On Mon, Sep 22, 2014 at 04:05:29PM -0400, Neil Horman wrote:
> On Mon, Sep 22, 2014 at 12:23:36PM -0700, Matthew Hall wrote:
> > I fixed some of the clang errors a few weeks ago. But some of my patches
> > got sent back due to issues seen by others and I didn't have time to fi
On Tue, Sep 23, 2014 at 01:08:21AM +, Saha, Avik (AWS) wrote:
> I was wondering if there is way to use the rte_table_hash_lru without
> building a pipeline - Basically using the same hash table like functionality
> of add, delete and lookup without setting up a pipeline and connect it to
>
On Tue, Sep 23, 2014 at 03:43:59AM +, Saha, Avik (AWS) wrote:
> So with DPDK 1.7 there are 2 separate implementations - one is the rte_hash
> which does not support LRU (at least to my understanding - I could be wrong
> here) and then there is the librte_table library which has support for
in the DPDK code.
Matthew.
--
Sent from my mobile device.
On September 23, 2014 2:59:47 AM PDT, Bruce Richardson wrote:
>On Mon, Sep 22, 2014 at 03:12:43PM -0700, Matthew Hall wrote:
>> On Mon, Sep 22, 2014 at 04:05:29PM -0400, Neil Horman wrote:
>> > On Mon, Sep 22, 2014 a
On Tue, Sep 23, 2014 at 06:53:57PM +, Wang, Shawn wrote:
> Can someone share some light on what is magic of the dpdk Makefile to
> correctly register the NIC type?
I had the same problem as a guy who began using it before the auto-reg,
stopped a while, and began again after.
You have to
On Wed, Sep 24, 2014 at 01:10:32PM -0700, Malveeka Tewari wrote:
>
> There is already a rump-kernel based TCP/IP stack for DPDK
> https://github.com/rumpkernel/dpdk-rumptcpip/.
...
> But these solutions are again too heavy weight.
Try using this along with
On Thu, Sep 25, 2014 at 09:11:24AM -0700, Jeff Shaw wrote:
> Intel(R) Data Direct I/O Technology (Intel(R) DDIO) is a feature introduced
> with the Intel(R) Xeon(R) processor E5 family.
>
> It has been around for several years and is available at least on all Xeon
> E5 processors. DDIO is part
On Thu, Sep 25, 2014 at 07:27:21PM +, Anjali Kulkarni wrote:
> Actually, in the demo that I saw they had probably used as many of the
> accelerations as possible to get the kind of rates they described. Even if
> we could see (a documentation of) what all things they used in this
> particular
On Mon, Sep 29, 2014 at 10:23:58PM +0200, Thomas Monjalon wrote:
> - mbuf rework
> - logs rework
> - some eal cleanups
Hi Thomas,
I was curious, did we happen to know if any of these three changes affected
the external API's much?
It would help us get some idea what to test
On Tue, Sep 30, 2014 at 06:52:45AM +0200, Thomas Monjalon wrote:
> You're right.
> During integration time, app hackers should be able to check the git history
> for these API changes.
> When it will be officially released, there will be some notes in the
> documentation to help porting
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
On Mon, Apr 20, 2015 at 02:37:53PM +, Ravi Kumar Iyer wrote:
> We were doing some code optimizations , running DPDK based applications, and
> chanced upon the rte_rdtsc function [ to read tsc timestamp register value ]
> consuming cpu cycles of the order of 100clock cycles with a delta of
On Thu, Jan 22, 2015 at 01:32:04PM +0800, Linhaifeng wrote:
> Do you mean if call rte_memcpy before rte_eal_init() would crash?why?
No guarantee. But a theory. It might use some things from the EAL init to
figure out which version of the accelerated algorithm to use.
Matthew.
similar to mine, the more adoption of DPDK and
better DPDK community we will be able to have as time marches forward.
If we could manage to get it to work in VirtualBox, then I could surely help
do some app-level testing on the new code, if we could see it in a test branch
or test repo somewh
On Tue, Jan 27, 2015 at 03:42:00AM +, Wiles, Keith wrote:
> There is an app note on how to get DPDK working in VirtualBox, it is a bit
> bumpy on getting it work.
> Here is the link:
> http://plvision.eu/blog/deploying-intel-dpdk-in-oracle-virtualbox/
>
> I have not tried it, but it was
On Tue, Jan 27, 2015 at 10:02:24AM +, Stephen Hemminger wrote:
> On Mon, 26 Jan 2015 19:06:12 -0800
> Matthew Hall wrote:
>
> > Thank you so much for this, using virtio drivers in DPDK has been messy and
> > unpleasant in the past, and you clearly wrote a lot of nice
On Jun 29, 2015, at 3:19 AM, Thomas Monjalon
wrote:
> There is no such bug with my compiler:
> clang version 3.6.1 (tags/RELEASE_361/final)
> Target: x86_64-unknown-linux-gnu
>
> Matthew, which version are you using?
Hi Thomas and Roman,
It seems to happen if I have set -mavx in
To be a bit more specific, this is what I had to do to fix it for clang 3.6 SVN
snapshot release.
I am not sure if there is a better way of handling this situation. I'd love to
know where I could improve it.
Matthew.
diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
index f595cd0..8c883ee
0xf8,%P0" :: "i" (status) : "memory");
So there are definitely some corner cases that seem to be able to trigger it.
On Jun 30, 2015, at 10:17 PM, Matthew Hall wrote:
> To be a bit more specific, this is what I had to do to fix it for clang 3.6
> SVN snapshot re
Hello,
Based on the wonderful assistance from Vladimir and Stephen and a close friend
of mine that is a hypervisor developer who helped me reverse engineer and
rewrite rte_lpm_lookupx4, I have got a known-working version of rte_lpm4 with
expanded 24 bit next hop support available here:
Previously, with the -msse4.2 flag removed, the build failed for a different
reason.
I can retry without it and see if it's the case in the new DPDK.
On Jul 1, 2015, at 4:10 AM, Bruce Richardson
wrote:
> On Tue, Jun 30, 2015 at 10:49:26PM -0700, Matthew Hall wrote:
>> With those
On Jul 1, 2015, at 4:20 AM, Bruce Richardson
wrote:
> Could you maybe send a patch (or set) with all your changes in it here for us
> to look at? [I did look at it in github, but I'm not very familiar with github
> and the changes seem to be spread over a whole series of commits]
Here is a view
On Jul 2, 2015, at 4:20 AM, Dumitrescu, Cristian wrote:
> I am wondering how can I use the hash library if I don't know the number
> of entries in the bucket (number of entries in the bucket can grow
> dynamically)
> I am trying to use the DPDK hash library for MAC table where I can't give
> the
On Thu, Jul 02, 2015 at 05:55:20PM +, De Lara Guarch, Pablo wrote:
> You are probably talking about extendable buckets here.
> The downsize of that approach is that you have to allocate memory on the fly,
> whereas with the cuckoo hash implementation, the entry can be stored in an
>
Hello Venkat,
I'd like to ask one question about your project.
What did you do to make poll-mode drivers for WLAN controllers?
I didn't think DPDK had these by default and it could be quite nice for
high-speed protocols such as 802.11N.
Thanks,
Matthew.
On Jul 3, 2015, at 9:10 PM,
using DPDK only to process the tunneled wireless data packets from
> AP.
>
> We added a tunnel layer on top of the PMDs, to process the tunneled packets.
>
> Thanks
> Venkat
>
>
>
> On 5 July 2015 at 11:08, Matthew Hall wrote:
>
> > Hello Venkat,
&
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 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
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
>
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.
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:
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
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
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
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)
>
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
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
>
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
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 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
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
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
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
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
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.
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
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
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
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
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
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
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
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
on doing performance / production quality
improvements on my code, without some kind of basic help understanding
how this librte_power stuff should work.
Thanks,
Matthew.
On 12/5/15 4:08 PM, Matthew Hall wrote:
> Hello all,
>
> I wanted to ask some questions about librte_power and the great
/15 11:10 PM, Matthew Hall wrote:
> 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 i
On 1/3/16 9:09 AM, Wiles, Keith wrote:
> Pktgen is setup for tabs for 4 (with replace tabs with spaces), using tab
> stop of 8 is just wrong IMO :-)
> Just started using kdevelop instead of eclipse, so I may have corrupted the
> style some :-(
The problem I found was a number of files had an
When you go to this link:
http://dpdk.org/doc/guides/prog_guide/perf_opt_guidelines.html
There is a bug in the Sphinx layout, where the subchapters of a chapter are
invisible even after the chapter is clicked.
It is a pain when you are trying to figure out the different sections in a
widely
On Wed, Jan 13, 2016 at 11:34:33AM +, Bruce Richardson wrote:
> When the first example apps using this style of prefetch were originally
> written, yes, there was a noticable performance increase achieved by using
> the prefetch. Thereafter, I'm not sure that anyone has checked with each
>
On Tue, Jan 12, 2016 at 03:17:21PM +, Zhang, Helin wrote:
> Hi Matthew
>
> Yes, you have indicated out the key, the power management module has changed
> or upgraded.
> Could you help to try the legacy one to see if it still works, as indicated
> in your link?
I can do this, but according
On Thu, Jan 14, 2016 at 02:03:55AM -0500, Matthew Hall wrote:
> Yes, let me know how I could help. I don't know very much yet. My machine is
> Skylake Core i7-6700k. Unfortunately I think I am in trouble here, because
> there is no whitepaper on the Intel website for Intel Speed Shift t
On Thu, Jan 14, 2016 at 07:15:51AM +, Zhang, Helin wrote:
> That's disappointing if Skylake is like that. Let's have a learning first,
> and then check if we can fix that. But in addition, DPDK provide interrupt
> based packet receiving mechanism, can it be one of your choice?
Maybe I am
101 - 200 of 287 matches
Mail list logo
