From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 0A88BA2EDB
for <public@inbox.dpdk.org>; Wed, 2 Oct 2019 16:42:48 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id D07CF1BEEC;
Wed, 2 Oct 2019 16:42:48 +0200 (CEST)
Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com
[209.85.215.193]) by dpdk.org (Postfix) with ESMTP id 33F791BEEC
for <stable@dpdk.org>; Wed, 2 Oct 2019 16:42:48 +0200 (CEST)
Received: by mail-pg1-f193.google.com with SMTP id z12so11936458pgp.9
for <stable@dpdk.org>; Wed, 02 Oct 2019 07:42:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20150623.gappssmtp.com; s=20150623;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=mFiroF7E1STKfORPL1CGX72V3WTfPhzp0orqz1E+v7I=;
b=ynCLf4ZKtLLtb7AbFQ6wHXT6JI3NRslMvkAGOSTK0OxtSQ+mGJp08SgqrhVcyMgROZ
kkNgsXd2kuuR9vWs9CIY7gCtp3Bu52PDknXl0DrZJBVN3H4jO/UWf/8ehP0eNjhJnPcT
t99i8Rj8pmrBfkzk+hNXtdwUactBthj9MAR23cU/6LkqVQYVkB7OqMN2YEJT8KYelZ/K
CeklhJQ5PO4eOQbNZQcIVbxgc9ZR5wqcAO2pM3sw7o+/BVvoHJd6AiT/BraPR79PMYH7
yUTCeGJnoCtrObbupD8f5ZRhq36ipNcp7rQi6vDBXM8Q44+v41FlIsOYK2K+pxv6asdW
yZXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=mFiroF7E1STKfORPL1CGX72V3WTfPhzp0orqz1E+v7I=;
b=Ov0EaTeS+6cFblMJ5zVX2e7HqkWicUgUh7UPYHPdM8+zxEcEJOXyGP1TUnWhOoN5m4
HzLi8KLqx8bfZXKK6PZAkTIfiywstylYQhOms+ZJ+aBU75JeI6fNzIpoSpNli02Z22cF
F6CoB+WSEcfqywLK8GUk0V0bleToMqnos7Q29efW794TO3HPPHWkUssX1hp6rMpB3EFi
Iao7xRQU1fFySks38bH9krQIcUIp3IST+CgQvPlKYFNA6aXQaXHIlMvKALNm7i67JHuN
SNPc5VHbMBZJPe1iPsyZsyboWnDQuZJZC0sdav4Z9cFbclUxLrcbdc0fJjeV0PKLSVJX
ZA7A==
X-Gm-Message-State: APjAAAXxHTPMvqTxmk4lfZp39IEtRAaqIp9TGmvB4M3EOfIBlj+sOs+0
4v1hKdk2Y9+CsySIMEOl7p691w==
X-Google-Smtp-Source: APXvYqx+QNn8EDS0G7+YN+nILfs/9mPxh67DdBmleYVVQ7sEPrpIVnEoLckP2SlV8FDusRJ+OyzRnQ==
X-Received: by 2002:a17:90a:cc08:: with SMTP id
b8mr4625800pju.119.1570027367125;
Wed, 02 Oct 2019 07:42:47 -0700 (PDT)
Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127])
by smtp.gmail.com with ESMTPSA id v4sm17917846pff.181.2019.10.02.07.42.46
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 02 Oct 2019 07:42:47 -0700 (PDT)
Date: Wed, 2 Oct 2019 07:42:40 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: David Marchand <david.marchand@redhat.com>
Cc: Anatoly Burakov <anatoly.burakov@intel.com>, dev <dev@dpdk.org>, Bruce
Richardson <bruce.richardson@intel.com>, dpdk stable <stable@dpdk.org>
Message-ID: <20191002074240.50c1ec7f@hermes.lan>
In-Reply-To: <CAJFAV8wmuoFOwcnH9OXupOCVX9-fXsRNNDeccefjZeUPDWH-Zw@mail.gmail.com>
References: <09c3f9d74e1e49aa5b3608d4bf4a773d086e83ff.1564501879.git.anatoly.burakov@intel.com>
<09c3f9d74e1e49aa5b3608d4bf4a773d086e83ff.1564577214.git.anatoly.burakov@intel.com>
<CAJFAV8wmuoFOwcnH9OXupOCVX9-fXsRNNDeccefjZeUPDWH-Zw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4 1/2] eal: make base address
hint OS-specific
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
On Wed, 2 Oct 2019 13:41:30 +0200
David Marchand <david.marchand@redhat.com> 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)?