From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 374DD2BC7 for ; Wed, 9 Nov 2016 11:17:26 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id t79so290740066wmt.0 for ; Wed, 09 Nov 2016 02:17:26 -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=uLo/Z8P2QRIVrBrf85PqL/ZngPj6evv3kOhhwZUBMXY=; b=jcf6FbhAviOVSROZHShyYghCSs4am8Tx4fXs3WX8bMcbDW/IuFt5w5/6wNylz6BEfz 30Yb7mAbzeswbDfTVuw1INKE84gAur0tt0zpylrJFrXj2bC9scZGOY4/XGElRFOass9Q MFwgn+AWsUy0pVOYNcANhNkBiKaaCVIL3q8FHZICHod8wpHJzYn70/n9RI9c5dcH7riY m3fAVJzkt0cQbbLxqV30Nr5BJi7pobNl7ceF3q/TmAdzr6nmjEyUaDPZ/vxqGq/zeHtE n5yQamp8b6U+7j8JnP+wwZNgZhfpjm3TGvW5ZOKlala05pbPlGzJ3hEMZPanSIyi15Cr TAug== 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=uLo/Z8P2QRIVrBrf85PqL/ZngPj6evv3kOhhwZUBMXY=; b=fRqGRmZh/o9fGeZzq5+89hz7gRHzpUNrM6jhT2TojgPav16indOcgZ+otDOGE7lFO1 hFzRWk8LPaCsislGn7lqgjhdkfwZnipgLliipXLdmqODDg06ApAUektj9d3Oj6l7WiiQ 4kTTtpIIIsXAFynzKDeBuTQD7vjpkzZ+UGeDrPU74YWz1UVeSezxL4pJQ772olHbZeIq Vhxy/sdoMqtWMv7m8R65MCz0JLA0svxwXVw5ge+HSeZYoBw7gj9os6QRpq8kSn434WJe Byx4+ROr3iR//bk1oIu4u1Xb8gF/EFTGzMEA51TLuL9MGUk4y9JChuxNzNIlVCTgkRuS 2WHw== X-Gm-Message-State: ABUngvfuljIO++zfDnIrUp07asgmhfv1YRLLvcAZC59hAZ/Vif5N86TyFLDDg0wyTm/61PsO X-Received: by 10.28.67.69 with SMTP id q66mr14966688wma.22.1478686646599; Wed, 09 Nov 2016 02:17:26 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id l67sm15512412wmf.0.2016.11.09.02.17.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 02:17:25 -0800 (PST) From: Thomas Monjalon To: Shreyansh Jain Cc: dev@dpdk.org, viktorin@rehivetech.com, david.marchand@6wind.com Date: Wed, 09 Nov 2016 11:17:25 +0100 Message-ID: <15406748.TzsDne6LfD@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1477657598-826-1-git-send-email-shreyansh.jain@nxp.com> References: <1477581467-12588-1-git-send-email-shreyansh.jain@nxp.com> <1477657598-826-1-git-send-email-shreyansh.jain@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v7 00/21] Introduce SoC device/driver framework for EAL 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: Wed, 09 Nov 2016 10:17:27 -0000 Hi Shreyansh, I realize that we had a lot of off-list discussions on this topic and there was no public explanation of the status of this series. 2016-10-28 17:56, Shreyansh Jain: [...] > As of now EAL is primarly focused on PCI initialization/probing. Right. DPDK was PCI centric. We must give PCI its right role: a bus as other ones. A first step was done in 16.11 (thanks to you Shreyansh, Jan and David) to have a better device model. The next step is to rework the bus abstraction. It seems a bus can be defined with the properties scan/match/notify, leading to initialize the devices. More comments below your technical presentation. [...] > This patchset introduces SoC framework which would enable SoC drivers and > drivers to be plugged into EAL, very similar to how PCI drivers/devices are > done today. > > This is a stripped down version of PCI framework which allows the SoC PMDs > to implement their own routines for detecting devices and linking devices to > drivers. > > 1) Changes to EAL > rte_eal_init() > |- rte_eal_pci_init(): Find PCI devices from sysfs > |- rte_eal_soc_init(): Calls PMDs->scan_fn > |- ... > |- rte_eal_memzone_init() > |- ... > |- rte_eal_pci_probe(): Driver<=>Device initialization, PMD->devinit() > `- rte_eal_soc_probe(): Calls PMDs->match_fn and PMDs->devinit(); > > 2) New device/driver structures: > - rte_soc_driver (inheriting rte_driver) > - rte_soc_device (inheriting rte_device) > - rte_eth_dev and eth_driver embedded rte_soc_device and rte_soc_driver, > respectively. > > 3) The SoC PMDs need to: > - define rte_soc_driver with necessary scan and match callbacks > - Register themselves using DRIVER_REGISTER_SOC() > - Implement respective bus scanning in the scan callbacks to add necessary > devices to SoC device list > - Implement necessary eth_dev_init/uninint for ethernet instances These callbacks are not specific to a SoC. By the way a SoC defines nothing specific. You are using the SoC word as an equivalent of non-PCI. We must have a bus abstraction like the one you are defining for the SoC but it must be generic and defined on top of PCI, so we can plug any bus in it: PCI, vdev (as a software bus), any other well-defined bus, and some driver-specific bus which can be implemented directly in the driver (the NXP case AFAIK). > 4) Design considerations that are same as PCI: > - SoC initialization is being done through rte_eal_init(), just after PCI > initialization is done. > - As in case of PCI, probe is done after rte_eal_pci_probe() to link the > devices detected with the drivers registered. > - Device attach/detach functions are available and have been designed on > the lines of PCI framework. > - PMDs register using DRIVER_REGISTER_SOC, very similar to > DRIVER_REGISTER_PCI for PCI devices. > - Linked list of SoC driver and devices exists independent of the other > driver/device list, but inheriting rte_driver/rte_driver, these are > also part of a global list. > > 5) Design considerations that are different from PCI: > - Each driver implements its own scan and match function. PCI uses the BDF > format to read the device from sysfs, but this _may_not_ be a case for a > SoC ethernet device. > = This is an important change from initial proposal by Jan in [2]. > Unlike his attempt to use /sys/bus/platform, this patch relies on the > PMD to detect the devices. This is because SoC may require specific or > additional info for device detection. Further, SoC may have embedded > devices/MACs which require initialization which cannot be covered > through sysfs parsing. > `-> Point (6) below is a side note to above. > = PCI based PMDs rely on EAL's capability to detect devices. This > proposal puts the onus on PMD to detect devices, add to soc_device_list > and wait for Probe. Matching, of device<=>driver is again PMD's > callback. These PCI considerations can be described as a PCI bus implementation in EAL. > 6) Adding default scan and match helpers for PMDs > - The design warrrants the PMDs implement their own scan of devices > on bus, and match routines for probe implementation. > This patch introduces helpers which can be used by PMDs for scan of > the platform bus and matching devices against the compatible string > extracted from the scan. > - Intention is to make it easier to integrate known SoC which expose > platform bus compliant information (compat, sys/bus/platform...). > - PMDs which have deviations from this standard model can implement and > hook their bus scanning and probe match callbacks while registering > driver. Yes we can have EAL helpers to scan sys/bus/platform or other common formats. Then the PMD can use them to implement its specific bus. I know that David, you and me are on the same page to agree on this generic design. I hope you will be able to achieve this work soon. The goal is to be able to plug a SoC driver in DPDK 17.02 with a clean design. My advice to make reviews and contributions easier, is to split the work in few steps: - clean PCI code (generalize non-PCI stuff) - add generic bus functions - plug PCI in generic bus abstraction - plug vdev in generic bus abstraction - plug the new NXP driver Thanks