From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 4E5525A63 for ; Tue, 13 Oct 2015 17:49:57 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 13 Oct 2015 08:49:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,678,1437462000"; d="scan'208";a="791648352" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga001.jf.intel.com with ESMTP; 13 Oct 2015 08:49:52 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.116]) by IRSMSX106.ger.corp.intel.com ([169.254.8.229]) with mapi id 14.03.0248.002; Tue, 13 Oct 2015 16:49:01 +0100 From: "Richardson, Bruce" To: Nissim Nisimov , "'dev@dpdk.org'" Thread-Topic: propose a solution for mapping same virtual address space to asymmetric processes Thread-Index: AdEFzCztSRUGD7HyT42FMoDDDi8OFgAAmIOg Date: Tue, 13 Oct 2015 15:49:00 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B03595A760@IRSMSX103.ger.corp.intel.com> References: <94AA676E9B9A384A844E7692F3CAD906C54F645D@ILMB2.corp.radware.com> In-Reply-To: <94AA676E9B9A384A844E7692F3CAD906C54F645D@ILMB2.corp.radware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] propose a solution for mapping same virtual address space to asymmetric processes 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: Tue, 13 Oct 2015 15:49:57 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Nissim Nisimov > Sent: Tuesday, October 13, 2015 4:40 PM > To: 'dev@dpdk.org' > Subject: [dpdk-dev] propose a solution for mapping same virtual address > space to asymmetric processes >=20 > Hi all, >=20 > The below will try to suggest a modification to the initialization of > Environment Abstraction Layer (AKA EAL) so it will be able to allocate > memory zones from same virtual memory addresses even if the primary > process is not similar to the secondary processes. >=20 > Problem: > The DPDK Primary/Secondary model requires that the exact same hugepage > memory mappings be present in all applications. > An issue may occur when the Primary and secondary processes are not > symmetric in such way that the code has big differences (for example, > Primary process is a traffic distributer and secondary is a worker). > The result may be that specific virtual address region in the first > process won't be available in the second process. >=20 >=20 > Suggested solution: > Map all related rte and uio sections somewhere close to the end of huge > pages memory (that mean rte_eal_memory_init() should be called before > rte_config_init() in primary process) According to our observations there > will be more probability to success when allocating the above sections > after huge pages section (actually uio is already allocated after the hug= e > pages area) >=20 > It solved our problem when trying to work with a primary traffic > distributer which is a very "light" process and few secondary worker > processes. >=20 >=20 > Please share your thoughts on this before I will try to commit our patch > for review >=20 > Thanks, > Nissim Hi, out of interest, have you tried fixing the issue using the "--base-virtaddr= " EAL flag to hint a base address to the primary process? It was put into t= he code some time ago to help solve exactly this problem. /Bruce