From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id DE0DD2B8C for ; Thu, 29 Sep 2016 09:20:35 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 29 Sep 2016 00:20:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,414,1470726000"; d="scan'208";a="1063831374" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 29 Sep 2016 00:20:29 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 29 Sep 2016 00:20:28 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 29 Sep 2016 00:20:28 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.118]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.101]) with mapi id 14.03.0248.002; Thu, 29 Sep 2016 15:20:26 +0800 From: "Xu, HuilongX" To: "Liu, Yong" , "dts@dpdk.org" Thread-Topic: [dts] [PATCH V1] fix lpm ipv6 unit case on 1G hugepage machine Thread-Index: AQHSGh0s3UZ9K6/jb0+cJDnMxTcxBaCQDutQ Date: Thu, 29 Sep 2016 07:20:25 +0000 Message-ID: References: <1474435711-23476-1-git-send-email-huilongx.xu@intel.com> <57ECB941.7030107@intel.com> In-Reply-To: <57ECB941.7030107@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dts] [PATCH V1] fix lpm ipv6 unit case on 1G hugepage machine X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 07:20:36 -0000 Yes, Set hugepage will failed in FreeBSD, but not influence the case exec in Fre= eBSD. I think maybe we can rework hugepage config on dts framework next time. Thanks a lot =20 > -----Original Message----- > From: Liu, Yong > Sent: Thursday, September 29, 2016 2:49 PM > To: Xu, HuilongX; dts@dpdk.org > Subject: Re: [dts] [PATCH V1] fix lpm ipv6 unit case on 1G hugepage > machine >=20 >=20 >=20 > On 09/21/2016 01:28 PM, xu,huilong wrote: > > Signed-off-by: xu,huilong > > --- > > tests/TestSuite_unit_tests_lpm.py | 15 ++++++++++----- > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > diff --git a/tests/TestSuite_unit_tests_lpm.py > b/tests/TestSuite_unit_tests_lpm.py > > index dadb492..7394d19 100644 > > --- a/tests/TestSuite_unit_tests_lpm.py > > +++ b/tests/TestSuite_unit_tests_lpm.py > > @@ -83,11 +83,16 @@ class TestUnitTestsLpmIpv6(TestCase): > > """ > > [arch, machine, env, toolchain] =3D self.target.split('-') > > self.verify(arch =3D=3D "x86_64", "lpm6 request huge memory") > > - > > - hugepage_ori =3D self.dut.get_total_huge_pages() > > - self.dut.set_huge_pages(4096) > > - hugepage_num =3D self.dut.get_total_huge_pages() > > - self.verify(hugepage_num >=3D 4096, "failed to request huge > memory") > > + # lpm ipv6 should leaest 8g huge page > > + min_hugepagesz =3D 8 * 1024 * 1024 > > + > > + hugepage_ori =3D int(self.dut.get_total_huge_pages()) > > + hugepages_size =3D int(self.dut.send_expect("awk > '/Hugepagesize/ {print $2}' /proc/meminfo", "# ")) > > + > This command can't work on FreeBSD. Again, it's better to let framework > handle huge allocation/destroy. > It's hard to each suite handle the difference for distributions. >=20 > > + if (hugepages_size * hugepage_ori < min_hugepagesz): > > + self.dut.set_huge_pages(min_hugepagesz / hugepages_size) > > + hugepage_num =3D self.dut.get_total_huge_pages() > > + self.verify(hugepage_num =3D=3D min_hugepagesz / > hugepages_size, "failed to request huge memory") > > > > self.dut.send_expect("./app/test/test -n 1 -c ffff", > "R.*T.*E.*>.*>", 60) > > out =3D self.dut.send_expect("lpm6_autotest", "RTE>>", 3600)