From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) by dpdk.org (Postfix) with ESMTP id 0443CFBDD for ; Tue, 20 Dec 2016 18:16:35 +0100 (CET) Received: by mail-pg0-f51.google.com with SMTP id g1so35634416pgn.0 for ; Tue, 20 Dec 2016 09:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wK8IScQArJRpdAGxhW06Cm+1vLNG5cM8Ee+WjiGoPgc=; b=rbN5yvSleK61Z7nqTkAFoEezB7HDeMicPqY1NK62hKvwdxvONp/nVpjfjaLOUFC3Z2 kFJe2wuM7WVIcLX3ooAZ/L8BOFGhT4sUsoJp8L2kA9y0p4Mj2KUaimvBeZVSshEmT+4i p+kg3uk9DqmrIYEkuPla6qdkpcnrH8x7JT8CP3oDPZ38MZQ2xmS3lIPSSlsLMMARoivj mC8QfRrmbowu+8Xj5z00jUOYbMmptuMIUeCwVYc3iNGH24SLrXyW1pvVEyzsH3+uNysu nv+V5VEEphXp1EzPEJxfANsaqweXYFIjgpsNMJS+P7NAIbPgoUV8jTF86FGvbgQIy/ns ZyTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wK8IScQArJRpdAGxhW06Cm+1vLNG5cM8Ee+WjiGoPgc=; b=ky2T0KvSzQ1OLosfXfHrlNAuzaBvjj4XM1zV+FfxB1Qf8+8kXRI9D4AZ2nqI+7JrsM 3GaTI9YowJ9Q608q6RWZ/2n4uL0qMp3A1rVKmDC6VsBGgSbzzXHV2ZSGc+aujC3YrMuW VXJ3lC83wyN6QfHsEgd8NK9SnyUnLGndly/eRgvs4eqxMpxuggLqnPPjoS2mVa63gCp1 v9ID0bv+3k+UEnX0j1hFnRCGeneZQNtyOpna/rmOF2EXsF/CB+lCrquT2DYQdioGVy7E Af3FWXjrjAWp7JxAud6bvAXaEzYa1v09W/dO+Qe4/KzcBOQDHFgUn6n0eKKhY8PoDUZc czGQ== X-Gm-Message-State: AIkVDXKBEEVnk4yVikXCLugFiIdQw2KA2HFEneXKurstFVDKkGegRw3NuAKPeho06Cbd3g== X-Received: by 10.99.209.5 with SMTP id k5mr509401pgg.145.1482254195222; Tue, 20 Dec 2016 09:16:35 -0800 (PST) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id a68sm40852589pgc.31.2016.12.20.09.16.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Dec 2016 09:16:35 -0800 (PST) Date: Tue, 20 Dec 2016 09:16:28 -0800 From: Stephen Hemminger To: Shreyansh Jain Cc: , Stephen Hemminger Message-ID: <20161220091628.49b56b7e@xeon-e3> In-Reply-To: <3017fb08-e1f2-376a-e748-7151810b440e@nxp.com> References: <20161219215944.17226-1-sthemmin@microsoft.com> <20161219215944.17226-5-sthemmin@microsoft.com> <3017fb08-e1f2-376a-e748-7151810b440e@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 04/13] eal: introduce driver type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 17:16:36 -0000 On Tue, 20 Dec 2016 12:46:17 +0530 Shreyansh Jain wrote: > On Tuesday 20 December 2016 03:29 AM, Stephen Hemminger wrote: > > Since multiple buses and device types need to be supported. > > Provide type field in driver. > > --- > > lib/librte_eal/common/include/rte_dev.h | 15 ++++++++++++--- > > lib/librte_eal/common/include/rte_pci.h | 1 + > > lib/librte_eal/common/include/rte_vdev.h | 1 + > > 3 files changed, 14 insertions(+), 3 deletions(-) > > > > diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h > > index e5471a22..3f4e26e6 100644 > > --- a/lib/librte_eal/common/include/rte_dev.h > > +++ b/lib/librte_eal/common/include/rte_dev.h > > @@ -144,12 +144,21 @@ void rte_eal_device_insert(struct rte_device *dev); > > void rte_eal_device_remove(struct rte_device *dev); > > > > /** > > + * Type of device driver > > + */ > > +enum rte_driver_type { > > + PMD_VIRTUAL, > > + PMD_PCI, > > +}; > > So the expectation is that if a new device type is introduced (anything > other than virtual or PCI), this enum is expanded? > > Broadly, we have two possible ways being discussed on ML for device > relationship with PMD/APIs: > > 1. the way you have done: each device belongs to a particular type (enum > rte_driver_type) and based on its type, operations would be performed on > it (using conditional operators, for example). We continue to have a > common device list containing all type of devices. It is more about providing feedback to applications in info_get which is the only place they should care. > > 2. disassociating the device (rte_device) completely from its type and > basing it on a Bus type. So, we have separate buses for each device type > and hence no need for separation of logic based on device type. > > I think implementation similar to (1) existed before it was removed in > 6751f6de. > > I have an (obvious) inclination towards (2) because that helps plugging > in more drivers/device types without expecting the contributor to change > the EAL - however trivial the change is. > The difference is that virtual devices don't actually live on bus. So it is really a property of the device not a bus per say.