From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id B9A9C7E75 for ; Thu, 6 Nov 2014 17:06:58 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 06 Nov 2014 08:12:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,326,1413270000"; d="scan'208";a="627741965" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga002.fm.intel.com with ESMTP; 06 Nov 2014 08:10:41 -0800 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.101]) by IRSMSX104.ger.corp.intel.com ([169.254.5.58]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 16:10:17 +0000 From: "Burakov, Anatoly" To: Thomas Monjalon Thread-Topic: [PATCH v5] eal: map uio resources after hugepages when the base_virtaddr is configured. Thread-Index: AQHP+dcGdG2T5nOWEkiCOSTResgRgJxTupOwgAAGpYCAAABtAA== Date: Thu, 6 Nov 2014 16:10:15 +0000 Message-ID: References: <1415193919-17361-1-git-send-email-liang.xu@cinfotech.cn> <1415287928-14513-1-git-send-email-liang.xu@cinfotech.cn> <176911891.PG8FvFrDef@xps13> In-Reply-To: <176911891.PG8FvFrDef@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v5] eal: map uio resources after hugepages when the base_virtaddr is configured. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 16:06:59 -0000 Well, removing --base-virtaddr is not what I'm asking about. The issue at hand here is that, given our secondary process mechanism (that= you don't like :-) ), some stuff may be attempted to be mapped into space = a secondary process may already have mapped something else into (some libra= ries, for example). This issue was originally discovered by OVDK, so we add= ed a --base-virtaddr option to try and map hugepages at exact virtual addre= ss, rather than wherever mmap decides to do so on its own. The issue encountered by Liang (the author of the patch) is similar, only i= t's not the hugepages are mapped into the occupied space, but rather the PC= I resources (which are mapped with NULL by default, so can be mapped anywhe= re). Therefore he suggested a patch that maps the PCI resources into a spac= e just after the last hugepage when --base-virtaddr is provided. I'm not su= re we need the dependence on --base-virtaddr though, it can probably be don= e unconditionally. If you have no opinion on the matter, we can leave this = detail of the patch as it is, then. Also, I would suspect that if we are to modify where UIO resources are mapp= ed, VFIO code should be modified the same way to avoid inconsistency betwee= n the two. Thanks, Anatoly -----Original Message----- From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]=20 Sent: Thursday, November 6, 2014 3:58 PM To: Burakov, Anatoly Cc: lxu; dev@dpdk.org; De Lara Guarch, Pablo Subject: Re: [PATCH v5] eal: map uio resources after hugepages when the bas= e_virtaddr is configured. 2014-11-06 15:41, Burakov, Anatoly: > Thomas, do we need to do similar changes to VFIO code, to keep consistenc= y? > Also, do we really need for this to depend on --base-virtaddr? Why not=20 > do it unconditionally, i.e. map PCI resources right after hugepages in me= mory? I don't really like the secondary process mechanism at all. So I won't give good advice here ;) But I feel this option --base-virtaddr should be improved or removed. -- Thomas