From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by dpdk.org (Postfix) with ESMTP id A4E4FC310 for ; Fri, 10 Apr 2015 11:02:06 +0200 (CEST) Received: by igbqf9 with SMTP id qf9so12388597igb.1 for ; Fri, 10 Apr 2015 02:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GAmy8fUUYv4eB9ltF0KPDP2CwiwHL5/Y7QnHFKEgJeQ=; b=CxE3njwojR4sYKwRmVJEhSTnQgpO2qdznIIXVWJn2Upos7Ia4JoErT8ZemHboSfGIR Xe0F2ZbA8rp9dr00vpRlJkLzK/qqInTmxmd2JfILX+tpoMS3+ByI2BC7jKuAy9evwg8A vIs876AzoCoSaJWAhr8IQbjxzTy1cw7MkdhBFoKnk8pjW781h/1T3eO0UrhzQgMa+RZ5 twZI+kSyQnni8gXh/+lBy3A3i4zuvfyR/AxASebxDCVLG6ZxQVWBiZo1ey3xSADEzrm0 MCMNj7v3piO7UYgUxUt2RbjE9I1WEIba8JV9xp8gjnlxeD4/rg+P8F4IWKVLI5zSFLtU wTUQ== MIME-Version: 1.0 X-Received: by 10.107.170.135 with SMTP id g7mr922802ioj.2.1428656526016; Fri, 10 Apr 2015 02:02:06 -0700 (PDT) Received: by 10.107.39.199 with HTTP; Fri, 10 Apr 2015 02:02:05 -0700 (PDT) In-Reply-To: References: <20150407143522.GA10054@hmsreliant.think-freely.org> <20150408114736.GB22959@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB97725821414AC6@irsmsx105.ger.corp.intel.com> Date: Fri, 10 Apr 2015 14:32:05 +0530 Message-ID: From: Venkat Thummala To: "Ananyev, Konstantin" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Running DPDK Binaries on a different Target X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 09:02:07 -0000 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 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@intel.com> wrote: > >> >> Hi Venkat, >> >> > -----Original Message----- >> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Venkat Thummala >> > Sent: Thursday, April 09, 2015 10:07 AM >> > To: Neil Horman >> > Cc: dev@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 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 >> 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@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@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@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=) 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 ?? () >> > > > > > > >> > > > > > >> > > > > >> > > >> > >