From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by dpdk.org (Postfix) with ESMTP id 68EB32E89 for ; Wed, 6 Aug 2014 14:21:06 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 06 Aug 2014 05:23:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,811,1400050800"; d="scan'208";a="465581000" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by azsmga001.ch.intel.com with ESMTP; 06 Aug 2014 05:23:30 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.240]) by IRSMSX104.ger.corp.intel.com ([163.33.3.159]) with mapi id 14.03.0195.001; Wed, 6 Aug 2014 13:23:30 +0100 From: "Ananyev, Konstantin" To: Neil Horman Thread-Topic: [PATCH] acl: If build does not support sse4.2, emulate missing instructions with C code Thread-Index: AQHPr/nfSvxellfhhkCY1e7bjysdIJvCBOJwgAA+TICAAQY+8IAAJTWAgAARyTA= Date: Wed, 6 Aug 2014 12:23:29 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772582134FCB4@IRSMSX105.ger.corp.intel.com> References: <1407166558-9532-1-git-send-email-nhorman@tuxdriver.com> <2601191342CEEE43887BDE71AB9772582134F98D@IRSMSX105.ger.corp.intel.com> <20140805182035.GB20550@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB9772582134FC52@IRSMSX105.ger.corp.intel.com> <20140806121221.GA26562@localhost.localdomain> In-Reply-To: <20140806121221.GA26562@localhost.localdomain> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] acl: If build does not support sse4.2, emulate missing instructions with C code 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: Wed, 06 Aug 2014 12:21:07 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Wednesday, August 06, 2014 1:12 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org; Thomas Monjalon; Richardson, Bruce > Subject: Re: [PATCH] acl: If build does not support sse4.2, emulate missi= ng instructions with C code >=20 > On Wed, Aug 06, 2014 at 10:52:09AM +0000, Ananyev, Konstantin wrote: > > > > > > For ACL there is a simple UT, that could be run as: > > > > ./x86_64-native-linuxapp-gcc/app/test ... > > > > RTE>>acl_autotest > > > > It takes just few seconds to run. > > > > > > It doesn't seem to work properly, at least not on any of my systems. = With a > > > system allocation 100 pages to hugepage memory: > > > > > > [root@hmsreliant app]# ./test -c 0x3 -n 2 > > > EAL: Detected lcore 0 as core 0 on socket 0 > > > EAL: Detected lcore 1 as core 1 on socket 0 > > > EAL: Detected lcore 2 as core 2 on socket 0 > > > EAL: Detected lcore 3 as core 3 on socket 0 > > > EAL: Detected lcore 4 as core 0 on socket 0 > > > EAL: Detected lcore 5 as core 1 on socket 0 > > > EAL: Detected lcore 6 as core 2 on socket 0 > > > EAL: Detected lcore 7 as core 3 on socket 0 > > > EAL: Support maximum 64 logical core(s) by configuration. > > > EAL: Detected 8 lcore(s) > > > EAL: cannot open VFIO container, error 2 (No such file or directory= ) > > > EAL: VFIO support could not be initialized > > > EAL: Setting up memory... > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7fef07000000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7fef06c00000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x400000 bytes > > > EAL: Virtual area found at 0x7fef06600000 (size =3D 0x400000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7fef06200000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7fef05e00000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x600000 bytes > > > EAL: Virtual area found at 0x7fef05600000 (size =3D 0x600000) > > > EAL: Ask a virtual area of 0x600000 bytes > > > EAL: Virtual area found at 0x7fef04e00000 (size =3D 0x600000) > > > EAL: Ask a virtual area of 0x800000 bytes > > > EAL: Virtual area found at 0x7fef04400000 (size =3D 0x800000) > > > EAL: Ask a virtual area of 0x400000 bytes > > > EAL: Virtual area found at 0x7fef03e00000 (size =3D 0x400000) > > > EAL: Ask a virtual area of 0xa00000 bytes > > > EAL: Virtual area found at 0x7fef03200000 (size =3D 0xa00000) > > > EAL: Ask a virtual area of 0x400000 bytes > > > EAL: Virtual area found at 0x7fef02c00000 (size =3D 0x400000) > > > EAL: Ask a virtual area of 0x400000 bytes > > > EAL: Virtual area found at 0x7fef02600000 (size =3D 0x400000) > > > EAL: Ask a virtual area of 0x1800000 bytes > > > EAL: Virtual area found at 0x7fef00c00000 (size =3D 0x1800000) > > > EAL: Ask a virtual area of 0x1200000 bytes > > > EAL: Virtual area found at 0x7feeff800000 (size =3D 0x1200000) > > > EAL: Ask a virtual area of 0x2600000 bytes > > > EAL: Virtual area found at 0x7feefd000000 (size =3D 0x2600000) > > > EAL: Ask a virtual area of 0xc00000 bytes > > > EAL: Virtual area found at 0x7feefc200000 (size =3D 0xc00000) > > > EAL: Ask a virtual area of 0x2200000 bytes > > > EAL: Virtual area found at 0x7feef9e00000 (size =3D 0x2200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7feef9a00000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7feef9600000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7feef9200000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7feef8e00000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7feef8a00000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7feef8600000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x200000 bytes > > > EAL: Virtual area found at 0x7feef8200000 (size =3D 0x200000) > > > EAL: Ask a virtual area of 0x600000 bytes > > > EAL: Virtual area found at 0x7feef7a00000 (size =3D 0x600000) > > > EAL: Requesting 100 pages of size 2MB from socket 0 > > > EAL: TSC frequency is ~3392297 KHz > > > EAL: Master core 0 is ready (tid=3D73cf880) > > > EAL: Core 1 is ready (tid=3Df71fe700) > > > APP: HPET is not enabled, using TSC as default timer > > > RTE>>acl_autotest > > > ACL: allocation of 25166720 bytes on socket 9 for ACL_acl_ctx failed > > > > > > This hangs forever (well, at least 30 minutes, but thats sufficiently > > > close to forever for me to wait). > > > > > > > Ok that's unusual. > > Never seen before. > > I suppose that happens with unmodified dpdk 1.7? > If I build unmodified dpdk 1.7 (which I can only build for the native pla= tform), > it works, however it doesn't work when built with modifications for the d= efault > platform, but see below. >=20 > > I do run acl_autotest with at least 256M of huge-pages as ACL is quite = memory consuming and, as I remember, requires at least > 2X32M areas of contiguous hugepages. > > But in that case (not enough hugepages) it should just fail with someth= ing like: > > ACL: allocation of 25953152 bytes on socket -1 for ACL_acl_ctx failed > > Any other details, so I can try to reproduce it: > > arch you build/run it on? > x86_64 default build (has to be to test the new code). >=20 > > amount of free memory in the system? > Its an 8G workstation, should have most of that free (haven't checked yet= ). That's should be enough. I run it on 8GB workstation with ~3GB reported as 'free' by linux. >=20 > > Wonder what pstack says? > It says that we're stuck in the eal library, before we've touched the ACL > library it seems, so I'm not sure whats going on here: > #0 0x0000003d11ef53c3 in epoll_wait () from /lib64/libc.so.6 > #1 0x00000000004d315a in eal_intr_thread_main () > #2 0x0000003d12607f33 in start_thread () from /lib64/libpthread.so.0 > #3 0x0000003d11ef4ded in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fee73ffe700 (LWP 14529)): > #0 0x0000003d1260e87d in read () from /lib64/libpthread.so.0 > #1 0x00000000004ced0a in eal_thread_loop () > #2 0x0000003d12607f33 in start_thread () from /lib64/libpthread.so.0 > #3 0x0000003d11ef4ded in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fee84100880 (LWP 14527)): > #0 0x000000000041adde in acl_match_check_x2.constprop () > #1 0x000000000041b1af in search_sse_2 () > #2 0x00000000004baab9 in rte_acl_classify () > #3 0x000000000047d12d in test_acl () > #4 0x000000000041c535 in cmd_autotest_parsed () > #5 0x00000000004d8503 in cmdline_parse () > #6 0x00000000004d7600 in cmdline_valid_buffer () > #7 0x00000000004da43a in rdline_char_in () > #8 0x00000000004d7809 in cmdline_interact () > #9 0x000000000041bccb in main () Ok, seems that we are in the indefinite loop. Probably here: acl_match_check_x2=20 { ... while (!MM_TESTZ(temp, temp)) {..} } =20 Did I get it right, that it works ok with x86_64-default-linuxapp-gcc binar= y, but hangs with modified x86_64-default-linuxapp-gcc? If yes, then I wonder what modifications you made? Konstantin