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 1A10B919B for ; Mon, 31 Aug 2015 14:59:54 +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 1ZWOgd-0005RK-7P; Mon, 31 Aug 2015 08:59:52 -0400 Date: Mon, 31 Aug 2015 08:59:40 -0400 From: Neil Horman To: "Iremonger, Bernard" Message-ID: <20150831125940.GC32518@hmsreliant.think-freely.org> References: <1440690041-32391-1-git-send-email-bernard.iremonger@intel.com> <20150827174357.GC8113@tuxdriver.com> <8CEF83825BEC744B83065625E567D7C219F4883E@IRSMSX108.ger.corp.intel.com> <20150828175133.GC10601@tuxdriver.com> <8CEF83825BEC744B83065625E567D7C219F493A6@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CEF83825BEC744B83065625E567D7C219F493A6@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: Mon, 31 Aug 2015 12:59:54 -0000 On Mon, Aug 31, 2015 at 10:23:33AM +0000, Iremonger, Bernard wrote: > Hi John, > > > -----Original Message----- > > From: John W. Linville [mailto:linville@tuxdriver.com] > > Sent: Friday, August 28, 2015 6:52 PM > > To: Iremonger, Bernard > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs > > > > On Fri, Aug 28, 2015 at 08:15:47AM +0000, Iremonger, Bernard wrote: > > > Hi John, > > > > > > > -----Original Message----- > > > > From: John W. Linville [mailto:linville@tuxdriver.com] > > > > Sent: Thursday, August 27, 2015 6:44 PM > > > > To: Iremonger, Bernard > > > > Cc: dev@dpdk.org > > > > Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs > > > > > > > > On Thu, Aug 27, 2015 at 04:40:35PM +0100, Bernard Iremonger wrote: > > > > > There is a dummy pci driver in the vdev PMD's at present. > > > > > This RFC proposes to remove the pci driver from the vdev PMD's. > > > > > Changes have been made to librte_ether to handle vdevs which do > > > > > not > > > > have a pci driver. > > > > > > > > > > The pdev PMD's should work as before with the changes to > > > > > librte_ether The vdev PMD's which still have a pci driver should > > > > > work as before with the > > > > librte_ether changes. > > > > > > > > > > The following vdev PMD's have had the pci driver removed > > > > > > > > > > bonding PMD > > > > > null PMD > > > > > pcap PMD > > > > > ring PMD > > > > > > > > Any reason there is no patch for the af_packet driver? > > > > > > > > John > > > > > > I have just modified the Intel vdev PMD's. > > > It would be best if the owners of the non Intel vdev's submitted patches > > for their drivers. > > > > What constitutes an "Intel vdev PMD"? I thought these were all part of the > > DPDK project? It seems odd to me for you to pick and choose like this. > > I should probably have written vdev PMD's contributed by Intel. > I am not familiar with the other vdev PMD's and thought it best that they should be modified by their owners/maintainers if required. > These are fairly rote changes, familiarity isn't really needed here, just a willingness to do some minor testing. The right approach is to make the changes to all the drivers, and cc their authors on the patch set so that they can review it. > > > > What is the overall purpose of this RFC? > > The purpose of this RFC is to remove the need for a PCI device driver from Vdev's that that do not use a PCI driver. Removing the PCI driver is implemented in the ethdev changes. I have modified some of the Vdev's to verify that the ethdev changes work. > 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). This patch series just papers over the fact that an ethdev is implicitly a pci device by making the assignment of its pci_dev pointer optional. Whats really needed is a way to associate an ethdev with an arbitrary bus > > What benefit accrues to those vdev > > PMDs that implement this change? What penalty is imposed on those that > > do not change? > > 6Wind have decided that only cleanup patches will be allowed in future for Vdevs that have a dummy PCI driver. Any change in functionality for these Vdevs will not be allowed. > 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. He's not going to stop accepting bug fixes for existing drivers just because it uses the existing initalization infrastructure. I would even go so far as to say new drivers will be accepted for as long as the existing init path exists as it does. 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 Regards Neil > > > > John > > -- > > John W. Linville Someday the world will need a hero, and you > > linville@tuxdriver.com might be all we have. Be ready. > > Regards, > > Bernard. > > >