From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout4.w1.samsung.com (mailout4.w1.samsung.com [210.118.77.14]) by dpdk.org (Postfix) with ESMTP id 131445583 for ; Wed, 21 Jun 2017 12:37:04 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0ORW00CBJ85QUM60@mailout4.w1.samsung.com> for dev@dpdk.org; Wed, 21 Jun 2017 11:37:02 +0100 (BST) Received: from eusmges4.samsung.com (unknown [203.254.199.244]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20170621103702eucas1p24e06c5e2a60c4c32bce7fe5437d61cd4~KHLyDFBfU3053830538eucas1p2q; Wed, 21 Jun 2017 10:37:02 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges4.samsung.com (EUCPMTA) with SMTP id B3.CB.04729.D4C4A495; Wed, 21 Jun 2017 11:37:01 +0100 (BST) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20170621103701eucas1p246de92012a06b329f8e01b3fe6b6ffd4~KHLxWFpzG2084020840eucas1p2L; Wed, 21 Jun 2017 10:37:01 +0000 (GMT) X-AuditID: cbfec7f4-f79806d000001279-67-594a4c4d8fd5 Received: from eusync1.samsung.com ( [203.254.199.211]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 8C.CF.20206.D4C4A495; Wed, 21 Jun 2017 11:37:01 +0100 (BST) Received: from [106.109.129.180] by eusync1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0ORW007RR85N4HB0@eusync1.samsung.com>; Wed, 21 Jun 2017 11:37:00 +0100 (BST) To: Jerin Jacob , Thomas Monjalon Cc: Sergio Gonzalez Monroy , Hemant Agrawal , dev@dpdk.org, Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei From: Ilya Maximets Message-id: <4786d356-963d-cb1e-72cc-da154265a1d3@samsung.com> Date: Wed, 21 Jun 2017 13:36:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-version: 1.0 In-reply-to: <20170621102939.GA27670@jerin> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKsWRmVeSWpSXmKPExsWy7djPc7q+Pl6RBjc361vcWGVvsaKjncXi 3aftTBbTPt9mt1j5eCObxZX2n+wWEyeZWHTP/sJmcav5JJvFiglHGC0+PTjBYtGyZCeTxbcH 35kdeD0u9t9h9Nhwop/V49eCpaweN/7dYvNYvOclk8exm9PYPTa+28Hk0bdlFaPHle+rGQM4 o7hsUlJzMstSi/TtErgyPt05yFLQp1Dx6l07ewPjR6kuRk4OCQETied7VrBB2GISF+6tB7K5 OIQEljJKbDh9lRXC+cwo8aHhJDNMx+9Vh9khEssYJaZteAzV8oJRYsq5x6wgVcICNhILZ75m BLFFBCIltr5fzwJSxCwwiVniwZ8b7CAJNgEdiVOrj4AV8QrYSWxZsgVsBYuAqsSG12fBbFGB CInrc7ZA1QhK/Jh8jwXE5hTQlrg1fyHY4cwCBhIzphxmgrDlJTavecsMskxC4CO7xKHLL4Aa OIAcWYlNB6BecJHYMvsoK4QtLPHq+BZ2CFtG4vLkbhaI3mZGiYZVlxghnAmMEl+alzNBVNlL nLp5FWobn8SkbdOZIRbwSnS0CUGUeEhc+HoRapmjxLt1UxkhQdTHJPFpxnnWCYzys5A8NAvJ E7OQPLGAkXkVo0hqaXFuemqxiV5xYm5xaV66XnJ+7iZGYOI6/e/4lx2Mi49ZHWIU4GBU4uGN UPaMFGJNLCuuzD3EKMHBrCTCe9rZK1KINyWxsiq1KD++qDQntfgQozQHi5I4L9epaxFCAumJ JanZqakFqUUwWSYOTqkGRu5MwQo/3aeZbt2Ha/38Dh0s+HR/9y/vMIPVVv3M+w+ssF56lina tMi5LnjJxfTnzdJ1geGTlggK+29SORTb3hMcHyhnEit8+vXuX0qm+7488b36VPX/6cnfct76 Hb9jKBSXXFBvHFFUa69p++v87z1TtqVN/hnZ2P03QCo2bL1yiG7c5rfMSizFGYmGWsxFxYkA 3/17PFgDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsVy+t/xy7q+Pl6RBh/vMVrcWGVvsaKjncXi 3aftTBbTPt9mt1j5eCObxZX2n+wWEyeZWHTP/sJmcav5JJvFiglHGC0+PTjBYtGyZCeTxbcH 35kdeD0u9t9h9Nhwop/V49eCpaweN/7dYvNYvOclk8exm9PYPTa+28Hk0bdlFaPHle+rGQM4 o9xsMlITU1KLFFLzkvNTMvPSbZVCQ9x0LZQU8hJzU22VInR9Q4KUFMoSc0qBPCMDNODgHOAe rKRvl+CW8enOQZaCPoWKV+/a2RsYP0p1MXJySAiYSPxedZgdwhaTuHBvPVsXIxeHkMASRol/ 759AOS8YJY63fAarEhawkVg48zUjiC0iECmxdPtVJoiiPiaJsx+fMYM4zAJTmCVu7prPBFLF JqAjcWr1EbAOXgE7iS1LtjCD2CwCqhIbXp8Fs0UFIiQedu5ih6gRlPgx+R4LiM0poC1xa/5C oDM4gIbqSdy/qAUSZhaQl9i85i3zBEaBWUg6ZiFUzUJStYCReRWjSGppcW56brGRXnFibnFp Xrpecn7uJkZg/G479nPLDsaud8GHGAU4GJV4eBkUPSOFWBPLiitzDzFKcDArifCedvaKFOJN SaysSi3Kjy8qzUktPsRoCvTCRGYp0eR8YGrJK4k3NDE0tzQ0MrawMDcyUhLnnfrhSriQQHpi SWp2ampBahFMHxMHp1QD4+bN7edLxUu2fHv45f/GK0lyxd9+hc/2TXBqXezHzR5+9b1D3Jd6 zobqLxXpfhr1LUXXp/z96Px2dlJU49QLKe8XJDUev3S2efp2tYtNeUfVT052+tZznq3ZomYB W+qeOYsvRHYUxE55m6Y2yXC/jL/3tdo8lacB+RIWMw+3iSg+YrnjJ2aTqsRSnJFoqMVcVJwI AC1BzDv1AgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170621103701eucas1p246de92012a06b329f8e01b3fe6b6ffd4 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?SWx5YSBNYXhpbWV0cxtTUlItVmlydHVhbGl6YXRpb24gTGFi?= =?UTF-8?B?G+yCvOyEseyghOyekBtMZWFkaW5nIEVuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?SWx5YSBNYXhpbWV0cxtTUlItVmlydHVhbGl6YXRpb24gTGFi?= =?UTF-8?B?G1NhbXN1bmcgRWxlY3Ryb25pY3MbTGVhZGluZyBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0NJU0hRG0MxMEdEMDFHRDAxMDE1NA==?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170621103016epcas1p29f221baf4778c992e564416faa6eec46 X-RootMTR: 20170621103016epcas1p29f221baf4778c992e564416faa6eec46 References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <3795576.X6Zydzo19D@xps> <20170621092744.GA26030@jerin> <2845661.r9ChRO7rgB@xps> <20170621102939.GA27670@jerin> Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 10:37:05 -0000 On 21.06.2017 13:29, Jerin Jacob wrote: > -----Original Message----- >> Date: Wed, 21 Jun 2017 11:58:12 +0200 >> From: Thomas Monjalon >> To: Jerin Jacob >> Cc: Sergio Gonzalez Monroy , Hemant >> Agrawal , Ilya Maximets , >> dev@dpdk.org, Bruce Richardson , David >> Marchand , Heetae Ahn >> , Yuanhan Liu , Jianfeng >> Tan , Neil Horman , Yulong >> Pei >> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages >> >> 21/06/2017 11:27, Jerin Jacob: >>> -----Original Message----- >>>> Date: Wed, 21 Jun 2017 10:49:14 +0200 >>>> From: Thomas Monjalon >>>> To: Jerin Jacob >>>> Cc: Sergio Gonzalez Monroy , Hemant >>>> Agrawal , Ilya Maximets , >>>> dev@dpdk.org, Bruce Richardson , David >>>> Marchand , Heetae Ahn >>>> , Yuanhan Liu , Jianfeng >>>> Tan , Neil Horman , Yulong >>>> Pei >>>> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages >>>> >>>> 21/06/2017 10:41, Jerin Jacob: >>>>>>> 1. There are many machines (arm/ppc), which do not support NUMA. >>>>>>> >>>>>>> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA >>>>>>> >>>>>> >>>>>> I did find that link too, last modified 4 years ago. >>>>>> Despite that, I could not find any ARM references in libnuma sources, but >>>>>> Jerin proved that there is support for it. >>>>>> >>>>>> http://oss.sgi.com/projects/libnuma/ >>>>>> https://github.com/numactl/numactl >>>>> >>>>> Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel. >>>>> I guess we are talking about build time time dependency with libnuma here. >>>>> Correct? I think, Even with old arm64 kernel(< 4.6), You can build against >>>>> libnuma if it is present in rootfs. Just that at runtime, it will return >>>>> NUMA support not available. Correct? >>>>> >>>>> How hard is detect the presence of "numaif.h" if existing build system does not >>>>> support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES >>>>> if build environment has "numaif.h". >>>>> >>>>> Some example in linux kernel build system: >>>>> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh >>>> >>>> I think we should not try to detect numaif.h, because it should be >>>> an error on platform supporting NUMA. >>> >>> I have installed libnuma on a NUMA and non NUMA machine. >>> Compiled and ran following code on those machine and it could detect >>> the numa availability. Could you add more details on the "error on >>> platform supporting NUMA". >> >> I was saying that we do not need to detect NUMA. >> If we are building DPDK for a NUMA architecture and libnuma is not >> available, then it will be a problem that the user must catch. >> The easiest way to catch it, is to fail on the include of numaif.h. > > libnuma is not really _architecture_ depended. > > Ilya Maximets patch disables NUMA support in common arm64 config.I > think, It is not correct, We should not disable on any archs generic config. > > IMO, It should be enabled by default in common config and then we can > detect the presence of numaif.h, if not available OR a target does not need it > explicitly, proceed with disabling > RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable. Detecting of headers is impossible until dpdk doesn't have dynamic build configuration system like autotools, CMake or meson. Right now we just can't do that. > No strong opinion on "failing the build" vs "printing a warning" in the > absence of numaif.h