From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 9E77B3784 for ; Thu, 3 Sep 2015 16:03:24 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 03 Sep 2015 07:02:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,462,1437462000"; d="scan'208";a="781942339" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga001.fm.intel.com with ESMTP; 03 Sep 2015 07:02:52 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.12]) by IRSMSX152.ger.corp.intel.com ([169.254.6.220]) with mapi id 14.03.0224.002; Thu, 3 Sep 2015 15:02:51 +0100 From: "Iremonger, Bernard" To: Thomas Monjalon , Neil Horman Thread-Topic: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs Thread-Index: AQHQ4/iIrrsGaqoMN02VOjrYJZek+Z4nn9IAgABdgACAAtWp8A== Date: Thu, 3 Sep 2015 14:02:49 +0000 Message-ID: <8CEF83825BEC744B83065625E567D7C219F4A3F4@IRSMSX108.ger.corp.intel.com> References: <20150831125940.GC32518@hmsreliant.think-freely.org> <2129387.iCBeS9Cg7R@xps13> <8CEF83825BEC744B83065625E567D7C219F49ACE@IRSMSX108.ger.corp.intel.com> <20150901191842.GA31310@hmsreliant.think-freely.org> In-Reply-To: <20150901191842.GA31310@hmsreliant.think-freely.org> 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 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs 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: Thu, 03 Sep 2015 14:03:25 -0000 Hi Neil, Thomas, > > > > > > > > You didn't remove the relationship of the ethdev to the pci driver > > > > though, which is really the problem, An ethdev may reside on any > > > > number of bus types (pci/usb/vmbus/virt/none). > > > > > > > > > > Whats really needed is a way to associate an ethdev with an > > > > arbitrary bus > > > > > > > > > > > Please see email below from 6Wind > > > > > > > > > > http://dpdk.org/ml/archives/dev/2015-July/022107.html > > > > > > > > > I think you misread that. I think all Thomas is asking for > > > > (correct me if I'm wrong Thomas), is for someone to start > > > > refactoring the ethdev registration code so that we can have a > > > > single init path without the need for wierd typing and differentiat= ion at > init time. > > > > > > > > > > We just need to > > > > start thinking about how to make bus registration independent of > > > > ethernet device registration, and while your patch series sort of > > > > eliminates some of that, its really not a proper refactoring of > > > > the sort I think Thomas is asking for. > > > > I am just trying to distill what the actual requirement is from the abo= ve > discussion. > > > > (1) Remove relationship of the ethdev to the pci driver. > Correct I plan to continue work on the RFC to address this. >=20 > > (2) Refactor ethdev registration code so that there is a single init p= ath. > Correct (or mostly correct, in rereading my initial post, there may be so= me > ambiguitiy here) >=20 > > (3) Make bus registration independent of ethdev registration. > Correct >=20 > > (4) Change all (17) PMD's to use the modified structures. > > > Correct (I assume the 17 number is accurate here) There are 17 PMD directories some of which have multiple PMD's. The total number of PMD's is 23 at present. =20 > > The rte_eal_driver_registration() code is in librte_eal, untouched as= yet by > this patch set. > > > Correct, the code that registers an init function is a single path, which= is great. > However, that path requires that you specify a device type (in this case > PMD_PDEV or PMD_VDEV to differentiate pci vs virtual devices (it uses thi= s > for ordering of initalization in rte_eal_dev_init, which is a hack). Wha= t would > be preferred would be if the structure that was registered via that macro > only held a name and an init routine to initalize the driver itself. Insi= de that > init routine, the driver would then be responsible for registering with t= he > appropriate bus type (virtual/pci/usb/whatever). A secondary function > would be registered as part of that process (akin to the linux/bsd probe(= ) > method) which was called once for each instance of the device found on th= at > bus. >=20 I will send a second RFC to address the eal driver registration code issues= in librte_eal. > > The rte_eth_driver_registration() code is in librte_ether. > > Should the pci fields be removed from the struct rte_eth_dev{} and > > struct eth_driver{}, > IMO, yes, they should, as the driver can store pointers to those devices = in > their private per-device data area. That said, there may be value in inc= luding > a union of all bus types in the ethdev itself, if there are higher layer = functions > that need to be aware of a given ethdevs bus type I plan to park the issue of multiple bus types for now. More consensus is needed on the best way forward.=20 =20 >=20 > > and put somewhere else or replaced with a union of bus types and > drivers? Regards, Bernard.