From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id 15C9D9AEC for ; Tue, 10 May 2016 14:45:31 +0200 (CEST) Received: from jvn (dynamic-109-81-211-184.ipv4.broadband.iol.cz [109.81.211.184]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3r3zVy421Nz8PG; Tue, 10 May 2016 14:45:30 +0200 (CEST) Date: Tue, 10 May 2016 14:45:34 +0200 From: Jan Viktorin To: Santosh Shukla Cc: dpdk , Anatoly Burakov , David Marchand , Keith Wiles , Stephen Hemminger , "Shukla, Santosh" Message-ID: <20160510144534.4a897de6@jvn> In-Reply-To: References: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com> Organization: RehiveTech X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 00/15] Make VFIO support independent on PCI 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, 10 May 2016 12:45:31 -0000 Hello Santosh, On Tue, 10 May 2016 17:48:23 +0530 Santosh Shukla wrote: > On Fri, Apr 29, 2016 at 7:14 PM, Jan Viktorin wrote: > > > > Hello, > > > > here follows several patchs extracting the general VFIO code out of the > > PCI + VFIO code base. Usually, it's just move and rename of functions. > > The most complicated ones are: > > > > * eal/linux: extract setup logic out of pci_vfio_map_resource > > > > - separation of some setup code out of the pci_vfio_map_resource > > (which is otherwise quite PCI-speicific) > > - it is required by the following one > > > > * eal/linux: move global vfio_cfg to eal_vfio.c > > > > - moving the vfio_cfg global variable out of the eal_pci_vfio together with > > the functions working with this variable > > > > Some patchs make just temporary changes to avoid breakages throughout the > > patch set (dma mapping). > > > > I am not sure, how exactly is the mp_sync code intended to work. Should there > > be just a single socket connection (no matter how many bus-systems we support)? > > I assume it works this way so I've generalized the eal_pci_vfio_mp_sync. > > > > The vfio initialization is moved out of the rte_eal_pci_init into EAL. > > > > The code is now prepared for adding of other infrastructures such as the SoC > > that I've introduced in [1]. I've partially done this in my workspace. Probably, I should have written here "later, vfio-platform will be connected to this"... > > > > I haven't started reading patch set, we'll do so. But by referring to > your initiative [1] which is non-pci SoC infra, How about binding > those non-pci soc via vfio-platform-way? As because vfio-for-platform > device use-case is such non-pci accelerators in SoC. is your current > refactoring effort aligned towards vfio-platform direction? Sure, vfio-platform is the way to go. However, this patch set is just a refactoring. The goal is to be able to connect with the vfio-platform. Without this patch set, it leads to lots of duplicated code. Jan -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic