From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by dpdk.org (Postfix) with ESMTP id B84917E23 for ; Fri, 10 Apr 2015 07:08:52 +0200 (CEST) Received: by iedfl3 with SMTP id fl3so10533008ied.1 for ; Thu, 09 Apr 2015 22:08:52 -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=bCJFh53i0FnzMoxahWe3/NHyrzx+TjhgoDg4hKQTm3Y=; b=M6Xs1Pub59OVl77zTrx8I5trDPODGj8gMlyuNsDEnLM1vB0N5FWfLF3rPisHKaq3TB qKBrma+94MSdDdXcCkCpbJ3tdMxEdjE81df62Qaktm50HOFzg0a6Ua7McPmRrCUKNh5q UsGpnZX+dR4g7qssRKFykhP0wJsFXmDn6YA6Tv8CVQfuLbh8BlRv8TO5Lc18nfKl4DNF W7X9zMr1hkVkfLx0wsZcaSKNC0R+ZL7AiTCWLiJ6NIIfLGAiaWaj2q+MXxoE7ANAAa7m 678Xy5R58++SuwTcdmR/XiY89mu9QxvoO2mr0rmB2mo/F7Ly3KWaVsuiF1jEYCt9S5gG zW9g== MIME-Version: 1.0 X-Received: by 10.50.66.37 with SMTP id c5mr1452181igt.26.1428642532048; Thu, 09 Apr 2015 22:08:52 -0700 (PDT) Received: by 10.107.39.199 with HTTP; Thu, 9 Apr 2015 22:08:51 -0700 (PDT) In-Reply-To: <2601191342CEEE43887BDE71AB97725821414AC6@irsmsx105.ger.corp.intel.com> References: <20150407143522.GA10054@hmsreliant.think-freely.org> <20150408114736.GB22959@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB97725821414AC6@irsmsx105.ger.corp.intel.com> Date: Fri, 10 Apr 2015 10:38:51 +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 05:08:53 -0000 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 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 ?? () > > > > > > > > > > > > > > > > > > > > > >