[dpdk-dev] KNI interface is not coming up

Hi Robert, Thanks a lot, it fixed the issue. Regards Venkat On 30 April 2015 at 20:11, Sanford, Robert wrote: > Hi Venkat, > > Perhaps your DPDK application needs to slow-poll KNI devices via > rte_kni_handle_request( ). > > http://dpdk.org/doc/api/rte__kni_8h.html > > -- > Regards, > Robert >

[dpdk-dev] KNI interface is not coming up

Hi, I am testing DPDK 2.0 release. I am not able to bring the KNI interface up. It always gives the following error. SIOCSIFFLAGS: Timer expired This is on Ubuntu, Linux vthummala-PowerEdge-R720 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Please

[dpdk-dev] Running DPDK Binaries on a different Target

MACHINE 1, __builtin_ctz(0) is returning 32, So, it works. On MACHINE 2, __builtin_ctz(0) is returning 0, So, it fails. Regards Venkat On 10 April 2015 at 10:38, Venkat Thummala wrote: > Hi Konstantin, > > Thanks a lot for looking in to this. > > In my case, I am using t

[dpdk-dev] Running DPDK Binaries on a different Target

; From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Venkat Thummala > > Sent: Thursday, April 09, 2015 10:07 AM > > To: Neil Horman > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] Running DPDK Binaries on a different Target > > > > I have the following

[dpdk-dev] Running DPDK Binaries on a different Target

2014 x86_64 x86_64 x86_64 GNU/Linux On 8 April 2015 at 17:17, Neil Horman wrote: > On Wed, Apr 08, 2015 at 02:03:05PM +0530, Venkat Thummala wrote: > > Hi Neil, > > > > Thanks for the quick response. > > > > The issue got fixed by setting CONFIG_RTE_MACHINE t

[dpdk-dev] Running DPDK Binaries on a different Target

as on the OTHER machine the rule never HITS. Is this because of the "default" machine option? Regards Venkat On 7 April 2015 at 20:05, Neil Horman wrote: > On Tue, Apr 07, 2015 at 05:30:15PM +0530, Venkat Thummala wrote: > > Attaching the CPU Info. > > > >

[dpdk-dev] Running DPDK Binaries on a different Target

Attaching the CPU Info. On 7 April 2015 at 17:28, Venkat Thummala wrote: > Hi, > > I have built a DPDK application [based on version 2.0] and run on the > native machine successfully. > > I have tried running the binary on a different machine, but it resulted in > a CRA

[dpdk-dev] Running DPDK Binaries on a different Target

Hi, I have built a DPDK application [based on version 2.0] and run on the native machine successfully. I have tried running the binary on a different machine, but it resulted in a CRASH with the following back trace. Please find the CPU info of the machines from the attachment. cpuinfo-1 - Nati

[dpdk-dev] sharing rte_malloc() address between processes.

rfere with this mapping, so it may be necessary to disable this feature in order to reliably run multi-process applications. Thanks Venkat On 10 June 2014 17:59, Venkat Thummala wrote: > Hi, > > Yo > > ? The multi-process feature requires that the exact same hugepage memory >

[dpdk-dev] sharing rte_malloc() address between processes.

Hi, Yo ? The multi-process feature requires that the exact same hugepage memory mappings be present in all applications. The Linux security feature - Address-Space Layout Randomization (ASLR) can interfere with this mapping, so it may be necessary to disable this feature in order to reliably run

[dpdk-dev] using hash table in a MP environment

Hi Shirley, Please refer the section 20.3 [Multi-Process Limitations] in DPDK Programmers Guide. The use of function pointers between multiple processes running based of different compiled binaries is not supported, since the location of a given function in one process may be different to its loc

[dpdk-dev] L2 FWD / L3 FWD performance with Rx and Tx ports on different sockets

Hi, I guess, the current L2 FWD / L3 FWD performance numbers are observed with both Rx and Tx ports connected to the same Socket. Does anyone have the performance numbers with Rx and Tx ports on two different sockets? How does DDIO come in to picture in this case? I believe DDIO comes in to pict