From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 3261A2BA8 for ; Fri, 10 Jun 2016 11:05:55 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 10 Jun 2016 02:05:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,449,1459839600"; d="scan'208";a="994906423" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 10 Jun 2016 02:05:53 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.193]) by IRSMSX104.ger.corp.intel.com ([163.33.3.159]) with mapi id 14.03.0248.002; Fri, 10 Jun 2016 10:05:52 +0100 From: "Burakov, Anatoly" To: Thomas Monjalon CC: David Marchand , "dev@dpdk.org" , "Gonzalez Monroy, Sergio" , "Yigit, Ferruh" , "Traynor, Kevin" , "pmatilai@redhat.com" Thread-Topic: [PATCH] dropping librte_ivshmem - was log: deprecate history dump Thread-Index: AQHRwpWkIvfEVp+q1EWlZtS+ZvGHIJ/iZ52g Date: Fri, 10 Jun 2016 09:05:51 +0000 Message-ID: References: <1465481396-23968-1-git-send-email-thomas.monjalon@6wind.com> <1799099.25AIKSsmQj@xps13> <1679257.PTMOF8o7eO@xps13> In-Reply-To: <1679257.PTMOF8o7eO@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2JlMjBlNTgtMjIwNy00NzkzLTg4YjctYTNjOTEzMWI1MWZhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImlVZnM3VXhPUVVJWWdDVHU2ckg0NXAwSzJpSDc4aXljNWVVelU1UmZ6blU9In0= x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] dropping librte_ivshmem - was log: deprecate history dump 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: Fri, 10 Jun 2016 09:05:55 -0000 Hi Thomas, Just a few notes: > 3/ The automatic mapped allocation of DPDK objects in the guest. > It should not be done in EAL. > An ivshmem driver would be called by rte_eal_dev_init. > It would check where are the shared DPDK structures, as currently done wi= th > the IVSHMEM_MAGIC (0x0BADC0DE), and do the appropriate allocations. > Thus only the driver would depend on ring and mempool. The problem here is IVSHMEM doesn't allocate the memory from DPDK, it alloc= ates new memory segments by mapping a PCI device. I.e. it doesn't do malloc= s, it modifies mem_config and adds memory to DPDK. Can that be done from wi= thin a PMD? >=20 > The last step of the ivshmem cleanup will be to remove the memory hack > RTE_EAL_SINGLE_FILE_SEGMENTS. Then CONFIG_RTE_LIBRTE_IVSHMEM > could be removed. The reason for that hack is that we often need to map several hugepages, an= d some of those pages could be 2M in size. If you're sharing 1G worth of co= ntiguous memory backed by 2M pages, that's 512 files in the command line in= vanilla DPDK, but can be made into one with RTE_EAL_SINGLE_FILE_SEGMENTS, = so that QEMU command-line doesn't get overly long. So removing this hack, while definitely desired, will adversely affect some= use cases, such as using IVSHMEM on platforms where 1G pages aren't suppor= ted. Whether we want to go with the effort of supporting those is of course= an open question - I personally don't have any data on IVSHMEM userbase. M= aybe Kevin/other OVS devs could help me out here :) Thanks, Anatoly