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

Venkat Thummala venkat.thummala.1978 at gmail.com
Fri Apr 10 11:02:05 CEST 2015
Previous message: [dpdk-dev] Running DPDK Binaries on a different Target
Next message: [dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
The issue is with my application logic, which calculates the SIP/DIP MASK
values.
I am using "__builtin_ctz(x)" to calculate the SIP/DIP MASK.

mask = 32 - __builtin_ctz(value).

If the value is ZERO, the outcome is undefined.

In my case, we are hitting the UNDEFINED case here.

On 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 <venkat.thummala.1978 at gmail.com>
wrote:

> Hi Konstantin,
>
> Thanks a lot for looking in to this.
>
> In my case, I am using the ACL Pipeline Infra [My application logic is
> built on the ACL pipeline].
> After your mail, I did verify the same with "l3fwd-acl" example, it just
> worked fine.
> Seems like, the issue is observed only with the Pipeline implementation.
> Currently, I am debugging this, will update you once I have more info on
> this.
> Any known issues with the Pipeline implementation?
>
> Regards
> Venkat
>
>
>
> On 9 April 2015 at 17:07, Ananyev, Konstantin <
> konstantin.ananyev at intel.com> wrote:
>
>>
>> Hi Venkat,
>>
>> > -----Original Message-----
>> > 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 ACL rule configured in the ACL Table.
>> >
>> > Priority - 20
>> > SIP - 0
>> > SIP MASK - 0
>> > DIP - 0
>> > DIP MASK - 0
>> > PROTO - 17 [UDP]
>> > PROTO MASK - 0xFF
>> > SPORT - 0
>> > SPORT RANGE - 0xFFFF
>> > DPORT - 0
>> > DPORT RANGE - 0xFFFF
>> >
>> > And pumping UDP traffic.
>> >
>> > On Machine 1, it always HITS the rule as expected.
>> >
>> > But On Machine 2, the same traffic never HITS the rule.
>> >
>> > I have tried this with both SCALAR and SSE classification algorithms,
>> but
>> > the result is same.
>>
>> So did I get it right:
>> You build a binary with RTE_MACHINE="default" on a box with AVX2 support.
>> Then run that binary on
>> a) native box (machine with AVX2 support)
>> b) machine without AVX2 support
>>
>> For the same input and same rules, same binary you got different results
>> for a) and b).
>> If that is the case, then there is something wrong here, either within
>> our code or with the compiler you are using.
>> Could you provide steps to reproduce it?
>> I did a quick test with l3fwd-acl for that case, 'default' binary that I
>> built on HSW board,
>> works as expected on IVB box for me.
>>
>> Build box: HSW (E3-1285), gcc 4.8.3
>> SUT: IVB 2.80GHz, gcc 4.8.2
>>
>> # cat acl_ipv4.rule1
>> R0.0.0.0/0 0.0.0.0/0 0 : 0xffff 0 : 0xffff 17/0xff 0
>> # cat acl_ipv6.rule1
>> R0:0:0:0:0:0:0:0/0 0:0:0:0:0:0:0:0/0 0 : 0xffff 0 : 0xffff 17/0xff 0
>>
>> ./dpdk.org-acl/examples/l3fwd-acl/x86_64-default-linuxapp-gcc/l3fwd-acl
>> --lcores=3 -n 4 --socket-mem=1024,0 -w 0000:04:00.1 -- -p 1 --config "(0,
>> 0, 3)" --rule_ipv4=./acl_ipv4.rule1 --rule_ipv6=acl_ipv6.rule1 -P
>>
>> Forwards UDP packets, drops all others.
>>
>> Anything else in your setup, that I am missing here?
>>
>> Konstantin
>>
>> >
>> > Could some one, please help me on this?
>> >
>> > DPDK Version:
>> > ===========
>> > 2.0
>> >
>> > Machine 1 CPU INFO:
>> > ================
>> > vendor_id    : GenuineIntel
>> > cpu family    : 6
>> > model        : 69
>> > model name    : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
>> > stepping    : 1
>> > microcode    : 0x16
>> > cpu MHz        : 759.000
>> > cache size    : 3072 KB
>> > physical id    : 0
>> > siblings    : 4
>> > core id        : 1
>> > cpu cores    : 2
>> > apicid        : 3
>> > initial apicid    : 3
>> > fpu        : yes
>> > fpu_exception    : yes
>> > cpuid level    : 13
>> > wp        : yes
>> > flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
>> > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
>> nx
>> > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
>> > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
>> > ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe
>> popcnt
>> > tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb
>> > xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
>> > tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
>> > bogomips    : 4589.70
>> > clflush size    : 64
>> > cache_alignment    : 64
>> > address sizes    : 39 bits physical, 48 bits virtual
>> > power management:
>> >
>> > MACHINE 1 OS:
>> > =============
>> > Linux vthummala-HP-Pavilion-15-Notebook-PC 3.13.0-48-generic #80-Ubuntu
>> SMP
>> > Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > MACHINE 2 CPU INFO:
>> > ==================
>> > vendor_id    : GenuineIntel
>> > cpu family    : 6
>> > model        : 62
>> > model name    : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
>> > stepping    : 4
>> > microcode    : 0x416
>> > cpu MHz        : 2599.890
>> > cache size    : 20480 KB
>> > physical id    : 1
>> > siblings    : 16
>> > core id        : 7
>> > cpu cores    : 8
>> > apicid        : 47
>> > initial apicid    : 47
>> > fpu        : yes
>> > fpu_exception    : yes
>> > cpuid level    : 13
>> > wp        : yes
>> > flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
>> > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
>> nx
>> > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
>> > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
>> > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2
>> x2apic
>> > popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat
>> > xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
>> smep
>> > erms
>> > bogomips    : 5201.35
>> > clflush size    : 64
>> > cache_alignment    : 64
>> > address sizes    : 46 bits physical, 48 bits virtual
>> > power management:
>> >
>> > MACHINE 2 OS:
>> > =============
>> > 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
>> >
>> >
>> > On 8 April 2015 at 17:17, Neil Horman <nhorman at tuxdriver.com> 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 to "default".
>> > > >
>> > > Default is the lowest common demoninator system that dpdk supports
>> (core2
>> > > duo).
>> > > So if you're system is superior to that processor, you're ok.
>> > >
>> > > > Though, this fixed the CRASH issue, I am observing inconsistent
>> behavior
>> > > > with ACL tables.
>> > > >
>> > > > With the same traffic and same ACL rule, on ONE machine the ACL
>> rule is
>> > > > being HIT, where as on the OTHER machine the rule never HITS.
>> > > >
>> > > > Is this because of the "default" machine option?
>> > > >
>> > > Possibly, the machine type changes the method of lookup for ACL rules,
>> > > though it
>> > > should remain consistent in terms of which rules are hit.
>> > > > Regards
>> > > > Venkat
>> > > >
>> > > >
>> > > > On 7 April 2015 at 20:05, Neil Horman <nhorman at tuxdriver.com>
>> wrote:
>> > > >
>> > > > > On Tue, Apr 07, 2015 at 05:30:15PM +0530, Venkat Thummala wrote:
>> > > > > > Attaching the CPU Info.
>> > > > > >
>> > > > > > On 7 April 2015 at 17:28, Venkat Thummala <
>> > > > > venkat.thummala.1978 at gmail.com>
>> > > > > > 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 CRASH with the following back trace.
>> > > > > > >
>> > > > > > > Please find the CPU info of the machines from the attachment.
>> > > > > > >
>> > > > > > > cpuinfo-1 - Native Machine
>> > > > > > > cpuinfo-2 - Non Native Machine
>> > > > > > >
>> > > > > > > Could someone please help me in understanding the issue here
>> and
>> > > > > making it
>> > > > > > > work?
>> > > > > > >
>> > > > > > > Regards
>> > > > > > > Venkat
>> > > > > > >
>> > > > > > > Program terminated with signal SIGILL, Illegal instruction.
>> > > > > > > #0  0x00000000004209f2 in rte_cpu_get_flag_enabled
>> > > (feature=2147483656,
>> > > > > > > feature at entry=RTE_CPUFLAG_EM64T)
>> > > > > > >     at
>> > > > > > >
>> > > > >
>> > >
>> /home/vthummala/src/vwlc/dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_cpuflags.h:303
>> > > > > > > 303        return (regs[feat->reg] >> feat->bit) & 1;
>> > > > >
>> > > > > Looks like this somehow compiled into an instruction that the
>> native
>> > > system
>> > > > > understands but the system you're running on doesn't.
>> disassemble the
>> > > > > code here
>> > > > > to see what instruction that is to confirm, then you either need
>> to:
>> > > > >
>> > > > > 1) Change the machine you're compiling for to be more specific to
>> your
>> > > > > target
>> > > > > system
>> > > > >
>> > > > > or
>> > > > >
>> > > > > 2) Understand that the hardware you're targeting doesn't support
>> dpdk
>> > > > >
>> > > > > Neil
>> > > > >
>> > > > > > > (gdb) bt
>> > > > > > > #0  0x00000000004209f2 in rte_cpu_get_flag_enabled
>> > > (feature=2147483656,
>> > > > > > > feature at entry=RTE_CPUFLAG_EM64T)
>> > > > > > >     at
>> > > > > > >
>> > > > >
>> > >
>> /home/vthummala/src/vwlc/dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_cpuflags.h:303
>> > > > > > > #1  0x0000000000420a1b in rte_hash_crc_set_alg (alg=6 '\006')
>> > > > > > >     at
>> > > > > > >
>> > > > >
>> > >
>> /home/vthummala/src/vwlc/dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:429
>> > > > > > > #2  rte_hash_crc_init_alg () at
>> > > > > > >
>> > > > >
>> > >
>> /home/vthummala/src/vwlc/dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:445
>> > > > > > > #3  0x000000000054968d in __libc_csu_init ()
>> > > > > > > #4  0x00007fc3ca474e55 in group_nodes_into_DFAstates
>> > > > > > > (dests_ch=0x940f507ab10ff0c8, dests_node=0x4a8b44de74c084c0,
>> > > > > > > state=0x4420528b48a8ebc9,
>> > > > > > >     dfa=<optimized out>) at regexec.c:3614
>> > > > > > > #5  build_trtable (dfa=0x840fc139c0014468,
>> > > state=0x4420528b48a8ebc9) at
>> > > > > > > regexec.c:3354
>> > > > > > > #6  0x41d589495541f689 in ?? ()
>> > > > > > > #7  0x00251630258d4c54 in ?? ()
>> > > > > > > #8  0x002517302d8d4855 in ?? ()
>> > > > > > > #9  0xc148db31e5294c53 in ?? ()
>> > > > > > > #10 0x65e808ec834803fd in ?? ()
>> > > > > > > #11 0x1e74ed8548ffed48 in ?? ()
>> > > > > > > #12 0x0000000000841f0f in ?? ()
>> > > > > > >
>> > > > > >
>> > > > >
>> > >
>>
>
>
Previous message: [dpdk-dev] Running DPDK Binaries on a different Target
Next message: [dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the dev mailing list