From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 821E2568F for ; Tue, 1 Sep 2015 21:18:56 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZWr4z-0005N3-5c; Tue, 01 Sep 2015 15:18:50 -0400 Date: Tue, 1 Sep 2015 15:18:42 -0400 From: Neil Horman To: "Iremonger, Bernard" Message-ID: <20150901191842.GA31310@hmsreliant.think-freely.org> References: <20150831125940.GC32518@hmsreliant.think-freely.org> <2129387.iCBeS9Cg7R@xps13> <8CEF83825BEC744B83065625E567D7C219F49ACE@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CEF83825BEC744B83065625E567D7C219F49ACE@IRSMSX108.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.0 (-) X-Spam-Status: No 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: Tue, 01 Sep 2015 19:18:56 -0000 On Tue, Sep 01, 2015 at 01:38:02PM +0000, Iremonger, Bernard wrote: > 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 differentiation 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 above discussion. > > (1) Remove relationship of the ethdev to the pci driver. Correct > (2) Refactor ethdev registration code so that there is a single init path. Correct (or mostly correct, in rereading my initial post, there may be some ambiguitiy here) > (3) Make bus registration independent of ethdev registration. Correct > (4) Change all (17) PMD's to use the modified structures. > Correct (I assume the 17 number is accurate here) > 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 this for ordering of initalization in rte_eal_dev_init, which is a hack). What 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. Inside that init routine, the driver would then be responsible for registering with the 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 that bus. > 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 including 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 > and put somewhere else or replaced with a union of bus types and drivers? > > Regards, > > Bernard. > > >