From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.161.182]) by dpdk.org (Postfix) with ESMTP id 59CCB3238 for ; Fri, 11 Nov 2016 02:58:03 +0100 (CET) Received: by mail-yw0-f182.google.com with SMTP id r204so2128615ywb.0 for ; Thu, 10 Nov 2016 17:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vfw2unb/6D/Bi0cqmbjhfYcT1JoTTRnUA40F+coGd64=; b=TkoCd0+0mqiUMbqZdQiVCbY9kG4k+RZGaeJEd9FWOXdchp0GCTdC74xMhYrMkPJc+E 2D90veIuxvfeK+0c2lC4pijwHg8GbvyO5GS2WG8VvddYm/X95Q6Mckx23mYiapa1o84E Wd/ve/rNGqanfSzaI7PuAIAQvJgUkEjThutVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vfw2unb/6D/Bi0cqmbjhfYcT1JoTTRnUA40F+coGd64=; b=Y5UhjP5reXxUH1jgSZecUbVaiGJcHN1qWfwwHvr8unvx3KfXpd+IxBOZCxU6n8hodK goG6E3u5zDijUrt7f3ezfbUnfC+wz1G4g9T+xdTufgpyJuo39XAgaWSVyXf3658oxsj9 bj/1tJyAwPeNqZ3/2ReBrck/4GHgvRL5qJf+LcCIMOPUtfJgXqUIuIa4stWQOeP2VD6q dIljuHKFPNgXPoNl2MZXNxRTjP9tG4WVpaBwvBhnl0I5PBp8c7WrKnUbluY/DvnrgBR8 r04j7fKfbw52cdD4hoU0s692sYYDeNeFrzcEF3OPuICwsxeqjmgUBQAIHUfYTXlc0L22 h9Lg== X-Gm-Message-State: ABUngvdYanOQQadCmRjwLXKb5biEBe7phOKyXaoUQzAHCup+FkX/4orl1Rs6hzn9l4Pm+KR0NMb1/QsqRs5W5Q5+ X-Received: by 10.129.167.3 with SMTP id e3mr787162ywh.60.1478829482621; Thu, 10 Nov 2016 17:58:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.171.48 with HTTP; Thu, 10 Nov 2016 17:58:02 -0800 (PST) In-Reply-To: <1506578.S1InCtPeL4@xps13> References: <1477581467-12588-1-git-send-email-shreyansh.jain@nxp.com> <9c727b8d-2fc1-49f6-04f4-33a847b2c915@nxp.com> <1506578.S1InCtPeL4@xps13> From: Jianbo Liu Date: Fri, 11 Nov 2016 09:58:02 +0800 Message-ID: To: Thomas Monjalon Cc: Shreyansh Jain , dev@dpdk.org, Jan Viktorin , David Marchand Content-Type: text/plain; charset=UTF-8 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: Fri, 11 Nov 2016 01:58:03 -0000 On 10 November 2016 at 17:26, 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. Agree. rte_eal_soc_scan_platform_bus can be the scanning func for platform bus.