From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 54E69A0679 for ; Tue, 2 Apr 2019 19:23:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 30EE85942; Tue, 2 Apr 2019 19:23:47 +0200 (CEST) Received: from mail-it1-f193.google.com (mail-it1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id 843095942 for ; Tue, 2 Apr 2019 19:23:45 +0200 (CEST) Received: by mail-it1-f193.google.com with SMTP id 139so6595306ita.4 for ; Tue, 02 Apr 2019 10:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6qNZdpVVbsDJpy1SwDZEnNG6LT0iXfTmqrsrmc9uN6w=; b=Efpf2zVZMcS6tKNfEjFaW6hYBKiR8x1pDV4NIyuXtYNroEtCPGHNRk1VfHhauM+LPv z48hMP01slJ5NL1CqyPF3qbcAiaDz/zmFmkU3L1KiKC+AngvdIhSMVrFsQe+Y1+wtR5F DHl7CnK343NzEHf+DRDwjcBHI+3y6txJNK9pYHzeQCW2OZVOpW2QU4cxz5XtjFp2xwAj pWBg2g0W1wcq+0d6awH0r47nfggoi5cIurT/ebcHR5jXzsNkJHVC+fcFZPOFOorM5hi9 DU6VdvAa44D9SuTJ08nfBoHIJ6AVZ4EzvnBZNgni7cEYKhO5qefm1Q7wvlbwHTDCrdoN nPOA== 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=6qNZdpVVbsDJpy1SwDZEnNG6LT0iXfTmqrsrmc9uN6w=; b=VwFXYhTL8b0IEEFODfCiiMn5viy5Ue9+mrg5aI0wbH07xAnaS5aFEyXHOVIMrZxyBB 8/V2g4MgGWNDM/yvPScRNNyycPWajTm7XEKEakUy/mg+BOs1uVvmw2ztcBSbOVS9m0BI G0u1/5QzW/1ELGmNJswgHhwthD+YCpAP3L0vnQVlZdfaaI3QaCTt74DYPiHvp3GmlJNq DxjRbi7XpKgS6U4pPAKHOKokGEJ4ye3vkY/tcTs1qb3F4/bRwuIP4h9rlCbex3uhrhiS HJTvPna97oGc0KA1Z9eUCh/V+VZUOmiQ3pFsIsVGb9bbFmx518v2Q1y4KX5K2amvgpZ/ eRkQ== X-Gm-Message-State: APjAAAV8TNJC0lgovTzxO+nolmEvtyCcXMY7j/fEIhQHOEQfTK5ViUfR ztwcu0BVWVTSgbjXjIguxOgk6gQ6eeUDT+EU5jhX+g== X-Google-Smtp-Source: APXvYqyi111n+vpM6wiQbGLyTMAAfF0hKP+XbyzY/WRMOUpub7t3oaF0C3uoH7zjgF/1BJl2PYZfXZ342bAd5OzZ3bE= X-Received: by 2002:a24:a00b:: with SMTP id o11mr5680893ite.120.1554225824860; Tue, 02 Apr 2019 10:23:44 -0700 (PDT) MIME-Version: 1.0 References: <20190321202156.117496-1-shahafs@mellanox.com> <20190331084348.4740-1-shahafs@mellanox.com> <0ccaf7f1-e10c-de6a-1219-76ce6e76119f@intel.com> In-Reply-To: <0ccaf7f1-e10c-de6a-1219-76ce6e76119f@intel.com> From: Alejandro Lucero Date: Tue, 2 Apr 2019 17:23:33 +0000 Message-ID: To: "Burakov, Anatoly" Cc: Shahaf Shuler , Thomas Monjalon , dev , dpdk stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-stable] [PATCH v2] mem: limit use of address hint X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Tue, Apr 2, 2019 at 5:13 PM Burakov, Anatoly wrote: > On 31-Mar-19 9:43 AM, Shahaf Shuler wrote: > > patch[1] added an address hint as starting address for 64 bit systems in > > case an explicit base virtual address was not set by the user. > > > > The justification for such hint was to help devices that work in VA > > mode and has a address range limitation to work smoothly with the eal > > memory subsystem. > > > > While the base address value selected may work fine for the eal > > initialization, it easily breaks when trying to register external memory > > using rte_extmem_register API. > > > > Trying to register anonymous memory on RH x86_64 machine took several > > minutes, during them the function eal_get_virtual_area repeatedly > > scanned for a good VA candidate. > > > > The attempt to guess which VA address will be free for mapping will > > always result in not portable, error prone code: > > * different application may use different libraries along w/ DPDK. One > > can never guess which library was called first and how much virtual > > memory it consumed. > > * external memory can be registered at any time in the application run > > time. > > > > In order not to break the existing secondary process design, this patch > > only limits the max number of tries that will be done with the > > address hint. > > When the number of tries exceeds the threshold the code > > will use the suggested address from kernel. > > > > Fixes: 1df21702873d ("mem: use address hint for mapping hugepages") > > Cc: stable@dpdk.org > > Cc: alejandro.lucero@netronome.com > > > > [1] commit 1df21702873d ("mem: use address hint for mapping hugepages") > > > > Signed-off-by: Shahaf Shuler > > --- > > > > On v2: > > * instead of a complete remove of the hint limit the number of tries > we allow. > > --- > > LGTM > > Tested-by: Anatoly Burakov > > We can always increase the number of tries later :) > > This is also fine for me. If the map address is not within the supported range by a device with addressing limitations, the device will not be used. Not sure how this is likely to happen, but I guess if it is become a problem, another solution should be implemented. Acked-by: Alejandro Lucero > -- > Thanks, > Anatoly >