From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 70AFAA32A2 for ; Thu, 24 Oct 2019 14:32:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4CAF51EA35; Thu, 24 Oct 2019 14:32:39 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 403F71EA29; Thu, 24 Oct 2019 14:32:37 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2019 05:32:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,224,1569308400"; d="scan'208";a="210150185" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.8.129]) ([10.252.8.129]) by fmsmga001.fm.intel.com with ESMTP; 24 Oct 2019 05:32:34 -0700 To: Stephen Hemminger , David Marchand Cc: dev , Bruce Richardson , dpdk stable References: <09c3f9d74e1e49aa5b3608d4bf4a773d086e83ff.1564501879.git.anatoly.burakov@intel.com> <09c3f9d74e1e49aa5b3608d4bf4a773d086e83ff.1564577214.git.anatoly.burakov@intel.com> <20191002074240.50c1ec7f@hermes.lan> From: "Burakov, Anatoly" Message-ID: <1303a98f-60e0-9b23-7518-93fc1fc7f1ab@intel.com> Date: Thu, 24 Oct 2019 13:32:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191002074240.50c1ec7f@hermes.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 1/2] eal: make base address hint OS-specific 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 02-Oct-19 3:42 PM, Stephen Hemminger wrote: > On Wed, 2 Oct 2019 13:41:30 +0200 > David Marchand wrote: > >>> +uint64_t eal_get_baseaddr(void) >>> +{ >>> + /* >>> + * Linux kernel uses a really high address as starting address for >>> + * serving mmaps calls. If there exists addressing limitations and IOVA >>> + * mode is VA, this starting address is likely too high for those >>> + * devices. However, it is possible to use a lower address in the >>> + * process virtual address space as with 64 bits there is a lot of >>> + * available space. >>> + * >>> + * Current known limitations are 39 or 40 bits. Setting the starting >>> + * address at 4GB implies there are 508GB or 1020GB for mapping the >>> + * available hugepages. This is likely enough for most systems, although >>> + * a device with addressing limitations should call >>> + * rte_mem_check_dma_mask for ensuring all memory is within supported >>> + * range. >>> + */ >>> + return 0x100000000; > > Is this going to work right on 32 bit builds where sizeof(uint) == 4 > then constants default to 32. Does it need ul or ull suffix (or a cast)? > Adding ULL in v2, thanks. -- Thanks, Anatoly