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
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 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 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
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
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 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: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 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 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 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 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 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 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, 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
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
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
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
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
>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 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:
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.
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
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
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
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
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
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
> 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
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:
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
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
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 made
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
On Mon, Jan 25, 2016 at 10:20:42AM +0100, Andriy Berestovskyy wrote:
> Hi Matthew,
> Every software has bugs. pktgen is a great tool and we appreciate it as is.
>
> I would prefer we discuss a patch rather that questioning a
> functionality implemented way ago...
>
> Andriy
Sure patches are the
On Thu, Jan 21, 2016 at 05:35:00PM +0200, Arnon Warshavsky wrote:
> Keith,
> For the record, on my end (can only speak for myself) this is not a real
> problem.
> I work around it by using a different theme and live with it happily ever
> after.
> I just provided the input since I encountered it.
On Thu, Jan 21, 2016 at 03:46:21PM +, Wiles, Keith wrote:
> It appears (if I compared the text correctly) the above only move a few
> trailing words to the next line, why?
I believe in trying to leave code / docs cleaner than I found them.
Most Markdown / ReStructured Text has a tradition
On Fri, Jan 22, 2016 at 06:02:24PM +0300, Igor Ryzhov wrote:
> How about exposing stats according to IF-MIB?
>
> Statistics to be exposed are - octets, unicast packets, multicast packets,
> broadcast packets, errors and discards for both TX and RX.
>
> These counters are basic and implemented
On Thu, Jan 21, 2016 at 07:44:21PM +, Wiles, Keith wrote:
> What type of data do you want to add to the packets? Now it builds
> IPv4/UDP/TCP packets, do you need to replace UDP or TCP or just add more
> protocol layers?
I perform content inspection of various types:
IPv4 - supported
IPv6
On Thu, Jan 21, 2016 at 11:00:14AM -0800, Stephen Hemminger wrote:
> I would rip out the whole tty control and theming nonsense and then
> just print one line copyright on startup.
Personally, I might have put this sentiment more diplomatically, but a
refactor effort such as this would make life
On Thu, Jan 21, 2016 at 03:01:33PM +, Wiles, Keith wrote:
> The problem is you used the same core (2) for the -m option. Core 2 is being
> used for the keyboard, timer and screen output. This means you must have the
> -m option starting with core 3 as in -m 3.0 and your problem should go
On Thu, Jan 21, 2016 at 03:05:38PM +, Wiles, Keith wrote:
> Forgot to answer this one. Pktgen does not allow the user to define the
> content of the packet per say only the fill pattern and what ever you
> configure the packet type to be. If you would like to submit a patch for
> adding
On 1/20/16 10:14 PM, Qiu, Michael wrote:
> As we could start up many primaries, how does your secondary process
> work with them?
I just worked on this tonight myself. When doing > 1 primary (for
example pktgen and app), I had to specify:
--no-shconf
--file-prefix pktgen
--file-prefix app
Or
Hello,
I was trying to just use the default PKT file, test/set_seq.pkt, like so:
sudo "./app/app/${RTE_TARGET}/pktgen" \
-l 2,3 \
--master-lcore 2 \
-n 2 \
-m 1024 \
-w 0a:00.1 \
--no-shconf \
--file-prefix pktgen \
-- \
-P \
-m 2.0 \
-f test/set_seq.pkt
After pktgen loaded, the port 0 is
On 1/20/16 10:00 PM, Arnon Warshavsky wrote:
> Black background gets me to the blind reset as well.
> Pktgen is the only tab I keep with non black background..
Thanks for confirming. Never had this many termio issues before so I was
wondering if I just went totally crazy!
Matthew.
If I try using pktgen theme mode (-T) or unmodified, without commenting
out some of the stuff I mentioned I disabled for debugging in the
previous thread, it seems like it sets the pktgen prompt to be invisible
(black text on black??? or I'm not sure just want) on my TTY which has a
black
Signed-off-by: Matthew Hall
---
docs/source/usage_pktgen.rst | 15 +++
1 file changed, 15 insertions(+)
diff --git a/docs/source/usage_pktgen.rst b/docs/source/usage_pktgen.rst
index efe8aa4..223d033 100644
--- a/docs/source/usage_pktgen.rst
+++ b/docs/source/usage_pktgen.rst
Signed-off-by: Matthew Hall
---
docs/source/usage_pktgen.rst | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/docs/source/usage_pktgen.rst b/docs/source/usage_pktgen.rst
index 20bd314..efe8aa4 100644
--- a/docs/source/usage_pktgen.rst
+++ b/docs/source
On 1/20/16 7:27 AM, Thomas Monjalon wrote:
> Hi Matthew,
>
> RTE_SDK_BIN is an internal variable and should not be overriden.
>
> Have you installed DPDK somewhere? Example:
> make install O=mybuild DESTDIR=mylocalinstall
>
> Then you should build your app like this:
> make
On 1/20/16 8:26 AM, Wiles, Keith wrote:
> One problem is a number of people wanted to steal the code and use in a paid
> application, so the copyright is some what a requirement. As you may know I
> do a lot of debugging on Pktgen and I feel they are a nuisance. I can try to
> see if we can
Hello,
I was just reading the following blog post about downscaling community
involvement at the Linux Foundation.
http://mjg59.dreamwidth.org/39546.html
I wondered if any of issues discussed there this might be relevant for
the governance efforts moving forward on DPDK?
Sincerely,
Matthew.
re you forced to set TX_WTHRESH by hand for igb?
What sane default value one should pick for this setting?
Could we do something better to auto-select this like we did for most
rx_conf / tx_conf settings previously? Or did I miss something about the
usability changes or do something wrong?
Since
c_socket(buff,
(sizeof(pkt_seq_t) * NUM_TOTAL_PKTS),
RTE_CACHE_LINE_SIZE,
rte_socket_id());
Thoughts?
Matthew Hall
, etc. as Patchwork seems rather
old and difficult to use from my experience with it so far.
Sincerely,
Matthew.
On 1/19/16 9:20 PM, Matthew Hall wrote:
> I have some outstanding minor patches which do not appear in Patchwork
> anywhere I can see but the interface is also pretty con
Currently pktgen-dpdk and many other external apps will fail to compile
if the build output directory name is not equal to the target name.
This causes problems if you used an alternative build output directory.
Signed-off-by: Matthew Hall
---
mk/internal/rte.extvars.mk | 2 +-
1 file changed
I have some outstanding minor patches which do not appear in Patchwork
anywhere I can see but the interface is also pretty confusing.
Is there a way to find all patches by a person throughout time so I can
see what happened to them and check why they are not listed and also not
merged (that I
On Fri, Jan 15, 2016 at 04:54:11PM +, Zoltan Kiss wrote:
> Can you call rte_eth_tx_burst() and rte_eth_tx_burst() on the same port at
> the same time from different threads?
In general, yes you can. I did this before in an L4-L7 performance tester, so
cores could concentrate on RX or TX to
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
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 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 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
>
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 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
/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 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
On Mon, Dec 21, 2015 at 04:17:26PM +, Gray, Mark D wrote:
> Is tcpdump used in large production cloud environments? I would have
> thought other less intrusive (and less manual) tools would be used? Isn't
> that one of the benefits of SDN.
tcpdump, tshark, wireshark, libpcap, etc. have been
On Wed, Dec 16, 2015 at 11:56:11AM +, Bruce Richardson wrote:
> Having this work with any application is one of our primary targets here.
> The app author should not have to worry too much about getting basic debug
> support. Even if it doesn't work at 40G small packet rates, you can get a
> an integer value indicating how many bytes of the packet should be mirrored
> by the capturing application. +1 to Matthew Hall for taking this direction!
Yes, performance wise I think this is the only way that will really work 100%
of the time. Otherwise I think we end up in the very bad
On Wed, Dec 02, 2015 at 12:35:16PM +, Bruce Richardson wrote:
> Hi Matthew,
>
> thanks for the info, but I'm not sure I understand it correctly. It seems to
> me that you are mostly referring to the depths/sizes of the tables being used,
> rather than to the "data-size" being stored in each
On Wed, Dec 02, 2015 at 01:38:07AM +, Wiles, Keith wrote:
> In Pktgen I used tap interface to wireshark and that worked very nicely the
> only problem is it was slow :-(
>
> Having a tap PMD would be nice to be able to remove that code from Pktgen.
All these approaches we discussed so far
On Tue, Dec 01, 2015 at 09:45:56AM -0500, Kyle Larose wrote:
> Earlier Stephen mentioned using the named pipe behaviour of tcpdump.
> Is there an opportunity to take what you have mentioned here and marry
> it to the named pipe output to get the perf you need?
I am wondering about the same thing.
On Tue, Dec 01, 2015 at 01:16:47PM +, O'Driscoll, Tim wrote:
> True. The goal is to merge the best of the various patches that were
> submitted on this. This could involve changes to IPv6 as well as IPv4.
>
>
> Tim
If it's possible to fix IPv6 as well this would be good for me. Offering a
On Tue, Dec 01, 2015 at 11:58:16AM +, Bruce Richardson wrote:
> Hi,
>
> that is indeed very similar to what we are thinking ourselves. Is there any of
> what you have already done that you could contribute publically to save us
> duplicating some of your effort? [The one big difference, is
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 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 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 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.
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 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
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 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.
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 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 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 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: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: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 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: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: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
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
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/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/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 | 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/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
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 | 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
1 - 100 of 287 matches
Mail list logo
