From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id E8D2D1B42C; Fri, 13 Jul 2018 00:08:35 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6BC8B22475; Thu, 12 Jul 2018 18:08:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 12 Jul 2018 18:08:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=cq3My7SBqURrSJXZmpGz9bAgyn wIErF10ztDgsLuIDU=; b=gGrH9j5paAnYwUHfbCfvrSJb5Rl7WNGFM25pYBsIS/ 9hh4r7b/IMavGgBg3VRgY25+WR6EJPI8nF1KHXotF8WB2K3Vq4UKRidnhtuctRZ7 n47yYjnq8uiklmtyxKo8+oeCPegGlMggBsOeJu5V3+GuQiqrYCQHAT3tNhoOo1ri M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=cq3My7 SBqURrSJXZmpGz9bAgynwIErF10ztDgsLuIDU=; b=k1Ulw36qrTWubXvzmm1zWA H3vhzwy5TAvbGzOo+P+j5s+yWMRcQZUJ46ZIZyICMH9jLreesj6ciWgXLXY2C7Mj 8MveC/Z9GBXPPBUwEa4EGfAir5N7gBzBBEVvBaouno+WHtm9oWrExdM/gB8+f4NV yrUqtTdK1qjqrDHnW6BE1bzIShyHZo9JZ/9q0FYqUuxBpYAZaR+ae9YHRrIRJes5 2dBDP+qD9sTb88XbLRXxavQHse5WRzYGvpBKN8bMh9K3cfWeYJVaaC8zeaHh/oXX FnfNxsdpFIwFwR1PTN9VJ1WBqRibfmKmM92XOJGvbSUtsozATgJrxGV4hWwrQisg == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 65EB410261; Thu, 12 Jul 2018 18:08:34 -0400 (EDT) From: Thomas Monjalon To: Dariusz Stojaczyk Cc: dev@dpdk.org, "Burakov, Anatoly" , stable@dpdk.org Date: Fri, 13 Jul 2018 00:08:33 +0200 Message-ID: <4151001.GHUicDdu0G@xps> In-Reply-To: <6fb6125a-9f0a-4c37-a51b-c266f353d5b9@intel.com> References: <1529351589-173939-1-git-send-email-dariuszx.stojaczyk@intel.com> <6fb6125a-9f0a-4c37-a51b-c266f353d5b9@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] memory: do not use base-virtaddr in secondary processes 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: Thu, 12 Jul 2018 22:08:36 -0000 19/06/2018 11:21, Burakov, Anatoly: > On 18-Jun-18 8:53 PM, Dariusz Stojaczyk wrote: > > Since secondary process' address space is highly dictated > > by the primary process' mappings, it doesn't make much > > sense to use base-virtaddr for secondary processes. > > > > This patch is intended to fix PCI resource mapping > > in secondary processes using the same base-virtaddr > > as their primary processes. PCI uses the end of the hugepage > > memory area to map all resources. [pci_find_max_end_va()] > > It works for primary processes, but can't be mapped 1:1 > > by secondary ones, as the same addresses are currently always > > occupied by shadow memseg lists, which were created with > > eal_get_virtual_area(NULL, ...). > > > > ``` > > PRIMARY PROCESS > > 0x6e00e00000 388K rw-s- fbarray_memseg-2048k-1-3 > > 0x6e01000000 16777216K r---- [ anon ] > > 0x7201000000 16K rw-s- resource0 > > > > SECONDARY PROCESS > > 0x6e00e00000 388K rw-s- fbarray_memseg-2048k-1-3 > > 0x6e01000000 16777216K r---- [ anon ] > > 0x7201000000 4K rw-s- fbarray_memseg-1048576k-0-0_203213 > > ``` > > > > Fixes: 524e43c2ad9a ("mem: prepare memseg lists for multiprocess sync") > > Cc: anatoly.burakov@intel.com > > Cc: stable@dpdk.org > > > > Signed-off-by: Dariusz Stojaczyk > > --- > > Acked-by: Anatoly Burakov Applied, thanks