From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
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: <xmx:YtFHW1hPhWcv7ltYjVqrTHW6BhWDncdCTC0YxSSAsajNilSp7hq7RQ>
 <xmx:YtFHW6POdIKsh7vCZxxdvw7ndgiBm8pDZ3hWSukqVK25FJ3colZUrg>
 <xmx:YtFHW262gH2Nuzsj9e5OOZk5m7PLWWK5sn5YOKRPPFlPIjKPp9_9xg>
 <xmx:YtFHW43-4o4jqgreVoO-gHe7B-cmJiSEh74361OB3brCOlKVmKTReA>
 <xmx:YtFHW3b77FRe7_4TeLv7QIm2SswvyHSugIyeObgOKQgbk7QFNaud8Q>
 <xmx:Y9FHW3UebybA6bJ8_LP9uVFaZZlR2YR0kTpS5C8IjGiG7xcq1iRKfg>
X-ME-Sender: <xms:YtFHW0M4oH3I6Z4OVmC1ueKTgt_rXlhJc4YNscvwQQOFaK8F4M4uJw>
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 <thomas@monjalon.net>
To: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Cc: dev@dpdk.org, "Burakov, Anatoly" <anatoly.burakov@intel.com>,
 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-stable] [dpdk-dev] [PATCH] memory: do not use
	base-virtaddr in secondary processes
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>
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 <dariuszx.stojaczyk@intel.com>
> > ---
> 
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

Applied, thanks