Hello
I am working with KNI and I can send packets in both directions. But there are
a couple of things that I don?t know how to do:
- I have read in the documentation that the MAC address can be the real one.
But I am getting always a random one. I am setting the addr and id fields in
the str
24/02/2014 08:05, Chris Wright :
> * Thomas Monjalon (thomas.monjalon at 6wind.com) wrote:
> > In order to distinguish clearly this implementation from the extension
> > virtio-net-pmd, it is renamed to reflect its usage of uio framework.
> >
> > Signed-off-by: Thomas Monjalon
>
> Also simple pr
24/02/2014 08:03, Chris Wright :
> * Thomas Monjalon (thomas.monjalon at 6wind.com) wrote:
> > In order to make this tool available among other system commands,
> > the name must be more specific.
> >
> > Signed-off-by: Thomas Monjalon
>
> Looks reasonable to rename since it's not a generic scri
Hi,
20/03/2014 12:39, Neil Horman :
> On Thu, Mar 20, 2014 at 08:53:50AM -0700, H. Peter Anvin wrote:
> > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > clobbered when the code was compiled PIC or PIE, because the
> > i386-specific code to preserve %ebx was incorrectly co
Hi,
03/03/2014 23:45, Meir Tseitlin :
> I also think it should be handled somehow by default, because Ubuntu is not
> an esoteric distro. Why not patching it as well?
This issue should have disappeared after this commit:
http://dpdk.org/browse/dpdk/commit/?id=2a315d698510e7b33a7c9516ef532dbcd44c0
Hi,
I have some minor comments below.
27/02/2014 09:18, Stephen Hemminger :
> The function rte_snprintf() can never be inlined by Gcc.
> If compiled with -Winline it generates an error:
> function ?rte_snprintf? can never be inlined because it uses variable
> argument lists [-Werror=inline]
>
>
28/02/2014 09:21, David Marchand :
> Rebase commit 57c24af85d9eaa81549a212169605b4e2468a29f introduced a build
> regression for 32bits system.
The commit log of the rebased commit was also wrong for branch 1.6.0.
So I've reverted the rebased commit and did a new one.
It's better now.
Thank you fo
28/02/2014 09:21, David Marchand :
> RTE_PTR_ALIGN_CEIL return type is the same as what we give it as input.
> So instead of casting the returned value, cast 'addr' which should be the
> same as base_virtaddr.
>
> Reported-by: Mats Liljegren
> Signed-off-by: David Marchand
Acked and applied wit
On Thu, Mar 20, 2014 at 02:04:43PM -0400, Neil Horman wrote:
> On Thu, Mar 20, 2014 at 12:39:21PM -0400, Neil Horman wrote:
> > On Thu, Mar 20, 2014 at 08:53:50AM -0700, H. Peter Anvin wrote:
> > > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > > clobbered when the code wa
On Thu, Mar 20, 2014 at 12:39:21PM -0400, Neil Horman wrote:
> On Thu, Mar 20, 2014 at 08:53:50AM -0700, H. Peter Anvin wrote:
> > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > clobbered when the code was compiled PIC or PIE, because the
> > i386-specific code to preserve
On Thu, Mar 20, 2014 at 09:44:28AM -0700, H. Peter Anvin wrote:
> Neil Horman reported that on x86-64 the upper half of %rbx would get
> clobbered when the code was compiled PIC or PIE, because the
> i386-specific code to preserve %ebx was incorrectly compiled.
>
> However, the code is really way
On Thu, Mar 20, 2014 at 08:53:50AM -0700, H. Peter Anvin wrote:
> Neil Horman reported that on x86-64 the upper half of %rbx would get
> clobbered when the code was compiled PIC or PIE, because the
> i386-specific code to preserve %ebx was incorrectly compiled.
>
> However, the code is really way
Found the Problem. Few packet buffers were not being freed which lead to slow
leak of mbufs.
~Neeraj
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of ext Jain, Neeraj 3. (NSN -
IN/Bangalore)
Sent: Thursday, March 20, 2014 2:42 PM
To: dev at dpdk.org
Subject: [dpd
I just realized there is yet another oddity in this code:
> @@ -78,8 +69,10 @@ struct cpuid_parameters_t {
> struct feature_entry {
> enum rte_cpu_flag_t feature;/**< feature name */
The structure contains a field with an enum value...
> char name[CPU_FLAG_NAME_MAX_LEN];
Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.
However, the code is really way more complex than it needs to be. For
one thing, the CPUID instruction on
Hi,
I am currently running few trials with DPDK sample application for one of my
project requirements. Below are the system details under which the sample
application (L2 Forward) is being run.
Platform: Linux 2.6.32-358.17.1.el6.x86_64
VMWare: ESXI 5.1
Driver: vmxnet3-usermap
L2 FWD program is
On 03/20/2014 04:27 AM, Neil Horman wrote:
>>
> So, I answered my own question, sort of. The __i386__ is clear: x86_64 uses
> RIP
> relative addressing, making the saving of ebx not needed - thats perfectly
> clear.
>
> Whats a bit less clear to me is why it matters. Ideally moving ebx and
> re
x86_64 doesn't need to save off and restore ebx when issuing cpuid, since x86_64
uses RIP relative addressing. Doing the save actually clobbers the lower half
of rbx, which could be used and not saved off independently, leading to
undefined behavior. Fix up the defines so that for x86_64 we just
On Thu, Mar 20, 2014 at 07:03:23AM -0400, Neil Horman wrote:
> On Wed, Mar 19, 2014 at 09:22:03PM -0700, H. Peter Anvin wrote:
> > On 03/19/2014 05:40 PM, Neil Horman wrote:
> > > So after some discussion with hpa, I need to self NAK this again,
> > > apologies for
> > > the noise. Theres some cl
On Wed, Mar 19, 2014 at 09:22:03PM -0700, H. Peter Anvin wrote:
> On 03/19/2014 05:40 PM, Neil Horman wrote:
> > So after some discussion with hpa, I need to self NAK this again, apologies
> > for
> > the noise. Theres some clean up to be done in this area, and I'm still
> > getting
> > a segfau
20 matches
Mail list logo
