From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 7F9311094 for ; Wed, 18 Jan 2017 00:04:38 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id r126so222297146wmr.0 for ; Tue, 17 Jan 2017 15:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=7nlc2hIsqyGmkG/ejpVeQIEPa3Ak0WbCNmNTUb+IKuU=; b=nkF6W0JJiBNvr4/zUnct/kJNbD7QTQJnzu6ySC9h196hlrTPK+nOyu7x3LYhl4nsPn T8o/pLYTQBZSLkD+OHTdltiXYy7Uvw/mU8/7KHBeodbh8T+uw13s+aZY1Wg6B8MIV68o J3AIiSrdKwXQed3bgmf8YL863WU7z5LyhjZhZPpDP5Og5ehJGsX78CGWEppAx1CPs6lm TIUr6jmRTwz05kmS7zXMB7lhUUUrYwKJNwt9Hssjy+BxoOe230LHDAmIJP/eogRyzlz9 SbwTPk7C8GvcSUrN4YZyBgmE2rMqgH7lHLiBSdoJs9XIDPzM+OFAk2VPsDMJ6yZwHcIP s8gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=7nlc2hIsqyGmkG/ejpVeQIEPa3Ak0WbCNmNTUb+IKuU=; b=As5Uao3nC9c2MBVbN1AHMYPCxU4nc9Fw4ilBi9AdofFVvmnz0VQkEYeskdYrytoYGl Gyw13gBnHbbrvPbQcCe+eA4DffPoO6ngEvXs5/67ohnkyaKIFD5cZF3ZQ8GZKqguJy2X xDTLvr7PfNvWUqgquK15gJrGKiaGB6ErPO/tOuNmqBo7fZUG3NWW3IcEbO522jDZjdR2 nqdC1Rd6QYpufxG4olZW2wx1xPFAODEf3HV9hdjbh/Rg/+EYbhPw/j/765zNmG/OMU47 +aaGgWy4XuERTis6kIyZOFMVCBB73qKWafKAjwsO+xOAMGR9P0cRsjZ/HSnXZXNpiiwd VX/Q== X-Gm-Message-State: AIkVDXLptnhV3htv37hN0ZfGmKCkY1QDCmmzz8e8wEbogU7zx6fXrzE6kdPIn/XaPWrWC7Ey X-Received: by 10.28.111.75 with SMTP id k72mr377535wmc.39.1484694278274; Tue, 17 Jan 2017 15:04:38 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 135sm40340248wmh.14.2017.01.17.15.04.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 15:04:37 -0800 (PST) From: Thomas Monjalon To: Shreyansh Jain , Ferruh Yigit Cc: david.marchand@6wind.com, dev@dpdk.org Date: Wed, 18 Jan 2017 00:04:36 +0100 Message-ID: <1954236.zh4WF62xzI@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <0d943156-b700-3964-3e4f-9d8083ebd783@nxp.com> References: <1484581107-2025-1-git-send-email-shreyansh.jain@nxp.com> <4721b3d8-7374-76e8-d859-61c86a88a314@intel.com> <0d943156-b700-3964-3e4f-9d8083ebd783@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 5/8] eal: introduce bus scan and probe in EAL 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, 17 Jan 2017 23:04:38 -0000 2017-01-17 10:33, Shreyansh Jain: > On Tuesday 17 January 2017 01:28 AM, Ferruh Yigit wrote: > > On 1/16/2017 3:38 PM, Shreyansh Jain wrote: > >> +/* Add a PCI device to PCI Bus */ > >> +void > >> +rte_eal_pci_add_device(struct rte_pci_bus *pci_bus, > >> + struct rte_pci_device *pci_dev) > > > > I think more generic approach from previous version was better > > (rte_eal_bus_add_device()), but I guess they sacrificed for less > > modification. > > There was a lot of offline discussions after the reviews were posted > until v5. From the gist of it, I gathered that smaller 'specific' > changes are preferred as compared to complete generic approach without > an upfront usecase. Yes I discussed (a lot) this approach with Shreyansh. > Also, this change became irrelevant once I moved out the device/driver > lists from rte_bus to rte_xxx_bus. This is inline with existing model of > (rte_pci_device->rte_device, rte_pci_driver->rte_driver, > rte_pci_bus->rte_bus) and having pci_device_list/pci_driver_list private > to PCI itself. > > I guess what is going to happen is that in near future when buses start > moving to drivers/bus/*, this kind of generic layer would come in. I think there will be no use case requiring a unique list of all rte_device(s). Being generic and wrapping stuff with abstract classes is not always a benefit. That's why, this version is more focused on specialized objects. Experience with this layering will tell us wether it is a good design or not.