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
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
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
, 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
c_socket(buff,
(sizeof(pkt_seq_t) * NUM_TOTAL_PKTS),
RTE_CACHE_LINE_SIZE,
rte_socket_id());
Thoughts?
Matthew Hall
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
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.
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
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
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
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
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
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.
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: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
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 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 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 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 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 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 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 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
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 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
>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 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 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 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
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 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
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
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
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
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:
On Thu, Nov 06, 2014 at 10:24:11AM +0800, GongJinrong wrote:
> Hi, Guys
>
> When I run virtio-net-pmd in VM, I got "virtio-net device is already
> used by another driver" error message, after I removed the virtio-net.ko, it
> worked, but now I cannot use the virio-net driver for another
On Fri, Nov 07, 2014 at 01:22:49AM +0100, Marc Sune wrote:
> Found some time to have a close look. I also wanted to check a DPDK app
> against valgrind. It works!
>
> I downloaded and compiled valgrind from sources (3.10.0) and applied
> (manually) this patch:
>
>
On Thu, Oct 02, 2014 at 10:43:52AM +0900, Tetsuya Mukawa wrote:
> I haven't known the options. Thanks.
> Anyway, I understand I shouldn't change link order, but should check why
> '--start-group/--end-group' doesn't work on my environment.
> I will describe more in the email for Thomas.
>
>
On Thu, Oct 02, 2014 at 04:56:24PM +0100, Sergio Gonzalez Monroy wrote:
> When RTE_BUILD_COMBINE_LIBS=y is configured, there won't be individual shared
> libraries to copy over.
As a user of RTE_BUILD_COMBINE_LIBS, disabling the ability to use the
individual libs after the option is enabled is
On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> Just out of curiosity, whats the impetus behind a single shared library here?
> Is it just to ease application linking operations? If so, it almost seems to
> me
> that we should abandon the individual linking method and just use
On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote:
> This seems somewhat irrelevant to the patch. The default configuration is
> already the way you want it to be, shared library performance is actually very
> close to static performance, and yes, people can choose how they want to
>
On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote:
> We need to simplify build options. So I'm fine to remove COMBINE_LIBS option
> to always enable it.
> About making only one single static library, I think it's a good idea if
> it brings a real code simplification.
>
> So the
On Fri, Oct 03, 2014 at 10:27:30AM +0200, Thomas Monjalon wrote:
> The proposal is to always build single (combined) lib AND to build separated
> libs in case of shared libraries.
> For static library: only one single (combined) static library.
In the static case, this won't be backward
On Fri, Oct 03, 2014 at 07:32:34AM -0400, Neil Horman wrote:
> This makes good sense to me. A single archive is just easier in the static
> case, since the resulting binary will strip out unused code anyway, and
> multiple
> libraries are needed in the shared case so that we don't wind up
On Fri, Oct 03, 2014 at 03:15:46PM -0400, Neil Horman wrote:
> With a single archive, you get everything you build even if you don't need
> it.
Right, I was trying to avoid that for people who specifically didn't want it,
if there are any... I'm not one of them.
> But presumably if you're
Hi Guys,
I'm doing my development on kind of a cheap machine with no NUMA support...
but several years ago I used DPDK to build a NUMA box that could do 40 gbits
bidirectional L4-L7 stateful traffic replay.
So given the past experiences I had before, I wanted to clean the code up so
it'd work
On Mon, Oct 06, 2014 at 11:52:34AM +0100, Sergio Gonzalez Monroy wrote:
> Remove COMBINE_LIBS option and by default build:
> - CONFIG_RTE_BUILD_SHARED_LIB=y : both individual and combined libraries
> - CONFIG_RTE_BUILD_SHARED_LIB=n : single combined library
As previously discussed.,It would be
On Tue, Oct 07, 2014 at 10:55:11AM +0100, Sergio Gonzalez Monroy wrote:
> I don't see how this particular patch would force people to change their code,
> though in all likelihood they will have to as a result of ABI changes in the
> following release.
>
> The only difference now would be when
On Wed, Oct 08, 2014 at 06:55:41PM -0400, Neil Horman wrote:
> I think because there is a possibility that multiple workers may be used for
> a
> single tx queue.
>
> Neil
OK, so, in my application packets are RX'ed to a predictable RX queue and core
using RSS.
Then you put them into a
If the DPDK wants to conflict with all those system headers it means they also
have to provide working replacement for inet_pton, inet_ntop, and every other
important socket function which depends upon in.h or depends upon code
depending upon in.h. Clearly this doesn't represent a sustainable
On Thu, Oct 09, 2014 at 10:14:21AM +0100, Bruce Richardson wrote:
> Hi Matthew,
>
> What you are doing will indeed work, and it's the way the vast majority of
> the sample apps are written. However, this will not always work for everyone
> else, sadly.
>
> First off, with RSS, there are a
On Thu, Oct 09, 2014 at 12:09:42PM -0400, Neil Horman wrote:
> From what you've said above, sequence assignment needs to occur prior to any
> order breaking event. That means you either need to do it in individual PMD's
> on RX, or in the rte_eth library if you want to make it common. On the TX
On Sun, Oct 12, 2014 at 12:37:37PM +, Yan Freedland wrote:
> Every ~2min traffic stopped completely and then immediately came back. This
> happened in a periodic fashion.
To me it sounds like it could be similar to what I've seen when I ran out of
mbuf's or ran out of RX / TX descriptor
Hello,
I was working to get my open source project running in a VirtualBox Vagrant VM
powered by an Ubuntu Cloud image the last few days to make my project and DPDK
more developer friendly with a prebuilt environment. During this I was fixing
the ugly hardcodings I'd used to hack it together
on single
socket, dual socket non-NUMA, and dual socket NUMA boxes.
Thanks,
Matthew.
On Mon, Oct 06, 2014 at 02:13:44AM -0700, Matthew Hall wrote:
> Hi Guys,
>
> I'm doing my development on kind of a cheap machine with no NUMA support...
> but several years ago I used DPDK to buil
od' in
/usr/lib/x86_64-linux-gnu/libc_nonshared.a(mknod.oS) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
Did anybody ever see something this before?
Thanks,
Matthew.
On Mon, Oct 13, 2014 at 10:45:23PM -0700, Matthew Hall wrote:
> Hello,
>
> I was working to get my op
On Mon, Oct 13, 2014 at 11:03:53PM -0700, Matthew Hall wrote:
> Another weird issue... when I tried to compile a DPDK shared lib using clang
> I
> got this really, really weird error:
>
> /usr/bin/ld: test: hidden symbol `mknod' in
> /usr/lib/x86_64-linux-gnu/libc_no
Hello,
Having worked around the previously reported bizarre linker issues, I can now
see this new error:
PMD: virtio_dev_start(): RSS cannot be configured for VirtI/O net devices
If I want to ensure that the flows are sent consistently to the same core on
virtio-net to prevent surprises, what
Signed-off-by: Matthew Hall
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index e69de29..08d831a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+librte_pmd_virtio.so
--
1.9.1
right.
Matthew.
--
Sent from my mobile device.
On October 14, 2014 1:22:56 AM PDT, "Gonzalez Monroy, Sergio"
wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
>> Sent: Tuesday, October 14, 2014 7:34 AM
Richardson wrote:
>On Tue, Oct 14, 2014 at 07:53:56AM +0000, Matthew Hall wrote:
>> Signed-off-by: Matthew Hall
>> ---
>> .gitignore | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index e69de29..08d831a 1
100
>Bruce Richardson wrote:
>
>> On Tue, Oct 14, 2014 at 07:53:56AM +0000, Matthew Hall wrote:
>> > Signed-off-by: Matthew Hall
>> > ---
>> > .gitignore | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > di
In the virtio-net-pmd it is done in the same directory. Hence me submitting
this to try to make it easier for others to use the product.
Also the default DPDK doesn't ignore the build target directories... but I
already had to fork that one to fix clang compile failures in the examples
files.
On Wed, Oct 15, 2014 at 04:46:41PM -0400, daniel chapiesky wrote:
> At time 4:30, he mentioned the "shock to the system" of developers
> expecting a pat on the back and instead receiving critiques of their
> code.
>
> I realized that I was one of those who failed to acknowledge the incredible
On Fri, Oct 17, 2014 at 09:44:49AM +, Pattan, Reshma wrote:
> [Reshma]: Library just takes care of packets what it has got. No waiting
> mechanism is used for missing packets.
> [Reshma]: This is dependent upon how frequently packets are enqueued and
> dequeued from it. Packets which are in
On Fri, Oct 17, 2014 at 10:14:50PM -0400, Kamraan Nasim wrote:
> I have a DPI daemon running in userspace which uses libpcap for packet RX
> that I would like to replace with DPDK ethernet PMD. However it is not
> feasible to convert the entire application to run within the DPDK framework
> which
Hello,
I'm just trying to understand what you're supposed to do about this error to
get the optiomal configuration / performance. The error message and comments
seem like they're designed for Intel ethernet driver hackers not security
hackers like myself! ;-)
Note: I'm trying out the Intel
1.7.1 with a few minor clang compatibility patches in the example apps
--
Sent from my mobile device.
On October 19, 2014 6:46:27 AM PDT, Marc Sune wrote:
>Which DPDK version are you using
>
>marc
>
>On 19/10/14 00:50, Matthew Hall wrote:
>> Hello,
>>
>> I
On Mon, Oct 20, 2014 at 10:36:01AM +0100, Bruce Richardson wrote:
> On Sun, Oct 19, 2014 at 10:08:29AM -0700, Matthew Hall wrote:
> > 1.7.1 with a few minor clang compatibility patches in the example apps
>
> Rather than trying to tune the results yourself, maybe you could l
On Tue, Oct 21, 2014 at 11:28:47AM +0200, Thomas Monjalon wrote:
> But I care about the message brought by such change. It would mean that
> we can break the development branch and that most of developers don't test
> it nor base their patches on the latest commit. It's all about simple rules
>
On Tue, Oct 21, 2014 at 01:22:27PM +, Gonzalez Monroy, Sergio wrote:
> As you point out below, when building static DPDK we should not expect ldd
> to report any DPDK dependency. When building shared DPDK libs, we should
> expect such dependency expect for the fact that we are not linking
, Stephen Hemminger wrote:
>On Wed, 22 Oct 2014 00:00:58 -0700
>Matthew Hall wrote:
>
>> What I think git in general and DPDK in particular are missing is,
>they have a
>> tradition tags for releases, however I think this is broken because
>you can't
>> easily append mo
On Wed, Oct 22, 2014 at 03:20:40PM +, Gonzalez Monroy, Sergio wrote:
> You are not forced to use shared libraries. This module loads successfully
> with an app (testpmd) built against static DPDK libs.
It sounds like it just requires additional options as mentioned later in your
mail. We
On Wed, Oct 22, 2014 at 01:48:36PM +, O'driscoll, Tim wrote:
> Single Virtio Driver: Merge existing Virtio drivers into a single
> implementation, incorporating the best features from each of the existing
> drivers.
Tim,
There is a lot of good stuff in there.
Specifically, in the
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,
>
> Did an
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 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
201 - 287 of 287 matches
Mail list logo
