From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id F361414EC for ; Wed, 10 May 2017 13:37:42 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3B5722096A; Wed, 10 May 2017 07:37:42 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 10 May 2017 07:37:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=u1veP6F1+cbNUNu gWEHnWEUWUZEbJ5flKUg3g5YqKO8=; b=KvrYclSxy+TqfnpAfk8/QhbfcwMHSrk JQjaBqKV/jNAPtVUeGMgvVp1Hz31qVUH9nGVGQpJErOWO2fP7Ao0lhmHicUFn1Hq uQoguRkA8W0HlOWRxhC7JYFtakRckOz6o12scvfXjrx6PRMObBU81YVJzF/KDIwR 0ALXl+bk/Z4A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=u1veP6F1+cbNUNugWEHnWEUWUZEbJ5flKUg3g5YqKO8=; b=GDwCsDBU bj0X+h7MsZgoIb64quUlpXvyUOMJckG5DRnTb4bDRsTXPnjQzWuj+BilYXP7hjUV 8zp/3Fn0S/JxcNv2rMjUAnZE1fSI3eWDF15UhKc/vIv6JqAiOQ6PRZPLUn1KOmMo W98rSgYMFKEdp5ryf+fls9nhCKDR/jGFE2ftZZq0ufEDHip/Amw/X8lvnzv3vAqr 44Sv3wKD4v5GpjoPmj1ZFSN0MiBNXZEMSxE/7nAzD3IhHkfLwZkAP6S386jcrbwn 9WsbI2mnP6/RlXqmpNpUDC+P9Xzdo5zxBf2zgRf83ed+qQpzpyakpBDY/JVQ9SzH DfC7Th2lLyS9pw== X-ME-Sender: X-Sasl-enc: 1upZdqFwtvLpsBL6UbOpxQHBKSTYp3iz/cq018X4dh6x 1494416261 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id DBF9B7E5C8; Wed, 10 May 2017 07:37:41 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob , Declan Doherty , Radu Nicolau Cc: dev@dpdk.org Date: Wed, 10 May 2017 13:37:41 +0200 Message-ID: <1689808.ooT0WhsgLn@xps> In-Reply-To: <20170510110843.GA22712@jerin> References: <1494341879-18718-1-git-send-email-radu.nicolau@intel.com> <1c20ee02-530f-a39a-47c5-15cc5ce1a973@intel.com> <20170510110843.GA22712@jerin> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC][PATCH 2/5] pci: allow shared device instances. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 11:37:43 -0000 10/05/2017 13:08, Jerin Jacob: > From: Declan Doherty > > > > Hey Thomas, I've been working on this with Radu, so see my take below > > > > On 10/05/2017 11:28 AM, Thomas Monjalon wrote: > > > 10/05/2017 12:11, Radu Nicolau: > > > > Hi > > > > > > > > On 5/10/2017 10:09 AM, Thomas Monjalon wrote: > > > > > Hi, > > > > > > > > > > 09/05/2017 16:57, Radu Nicolau: > > > > > > Updated PCI initialization code to allow devices to be shared across multiple PMDs. > > > > > > > > > > > > Signed-off-by: Radu Nicolau > > > > > I was waiting the day when we have a device shared > > > > > by two different interfaces. > > > > > Note that some Mellanox and Chelsio devices already instantiate > > > > > two ethdev ports per PCI device. > > > > > > > > > > Please explain your idea behind this "shared" flag. > > > > > What is your exact need? > > > > > > > > Currently for each pci device a look-up into a list of PMDs is > > > > performed, and when a match is found the system moves to the next > > > > device. Having this flag will allow a PMD to inform the system that > > > > there may be more matches, more PMDs that can be used for this > > > > particular device. > > > > There is a difference when comparing to the devices you mentioned above, > > > > in this case the PMDs are totally different types, one network and one > > > > cryptodev PMD for each IXGBE network card. > > > > > > Yes I know it is a lack in DPDK. > > > Linux introduced MultiFunction Device in 2005: > > > http://events.linuxfoundation.org/sites/events/files/slides/belloni-mfd-regmap-syscon_0.pdf > > > > So at the most basic level the intention is to allow more than one device of > > different types, in our case a net PMD and a crypto PMD, to be instantiated > > on a single PCI bar, in essence to share the bar. I'm not familiar with the > > approaches taken in the Mellanox and Chelsio devices but I assume they are > > handled with the driver probe/create functions independently from the EAL > > infrastructure? Yes it is done in ethdev driver without real impact on EAL. > > For the initial proto-typing of this RFC we only implemented the > > multi-device creation but I envisage that there will be a requirement for > > sharing state between drivers, or at a minimum implementing locking around > > shared resources, registers etc. And I would like to see this done in a > > generic fashion that can me leverage by any driver and not have each driver > > having to solve this independently. > > Cavium's next generation PCI based NW devices has similar scheme where we > need to share the same BAR with multiple DPDK subsystems(ethdev, > eventdev etc) unlike current generation(OcteonTX). > > I think, Another possible way to handle this in generic way is to: > Register a new rte_bus for the shared PCI access which sits on top PCIe bus. > With new bus's scan and probe scheme, it can probe the two devices. Jerin, I don't see the benefit of a new virtual bus. > > I think this approach was sufficient to enable the RFC and kick off the > > discussion, but it is not a fully featured solution and we wanted to get > > community feedback before progressing to far along with a fully featured > > solution. Yes, that's how I've understood the RFC. That's why I try to start the discussion early, requesting more inputs. 10/05/2017 12:47, Radu Nicolau: > We have considered a vdev crypto PMD approach that would have not > require changes to the eal section, but it would have required some sort > of side communication with the IXGBE PMD; another one was a some sort of > on-demant initialized cryptodev. Over these approaches the current one > is cleaner and makes more sense, initialize a net and crypto PMD for a > device that is both a NIC and a cryptro device. Yes regarding the probing, an EAL change makes more sense. If someone has another view, please share. The other important topic to discuss is how we share device registers between different drivers. Please do not limit yourself to what exists and do not try to avoid any breakage when brainstorming. Thanks