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
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 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
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 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 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 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 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
> 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 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
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 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 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, 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 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 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 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 Mon, Aug 03, 2015 at 09:46:54AM +0800, Liang, Cunming wrote:
> According to the API definition, if the socket could not be determined, a
> default of zero will take.
> The '-1' is returned when the port_id value is out of range.
Yes, but when I asked the exact same question and was told the
I asked about this many months ago and was informed that "-1" is a "standard
error value" that I should expect from these APIs when NUMA is not present.
Now we're saying I have to change my code again to handle a zero value?
Also not sure how to tell the difference between no NUMA, something
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
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
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
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,
&
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,
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
>
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 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
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
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:
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
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
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
It would appear there is some bug in the new lock elision patches that is
preventing it from compiling with clang. Any suggestions?
On Jun 28, 2015, at 10:16 AM, Matthew Hall wrote:
> Hi all,
>
> I am getting a strange error compiling some RTM instructions when I upgraded
> my VM
Hi all,
I am getting a strange error compiling some RTM instructions when I upgraded my
VM environment from VirtualBox 4 to VirtualBox 5 and AVX instructions from the
host CPU became available. However when I am reading the opcode description for
XABORT it supposedly allows an immediate
Hi guys,
So I just finally fixed all the weird unit test failures for the basic-mode.
But the rte_lpm_lookupx4 will take quite a bit longer because it uses a lot of
real weird SSE intrinsic functions I never used before in my life.
However pretty soon I should get some kind of results how it
On Thu, Jun 25, 2015 at 09:13:59PM +, Vass, Sandor (Nokia - HU/Budapest)
wrote:
> Can anyone tell me the reason of this behavior? Using CPU 1 there are huge
> latencies, using other CPUs everything work as expected...
One possible guess what could be related. Normally DPDK uses "Core #0" as
On Thu, Jun 25, 2015 at 08:44:51PM +0200, Thomas Monjalon wrote:
> DPDK is not a stack.
Hi Thomas,
Don't worry too much about that challenge.
When I get my app feature complete, I think we can change that.
Same for Avi and they server frameworks they are making at Cloudius. ;)
Matthew.
On Thu, Jun 25, 2015 at 06:46:30PM +0300, Avi Kivity wrote:
> What would be useful is a runtime switch between polling and interrupt
> modes. This was if the load is load you use interrupts, and as mitigation,
> you switch to poll mode, until the load drops again.
Yes... I believe this is part
On Thu, Jun 25, 2015 at 09:14:53AM +, Vass, Sandor (Nokia - HU/Budapest)
wrote:
> According to my understanding each packet should go
> through BR as fast as possible, but it seems that the rte_eth_rx_burst
> retrieves packets only when there are at least 2 packets on the RX queue of
> the
On Wed, Jun 24, 2015 at 10:04:53AM +0300, Vladimir Medvedkin wrote:
> I published changes to rte_lpm_tbl24_entry only because it was just an idea
> :)
Understood. Just wanted to be sure I understood it right to convert it into C
code. :)
> different defines and checks should be modified too.
OK, I went and made a whole ton of patches to LPM and the tests and examples,
now the selftest errors out... but I think maybe I don't have an adequate
amount of hugepages. How much hugepage memory did people have when they did the
selftest successfully before?
I just keep seeing this over and
On Tue, Jun 23, 2015 at 09:13:14PM -0700, Matthew Hall wrote:
> Vladimir,
>
> One thing I was confused, you published the changes to rte_lpm_tbl24_entry
> but
> you didn't say what you did to change rte_lpm_tbl8_entry, as that one only
> had
> an 8-bit next_hop as well.
On Tue, Jun 23, 2015 at 10:19:58AM +0300, Vladimir Medvedkin wrote:
> Hi all,
>
> Matthew, I think ipv6 lpm code need less changes
> struct rte_lpm6_tbl_entry {
> uint32_t next_hop: 21; /**< Next hop / next table to be
> checked. */
> uint32_t depth :8; /**< Rule
On Mon, Jun 22, 2015 at 11:51:02PM -0400, Stephen Hemminger wrote:
> In order to make Vyatta/Brocade router work with LPM code
> I ended up redoing the layout. It is:
>
> And also several other scalability improvements (plus IPv6)
> and the correct handling of /32.
>
> Unfortunately, this is such
_));
> /* Using single uint8_t to store 3 values. */
> uint32_t valid :1; /**< Validation flag. */
> uint32_t ext_entry :1; /**< External entry. */
> uint32_t depth :6; /**< Rule depth. */
> };
> so we have 24 bit for next_hop.
&
On Jun 21, 2015, at 5:09 PM, Daeyoung Kim wrote:
> I am a newbie to DPDK.
Welcome!
> I'm making a packet capture program from the l3fwd
> sample application. When I tested my program in a virtual environment, it
> worked. But in a real world, it does not work correctly.
This topology is kind
Hello,
I have gone out on the internet for days looking at a bunch of different radix
tree implementations to see if I could figure a way to implement my own tree,
just to work around the really low 255 CIDR block limitation in librte_lpm.
Unfortunately every single one I could find falls into
On Jun 21, 2015, at 3:54 PM, Tom Barbette wrote:
> Application call to rte_eal_pci_probe() is not needed anymore since DPDK 1.8.
>
> http://dpdk.org/ml/archives/dev/2014-September/005890.html
>
> You were not wrong before, it is just a change in DPDK. I came across the
> same problem a few
On Jun 19, 2015, at 3:15 AM, Bruce Richardson
wrote:
> Thank you. It's finally nice to get some good news about compatibility! :-)
Hi Bruce,
I did manage to find just one weird issue when I was trying to use the new DPDK
v2.0.0. Previously I had code which was calling rte_eal_pci_probe()
On Thu, Jun 18, 2015 at 08:37:46PM -0700, Matthew Hall wrote:
> dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoning existing macro
> [-Werror]
Hi all,
I finally figured out what happened. My older DPDK build configuration file
had defined the poisoned macros to try to enable the fe
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:
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:
>
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.
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 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
On Mon, May 04, 2015 at 12:43:48PM +, Qiu, Michael wrote:
> What mail client do you use? I think mail client supporting thread mode
> is important for patch review.
Like many UNIX people, I use mutt.
My concern is that, if we're making the widespread adoption, usage, and
contributions for
On Fri, May 01, 2015 at 10:59:32PM +0300, Aaro Koskinen wrote:
> Projects like GCC, GLIBC, binutils, busybox, etc or what?
>
> A.
You'll notice all of these are low-level UNIX hacker sorts of tools mostly,
with the partial exception of busybox. But even that is mainly for embedded
use. It
On Fri, May 01, 2015 at 11:09:14AM -0700, Stephen Hemminger wrote:
> With email, the patches are right in front of developers and easier to quote
> for review comments.
Right in front of that subset of developers who do everything kernel-style,
perhaps yes. But this sort of workflow is in the
On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
> Yes, but as you said above, using a web browser doesn't make reviewing patches
> faster. In fact, I would assert that it slows the process down, as it
> prevents
> quick, easy command line access to patch review (as you have with a
On Apr 25, 2015, at 5:10 AM, Neil Horman wrote:
> I'm more focused on why that level of participation is not higher
Hi Neal,
This mail is probably way too long, but here is what I saw about participation,
in my case I used DPDK on two projects so far:
1) proprietary project for a L4-L7
On Apr 27, 2015, at 3:28 PM, Paul Emmerich wrote:
> Let me know if you need any additional information.
> I'd also be interested in the configuration that resulted in the 20% speed-
> up that was mentioned in the original mbuf patch
Not sure if it's relevant or not, but there was another mail
Stephen,
This mail is a bit confusing for end users of DPDK which might be why you
didn't get many replies yet.
If I understand this mail right, you're saying that nothing works? Or it works,
but igb_uio doesn't work, and the performance isn't good because MSI-X is not
working? I am confused
On Fri, Apr 24, 2015 at 12:39:47PM -0500, Jay Rolette wrote:
> I can tell you that if DPDK were GPL-based, my company wouldn't be using
> it. I suspect we wouldn't be the only ones...
>
> Jay
I could second this, from the past employer where I used it. Right now I am
using it in an open source
On Wed, Apr 22, 2015 at 03:57:44PM -0700, Stephen Hemminger wrote:
> Since it possible to have multiple DPDK applications in same environment,
> and the thread name size is so limited, I wonder if this is a good idea.
Why not try to opportunistically make the code easier to debug? DPDK is not
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 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 Sat, Mar 28, 2015 at 12:10:20PM +0300, Vladimir Medvedkin wrote:
> I just verify RSS symmetric in my code, all works great.
> ...
> By the way, maybe it will be usefull to add softrss function in DPDK?
Vladimir,
All of this is super-awesome code. I agree having SW RSS would be quite nice.
On Fri, Mar 27, 2015 at 05:03:02PM -0700, Stephen Hemminger wrote:
> I would argue remove rte_rand from DPDK.
+1
To paraphrase Donald Knuth, "Random numbers should not be generated [using a
function coded] at random."
It'd be better to fix libc, or considering that has a slow dev cycle and
On Mar 26, 2015, at 10:30 PM, Zhang, Helin wrote:
> Hi guys
>
> Did you guys talk about symmetric hash in software or in hardware?
>
> If about hardware, I have one comment.
> I40e supports symmetric hash by hardware, which was enabled in i40e PMD
> recently. You can have a try.
>
> Regards,
On Mon, Mar 23, 2015 at 05:18:49PM +0100, Thomas Monjalon wrote:
> Don't you think adding a bug tracker would artificially split discussions
> between mailing list threads and bug tracker entries?
It is difficult to track the workflow around bugs without some kind of
bug-friendly workflow tool.
On Mon, Mar 23, 2015 at 04:20:33PM +0100, Thomas Monjalon wrote:
> 2015-03-23 10:05, Matt Laswell:
> > Hey Folks,
> >
> > I have essentially the same question as Matthew. Has there been progress
> > in this area?
>
> No, AFAIK.
> Submitting a patch would be a good start I think.
Hi Thomas,
We
On Mon, Mar 23, 2015 at 05:19:00PM +0200, Dor Green wrote:
> I changed it to free and it still happens. Note that the segmentation fault
> happens before that anyway.
>
> I am using 1.7.1 at the moment. I can try using a newer version.
I'm using 1.7.X in my open-source DPDK-based app and it
On Wed, Mar 18, 2015 at 06:41:05PM +, Naveen Gamini wrote:
> When I tried to install dpdk on Amazon AWS ubuntu based linux, I see uio
> module error. Can anyone help me to how to load uio module on ubuntu linux
> so that IGB UIO module.
Amazon Cloud Images usually include minimized kernel
A few months ago we had this thread about symmetric hashing of TCP in RSS:
http://dpdk.org/ml/archives/dev/2014-December/010148.html
I was wondering if we ever did figure out how to get the 0x6d5a hash key
mentioned in there to work, or another alternative one.
Thanks,
Matthew.
On Mon, Feb 23, 2015 at 11:51:46PM +0200, Avi Kivity wrote:
> https://github.com/cloudius-systems/seastar
Hi Avi and others,
My code unintentionally ended up looking somewhat like a C version of your
seastar C++ code, even though I didn't really look at yours too much when I
coded mine as it
On Mon, Feb 23, 2015 at 08:48:57AM -0600, Matt Laswell wrote:
> Apologies in advance for likely being a bit long-winded.
Long winded is great, helps me get context.
> First, you really need to take cache performance into account when you're
> choosing a data structure. Something like a balanced
On Feb 22, 2015, at 4:02 PM, Stephen Hemminger
wrote:
> Use userspace RCU? or BSD RB_TREE
Thanks Stephen,
I think the RB_TREE stuff is single threaded mostly.
But user-space RCU looks quite good indeed, I didn't know somebody ported it
out of the kernel. I'll check it out.
Matthew.
Hello fellow stack hackers :) ,
I'm working on a simple server-side implementation of TCP on DPDK.
For this to work I need a good data structure to store some sockets.
The lookup key is like this:
struct ss_flow_key_s {
uint8_t sip[IPV6_ALEN];
uint8_t dip[IPV6_ALEN];
uint16_t
On Feb 17, 2015, at 1:30 AM, Thomas Monjalon
wrote:
> Yes, you're right. It has been renamed.
> But I think you should better work on improving the HEAD ;)
Yes, I agree. But to get to this point I have to get the core application
features to even work in 1.7, before I can switch the app to
On Feb 12, 2015, at 1:29 AM, Thomas Monjalon
wrote:
> Yes you can: make doc
> For doxygen API only: make doc-api-html
> For sphinx only: doc-guides-html.
Hi Thomas,
In 1.7 for me at least I found the target was called: doc-htmlapi .
Did the way this stuff works get changed at some point?
On Mon, Feb 16, 2015 at 10:33:52AM -0600, Jay Rolette wrote:
> In kni_net_rx_normal(), it was calling netif_receive_skb() instead of
> netif_rx(). The source for netif_receive_skb() point out that it should
> only be called from soft-irq context, which isn't the case for KNI.
For the uninitiated
I did some research on this previously before concluding NDPI wouldn't help me
much with my own particular application.
Just for running NDPI DPDK is not strictly needed, as NDPI is normally
read-only so something like PF_RING would work in default ntop / ndpi. If
you're trying to use NDPI in
Hi all,
I ran into a funny situation today with the API documentation.
For stability until I can get my app mostly working, I was using DPDK 1.7.X,
so I could concentrate on making the app reliable. But the DPDK website only
has the API docs for DPDK 1.8.X / HEAD.
I was wondering if we could
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 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
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 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.
On Fri, Jan 16, 2015 at 04:14:38PM -0500, Neil Horman wrote:
> Sure, Its a bit orthogonal to this conversation, but I think its a fine idea
> to
> have if it aids in general reviewing. Thomas can it be setup on dpdk.org?
>
> Neil
Admittedly I'm not a PMD expert to comment on all the specifics
On Fri, Jan 16, 2015 at 03:00:57PM -0500, Neil Horman wrote:
> Like Gerrit:
> https://code.google.com/p/gerrit/
Maybe we could work on setting up a community copy? I'd prefer if we could
avoid n=1 and make our community as strong as possible.
Matthew.
On Fri, Jan 16, 2015 at 07:18:19PM +0100, Thomas Monjalon wrote:
> I'd like to try solving the review challenge first and see what else can be
> done after that. Step by step.
FWIW, I know the kernel guys seem to really love it, but not everybody else
has much fun trying to do the reviews
On Thu, Jan 15, 2015 at 09:55:00PM +, O'driscoll, Tim wrote:
> As you said, there's a balance to be struck, and too many subtrees may
> become unmanageable. With respect to your concern about developers having to
> potentially develop patches against multiple subtrees, this has never been
>
On Mon, Jan 05, 2015 at 09:25:37PM -0800, Matthew Hall wrote:
> The same computation algorithm must be reused to calculate the IPV6
> Pseudoheader checksum when generating ICMPV6, UDPV6, and other L4 protocols
> whose definitions were retroactively modified to include the IPV6
>
On Mon, Jan 05, 2015 at 09:36:54AM +0100, Thomas Monjalon wrote:
> Which checksum are you talking about? IPv6 checsum doesn't exist.
The same computation algorithm must be reused to calculate the IPV6
Pseudoheader checksum when generating ICMPV6, UDPV6, and other L4 protocols
whose definitions
On Jan 4, 2015, at 11:56 PM, Gal Sagie wrote:
> I noticed that in version 1.8, there are no flags to indicate IPv6 check
> sum offloading
> (only DEV_TX_OFFLOAD_IPV4_CKSUM)
> which means TSO offloading is also not supported for IPv6.
I need that feature too. Right now I disabled the IP checksum
On Tue, Dec 09, 2014 at 10:33:59AM -0600, Matt Laswell wrote:
> Our DPDK application deals with very large in memory data structures, and
> can potentially use tens or even hundreds of gigabytes of hugepage memory.
What you're doing is an unusual use case and this is open source code where
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, 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, 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)
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,
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
>really w
101 - 200 of 287 matches
Mail list logo
