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 6E8603784 for ; Mon, 7 Sep 2015 11:22:27 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 07 Sep 2015 02:22:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,484,1437462000"; d="scan'208";a="784302069" Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78]) by fmsmga001.fm.intel.com with ESMTP; 07 Sep 2015 02:22:24 -0700 Received: from pgsmsx108.gar.corp.intel.com ([169.254.8.186]) by PGSMSX101.gar.corp.intel.com ([169.254.1.31]) with mapi id 14.03.0224.002; Mon, 7 Sep 2015 17:22:23 +0800 From: "Zende, Amruta S" To: "Iremonger, Bernard" , Thomas Monjalon , Neil Horman Thread-Topic: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs Thread-Index: AQHQ4/iIrrsGaqoMN02VOjrYJZek+Z4nn9IA///oJwCAAsxogIAGgJLg Date: Mon, 7 Sep 2015 09:22:23 +0000 Message-ID: <1574BF4E37E8634BA172E5CF34D31B5CEF7CD2@PGSMSX108.gar.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> <8CEF83825BEC744B83065625E567D7C219F4A3F4@IRSMSX108.ger.corp.intel.com> In-Reply-To: <8CEF83825BEC744B83065625E567D7C219F4A3F4@IRSMSX108.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.20.205] 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: Mon, 07 Sep 2015 09:22:28 -0000 Certain functions like "rte_eth_dev_socket_id" assume the device to be a PC= I device and access pointers like rte_eth_devices[port_id].pci_dev->numa_no= de.=20 Any such assumptions and dependencies should also be removed. Thanks & regards, Amruta Zende +91-20-4305-2969 -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Iremonger, Bernard Sent: Thursday, September 3, 2015 7:33 PM To: Thomas Monjalon; Neil Horman Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs Hi Neil, Thomas, > > > > > > > > You didn't remove the relationship of the ethdev to the pci=20 > > > > driver though, which is really the problem, An ethdev may reside=20 > > > > on any number of bus types (pci/usb/vmbus/virt/none). > > > > > > > > > > Whats really needed is a way to associate an ethdev with an=20 > > > > 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=20 > > > > (correct me if I'm wrong Thomas), is for someone to start=20 > > > > refactoring the ethdev registration code so that we can have a=20 > > > > single init path without the need for wierd typing and=20 > > > > differentiation at > init time. > > > > > > > > > > We just need to > > > > start thinking about how to make bus registration independent of=20 > > > > ethernet device registration, and while your patch series sort=20 > > > > of eliminates some of that, its really not a proper refactoring=20 > > > > of the sort I think Thomas is asking for. > > > > I am just trying to distill what the actual requirement is from the=20 > > above > 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=20 > some 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=20 > > 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=20 > case PMD_PDEV or PMD_VDEV to differentiate pci vs virtual devices (it=20 > uses this for ordering of initalization in rte_eal_dev_init, which is=20 > a hack). What would be preferred would be if the structure that was=20 > registered via that macro only held a name and an init routine to=20 > initalize the driver itself. Inside that init routine, the driver=20 > would then be responsible for registering with the appropriate bus=20 > type (virtual/pci/usb/whatever). A secondary function would be=20 > 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=20 > that 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=20 > > struct eth_driver{}, > IMO, yes, they should, as the driver can store pointers to those=20 > devices in their private per-device data area. That said, there may=20 > be value in including a union of all bus types in the ethdev itself,=20 > if there are higher layer functions that need to be aware of a given=20 > 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.