From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v9 00/25] Introducing rte_driver/rte_device generalization Date: Thu, 8 Sep 2016 09:49:29 -0700 Message-ID: <20160908094929.22d21b2f@xeon-e3> References: <1466510566-9240-1-git-send-email-shreyansh.jain@nxp.com> <1473257297-7221-1-git-send-email-shreyansh.jain@nxp.com> <20160907114004.4a218155@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: , To: Shreyansh Jain Return-path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by dpdk.org (Postfix) with ESMTP id BB5025686 for ; Thu, 8 Sep 2016 18:49:19 +0200 (CEST) Received: by mail-pa0-f49.google.com with SMTP id b2so19054575pat.2 for ; Thu, 08 Sep 2016 09:49:19 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 8 Sep 2016 12:40:08 +0530 Shreyansh Jain wrote: > > Overall I like to see the clean separation. > > Are you sure you removed as much as possible from PCI? > > I am not very sure of what you mean. > > If you are referring to whether all PCI PMDs have been taken care of, I > think they are. Only issue being I can't test all of them functionally. > I have some steps provided by Thomas which can help me compile test these. > > Or, if you are referring to whether PCI drivers have been completely > disconnected from existing EAL (and converted to above linkage), I think > yes. > > Key change that still remains is delinking eth_driver from PCI type and > using a more generic approach where eth_driver (or rte_eth_driver, after > name change) can be of any type - PCI, Virtual, SoC etc. > > > I wonder of global PCI device list is needed at all if you now have list of all devices. > > > > I think yes. There are separate lists for all device types which helps > keep the EAL code free of type checks. But, functionally it doesn't make > that big a different between a common or specific list. > I am in favor of separate lists of each rte_xxx_device/driver type - > other than a global list (which is not actually being used, for now). I was just concerned that doing bookkeeping on multiple lists creates more possibilities for bugs where error unwind paths don't match.