From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: [PATCH v7 11/21] eal/soc: implement probing of drivers Date: Fri, 11 Nov 2016 11:34:03 +0530 Message-ID: References: <1477581467-12588-1-git-send-email-shreyansh.jain@nxp.com> <9c727b8d-2fc1-49f6-04f4-33a847b2c915@nxp.com> <1506578.S1InCtPeL4@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: Jianbo Liu , , Jan Viktorin , To: Thomas Monjalon Return-path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0060.outbound.protection.outlook.com [104.47.36.60]) by dpdk.org (Postfix) with ESMTP id 498AD2BDF for ; Fri, 11 Nov 2016 07:01:50 +0100 (CET) In-Reply-To: <1506578.S1InCtPeL4@xps13> 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 Thursday 10 November 2016 02:56 PM, Thomas Monjalon wrote: > 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. > In the current model, without a bus like object, this can only be implemented as a hack. This is because: - If each driver has its scan, some of them (those on a common bus) would have their scan nullified - Then, EAL would initiate the scan on their behalf. (rte_eal_init) - Whereas, for those drivers which are 'special' scan, EAL would have to call each driver's scan. - This selection is manual code change (nullifying the scan function). - And then, EAL would have various 'generic' scan's chained together other than driver->scan(). A cleaner model would have been that EAL always calls the drivers->scan(). Obviously, this issue vanishes as soon as we have the bus->scan() like implementation where a bus would represent multiple devices/drivers. _________ Shreyansh