From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id A025A5599 for ; Thu, 10 Nov 2016 10:26:39 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id f82so18498955wmf.1 for ; Thu, 10 Nov 2016 01:26:39 -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=a6kVUFQoL8vvSuMJZvLEZLQ4TdwYIEB6csBJW1hRiAw=; b=UxlsCOOio+HvvvOxtH4EFQGyIlVl1ZfPu9hlr2/27Gn5fuXthjTIC0xnoedxAJrKIW P0oD9HPP5YBIzmGpqosmk+dfvomY/BQQae4nKpBD5kZURH080ie2sOFnYsfSXqwgoUNK Jqq1l2TbMj2jsZTUPjmGdJQJytjqPV3OPnxrFwac0WROFYr5/mmNyzuqD/Bd8d+GGUvX Yei016BxdnK7VWsdpYOECNxmFzZdoPj75WrmXBppLM4tBfsNFrxAFmlSnzoU9wh0lE7X 6Ee6clDDFYvAtsR/LvcFW3m1ETSz5M9MG9216pQ0WfPZC4nAFXRycJa8GoH3UlXqknod gZbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=a6kVUFQoL8vvSuMJZvLEZLQ4TdwYIEB6csBJW1hRiAw=; b=fmpbtWMx8BOI1JRRB1N4fn/CWLdSeDRbVOai8FyUJIiAKr4XsIQ+KWruMGohoCwkz9 Yw/u2KN3PS4wvLd97xP7r0vgAT+S4lLmsGFAkUcf9fzBf0n7YutfKBw9UaWHEvdDMwBb VpwH1nb2PEsYWZINuFn+/2nOQDq7MQ07EwdnCXZJkWsTfYu0+UQAngEZ3V/jDybIFnzn LegXYyeF9c2gbGOK1SUzfDbWjsgiANNP2bzI03XK1pUEzUdhXGdkoMCTYoQabDzguQjR bvaHvfYZ4Wm5jb8i5Tr1mM/Bkg8g6HkAIi5DDxgGgY8kz3cwEe8qvs0EUrzOVazaB0AR DuGA== X-Gm-Message-State: ABUngve4xnUaEICC+sCyUa38ny0AOupFOJWk1bzWUel+fvk33iFjVGp/fIUorDJ8+DqPCH14 X-Received: by 10.194.60.195 with SMTP id j3mr3375511wjr.149.1478769999284; Thu, 10 Nov 2016 01:26:39 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id f76sm5065372wmd.15.2016.11.10.01.26.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2016 01:26:38 -0800 (PST) From: Thomas Monjalon To: Shreyansh Jain Cc: Jianbo Liu , dev@dpdk.org, Jan Viktorin , david.marchand@6wind.com Date: Thu, 10 Nov 2016 10:26:37 +0100 Message-ID: <1506578.S1InCtPeL4@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <9c727b8d-2fc1-49f6-04f4-33a847b2c915@nxp.com> References: <1477581467-12588-1-git-send-email-shreyansh.jain@nxp.com> <9c727b8d-2fc1-49f6-04f4-33a847b2c915@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v7 11/21] eal/soc: implement probing of drivers 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: Thu, 10 Nov 2016 09:26:39 -0000 2016-11-10 14:40, Shreyansh Jain: > On Thursday 10 November 2016 01:11 PM, Jianbo Liu wrote: > > On 10 November 2016 at 14:10, Shreyansh Jain wrote: > >> On Thursday 10 November 2016 09:00 AM, Jianbo Liu wrote: > >>> I'm still not sure about the purpose of soc_scan, and how to use it. > >> > >> > >> For each device to be used by DPDK, which cannot be scanned/identified using > >> the existing PCI/VDEV methods (sysfs/bus/pci), 'soc_scan_t' provides a way > >> for driver to make those devices part of device lists. > >> > >> Ideally, 'scan' is not a function of a driver. It is a bus function - which > >> is missing in this case. > >> > >>> If it's for each driver, it should at least struct rte_soc_driver * as > >>> its parameter. > >> > >> > >> Its for each driver - assuming that each non-PCI driver which implements it > >> knows how to find devices which it can control (for example, special area in > >> sysfs, or even platform bus). > >> > > > > Considering there are several drivers in a platform bus, each driver > > call the scan function, like the rte_eal_soc_scan_platform_bus() you > > implemented. > > The first will add soc devices to the list, but the remaining calls > > are redundant. > > Indeed. This is exactly the issue we will face if we try and move this > scan/match logic to PCI - all devices are identified in one step. > > There is a difference in principle here: > A SoC device/driver combination is essentially focused towards a single > type of bus<->devices. For example, a NXP PMD would implement a scan > function which would scan for all devices on NXP's bus. This would not > conflict with another XYZ SoC PMD which scans its specific bus. > > There is caveat to this - the platform bus. There can be multiple > drivers which can serve platform bus compliant devices. First > PMD->scan() initiated for such a bus/device would leave all other scans > redundant. > > More similar caveats will come if we consider somewhat generic buses. At > least I couldn't find any interest for such devices in the ML when I > picked this series (from where Jan left it). > > Probably when more common type of PMDs come in, some default scan > implementation can check for skipping those devices which are already > added. It would be redundant but harmless. If several drivers use the same bus, it means the bus is standard enough to be implemented in EAL. So the scan function of this bus should be called only once when calling the generic EAL scan function.