From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id DEE1729CB for ; Fri, 10 Jun 2016 14:08:52 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 10 Jun 2016 05:08:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,449,1459839600"; d="scan'208";a="825473314" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga003.jf.intel.com with ESMTP; 10 Jun 2016 05:08:51 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX109.ger.corp.intel.com (163.33.3.23) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 10 Jun 2016 13:08:49 +0100 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.193]) by irsmsx112.ger.corp.intel.com ([169.254.1.18]) with mapi id 14.03.0248.002; Fri, 10 Jun 2016 13:08:49 +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///3xoCAABF0kP//+qkAgAAuJLA= Date: Fri, 10 Jun 2016 12:08:48 +0000 Message-ID: References: <1465481396-23968-1-git-send-email-thomas.monjalon@6wind.com> <1594485.zPMdI6dQJ2@xps13> <4009533.BSYr1qtBke@xps13> In-Reply-To: <4009533.BSYr1qtBke@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjU2MzZlOGYtNjJiNC00YWRiLTliZTUtMWQ1NzJlMGQxYTY5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkVXVWU4T2tQVGJBUldEVmZmczgxVGVuQVlJa0xqWTg0d2xkaEZyVVVPbkU9In0= 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 12:08:53 -0000 Hi Thomas,=20 > 2016-06-10 09:47, Burakov, Anatoly: > > > > > 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, > > > and some of those pages could be 2M in size. If you're sharing 1G > > > worth of contiguous 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 supported. 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. Maybe Kevin/other OVS > > > > devs could help me out > > > here > > > > :) > > > > > > We can keep supporting 2M pages by having a command line option, > > > instead of the #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS. > > > But as I said, it is not the top priority to remove this hack. > > > > Ah, so you're not suggesting removing the _functionality_, just the #if= def? > That could be made to work I guess... > > > > Also, please correct me if I'm wrong, but I seem to remember some > patches about putting all memory in a single file - I think that should w= ork for > IVSHMEM as well, because I believe IVSHMEM handles holes in files just fi= ne, > and can map even if everything resides inside a single file. So if that p= atch > does what I think it does, we might just integrate it and remove the sing= le file > segments code entirely. >=20 > Yes it can be considered in a memory allocator rework. > Please jump in this thread: > http://dpdk.org/ml/archives/dev/2016-April/037444.html I've read through that thread, and I don't think anything should be done to= support that in IVSHMEM. IVSHMEM library should correctly detect all mappe= d files, whatever the memory layout on the host side (contiguous, noncontig= uous, single file...). On the guest, we're simply adding memzones which we = map from a PCI device, so IVSHMEM shouldn't be affected by any changes to h= ow memzones/mempools are allocated (mempools aren't even allowed for use wi= th IVSHMEM). Thanks, Anatoly