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 20309A2EDB for ; Wed, 2 Oct 2019 13:41:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 209AB1BEE1; Wed, 2 Oct 2019 13:41:49 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id D5E5D1BED3 for ; Wed, 2 Oct 2019 13:41:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1570016507; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NBfHpaAlwxXPlJQkrc/oQ67OZsC7CeECZ2DI5Gv8Eak=; b=brurT30nQjup8ySdPht0PCv92pDXzVFRyU0zENffXtmBCMc5qV7zGMgFod1krnQgDFWAME SMxAhdcgk9JCcqCnwzACw/OciuZizgsK+kHSUHsiln4cvbLlqambm9Bc/nZs/PLE3cVEdL XuXtMcyBWQG1Q9b05W5onF6QLI6qiGw= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-221-sCJRXg7jMNSFCdUMxtAFww-1; Wed, 02 Oct 2019 07:41:42 -0400 Received: by mail-ua1-f71.google.com with SMTP id r21so3312500uao.16 for ; Wed, 02 Oct 2019 04:41:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8tcGiSf3vb5yKOrx7954NBbD4g1GqS8nYTcLMO3ilbA=; b=FVOVhubilHVf+JUvKJZLtPsWDUuVrZKXX9bQvIM0lNe/DzSRteDA1nWt8LAj9TOZ7y mjITga0vcxeJVWjtPhECg9KD2eakqCgI4bYaMYKI9McOd6usywi1YRjPLm13sGChxqNX /PqcuPN5Kv3BqNzuU7iZ8f7uKITNVxrAGu96Xlig8Cq9EbuG3APct6uVnfGQa0s3kdDO muFlmkdKlc+QzuqfetLO0zxJzIXtu9o0YVdB+kAljrmRWK8IiPDb1qYC2eiaZwJNTLgk OVmdddcunVsy26A3NMJ+ITZQRaKu3LsScnjdAnaormDBcLPm3O4tZC5s4oWeTCH3cXDe pFrw== X-Gm-Message-State: APjAAAWYib6DebdNNY0eY4AXrm/+ReCYDKS8JxnP7P0XljLTpVMkDEaK 2+f4R3o/Fjtp7ZbCMy1dl0yVCJ4sZ79b/oykALna/jghPJFobeB0EV1pdfzL94bIMg7M70jOS8l sLgr1D/5U/FVoulKyq5U= X-Received: by 2002:ab0:4203:: with SMTP id i3mr1428820uai.53.1570016501727; Wed, 02 Oct 2019 04:41:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqx85zG1W4RTqpsWoYslFUMe6wqGwlFfosfIcMZ1h/WnhjdG1/SLsMtRoKZZRLMyKg9yD3yG8Fw9o0KOfCGd2uA= X-Received: by 2002:ab0:4203:: with SMTP id i3mr1428800uai.53.1570016501280; Wed, 02 Oct 2019 04:41:41 -0700 (PDT) MIME-Version: 1.0 References: <09c3f9d74e1e49aa5b3608d4bf4a773d086e83ff.1564501879.git.anatoly.burakov@intel.com> <09c3f9d74e1e49aa5b3608d4bf4a773d086e83ff.1564577214.git.anatoly.burakov@intel.com> In-Reply-To: <09c3f9d74e1e49aa5b3608d4bf4a773d086e83ff.1564577214.git.anatoly.burakov@intel.com> From: David Marchand Date: Wed, 2 Oct 2019 13:41:30 +0200 Message-ID: To: Anatoly Burakov Cc: dev , Bruce Richardson , dpdk stable X-MC-Unique: sCJRXg7jMNSFCdUMxtAFww-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Wed, Jul 31, 2019 at 2:47 PM Anatoly Burakov wrote: > > Not all OS's follow Linux's memory layout, which may lead to > problems following the suggested common address hint absent > of a base-virtaddr flag. Make this address hint OS-specific. > > Cc: stable@dpdk.org Missing Fixes: ? > > Signed-off-by: Anatoly Burakov > --- > lib/librte_eal/common/eal_common_memory.c | 19 +------------------ > lib/librte_eal/common/eal_private.h | 6 ++++++ > lib/librte_eal/freebsd/eal/eal_memory.c | 10 ++++++++++ > lib/librte_eal/linux/eal/eal_memory.c | 20 ++++++++++++++++++++ > 4 files changed, 37 insertions(+), 18 deletions(-) > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/c= ommon/eal_common_memory.c > index 19ea47570..4a9cc1f19 100644 > --- a/lib/librte_eal/common/eal_common_memory.c > +++ b/lib/librte_eal/common/eal_common_memory.c > @@ -40,23 +40,6 @@ > static void *next_baseaddr; > static uint64_t system_page_sz; > > -#ifdef RTE_ARCH_64 > -/* > - * Linux kernel uses a really high address as starting address for servi= ng > - * 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 spa= ce > - * as with 64 bits there is a lot of available space. > - * > - * Current known limitations are 39 or 40 bits. Setting the starting add= ress > - * 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 ensurin= g all > - * memory is within supported range. > - */ > -static uint64_t baseaddr =3D 0x100000000; > -#endif > - > #define MAX_MMAP_WITH_DEFINED_ADDR_TRIES 5 > void * > eal_get_virtual_area(void *requested_addr, size_t *size, > @@ -85,7 +68,7 @@ eal_get_virtual_area(void *requested_addr, size_t *size= , > #ifdef RTE_ARCH_64 > if (next_baseaddr =3D=3D NULL && internal_config.base_virtaddr = =3D=3D 0 && > rte_eal_process_type() =3D=3D RTE_PROC_PRIMARY) > - next_baseaddr =3D (void *) baseaddr; > + next_baseaddr =3D (void *) eal_get_baseaddr(); > #endif > if (requested_addr =3D=3D NULL && next_baseaddr !=3D NULL) { > requested_addr =3D next_baseaddr; > diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/= eal_private.h > index 798ede553..31eae2278 100644 > --- a/lib/librte_eal/common/eal_private.h > +++ b/lib/librte_eal/common/eal_private.h > @@ -381,4 +381,10 @@ rte_option_init(void); > void > rte_option_usage(void); > > +/** > + * Get OS-specific EAL mapping base address. > + */ > +uint64_t > +eal_get_baseaddr(void); > + > #endif /* _EAL_PRIVATE_H_ */ > diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c b/lib/librte_eal/fre= ebsd/eal/eal_memory.c > index 9b9a0577a..1bfdb52fb 100644 > --- a/lib/librte_eal/freebsd/eal/eal_memory.c > +++ b/lib/librte_eal/freebsd/eal/eal_memory.c > @@ -22,6 +22,16 @@ > > #define EAL_PAGE_SIZE (sysconf(_SC_PAGESIZE)) > > +uint64_t eal_get_baseaddr(void) > +{ > + /* > + * FreeBSD may allocate something in the space we will be mapping= things > + * before we get a chance to do that, so use a base address that'= s far > + * away from where malloc() et al usually map things. > + */ > + return 0x1000000000; > +} > + > /* > * Get physical address of any mapped virtual address in the current pro= cess. > */ > diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux= /eal/eal_memory.c > index 1c089a1ef..8516f0d35 100644 > --- a/lib/librte_eal/linux/eal/eal_memory.c > +++ b/lib/librte_eal/linux/eal/eal_memory.c > @@ -70,6 +70,26 @@ static int phys_addrs_available =3D -1; > > #define RANDOMIZE_VA_SPACE_FILE "/proc/sys/kernel/randomize_va_space" > > +uint64_t eal_get_baseaddr(void) > +{ > + /* > + * Linux kernel uses a really high address as starting address fo= r > + * serving mmaps calls. If there exists addressing limitations an= d 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 o= f > + * available space. > + * > + * Current known limitations are 39 or 40 bits. Setting the start= ing > + * address at 4GB implies there are 508GB or 1020GB for mapping t= he > + * available hugepages. This is likely enough for most systems, a= lthough > + * a device with addressing limitations should call > + * rte_mem_check_dma_mask for ensuring all memory is within suppo= rted > + * range. > + */ > + return 0x100000000; > +} > + > /* > * Get physical address of any mapped virtual address in the current pro= cess. > */ > -- > 2.17.1 What about windows port? --=20 David Marchand