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 DC294952 for ; Mon, 6 Mar 2017 16:26:39 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id v203so4968427wmg.0 for ; Mon, 06 Mar 2017 07: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=ylz2h626v2cbwJ4MftloN9I+Zu08+5iIoGNpHL0SQA8=; b=sgWnO1gl5DcRdfmbmJm/AGwvSExjzr4N20Ja6DBwySSdteEgQG58L96U8L/5D/mgYC HJsjMJbkZW7AW2cJwZXNOyG1x8KTBIamYJewPKTCWNSqPKinEzEw6E6awL3q3pgTw7JH rTHIDTYzgNPva4o2XjsVw1Vh7WDXKBBGSDyfuq22xTvt+P5aSmUup0QuaY4Dm55wmt4C r9zyT2oE02eXB/t5R3gr/YkxA4dN9pJVqsoRi3d7hRTw51tHHA3hdyos5krZ49Kwvv54 76EIaU0v41++IJKNba2GF2d79itgJirTtmESQXSlOW9WWCmoE3s4lYnXvwwfJ6a++geI yT/Q== 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=ylz2h626v2cbwJ4MftloN9I+Zu08+5iIoGNpHL0SQA8=; b=UXX76WTA4TbcvmkjqX2JT/al7VrllBhwpUvFR6UI9MSV+ucN1HUbIRumjkh0oGhb7J zYO26XW/ZwJWlX6mGCJaweoK2Jb9PQEQwHwNzTkwzb6W+AY1NFmZEHgboXu6TgDsW24A 5CjhN1+U1Zyjk+5/7GvD3Q8XjLRZ92VkrlcLcPebhywPqBY3PSyHSuwG623btMTtjQol PMCQlY2ahT0JzNWGUGQQpSYw1B/SIiPuQ2NzX4SUVXlY2kHbP2kxqsi1Y8YdFeDVH+l0 EX9z/EZ4BWblX9VTnd2KWG3r5LCfX6Rd/VJjnSqIyG1yChGGKkJ3cqImTpxv5ZBEpYwQ wNgA== X-Gm-Message-State: AMke39lji9Uxx9eKgRPZY1IWJWt1jWjyGulKeiQyUXoV2Az7nhHUYM1WqtJFYZDWPNGuN4k0 X-Received: by 10.28.128.209 with SMTP id b200mr14413580wmd.140.1488813999436; Mon, 06 Mar 2017 07: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 x193sm15201083wme.23.2017.03.06.07.26.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 07:26:38 -0800 (PST) From: Thomas Monjalon To: "Chen Jing D(Mark)" Cc: dev@dpdk.org, cunming.liang@intel.com, gerald.rogers@intel.com, keith.wiles@intel.com, bruce.richardson@intel.com, John Mcnamara Date: Mon, 06 Mar 2017 16:26:37 +0100 Message-ID: <1488825967.6DAzsKhpGM@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1488427438-13646-7-git-send-email-jing.d.chen@intel.com> References: <1488427438-13646-1-git-send-email-jing.d.chen@intel.com> <1488427438-13646-7-git-send-email-jing.d.chen@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 6/6] doc: introduction to prgdev 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: Mon, 06 Mar 2017 15:26:40 -0000 2017-03-02 12:03, Chen Jing D: > +Overview > +======== I think the first review pass of this series must be focused on the overview you give here (thanks for the detailed explanations). I'll try to sum up while commenting. [...] The target is programmable devices. > +The major purpose of prgdev is to help DPDK users to load/upgrade RTL images > +for FPGA devices, or upgrade firmware for programmble NICs. This is a control plane feature. You want to have it in DPDK to allow dynamic programmation while running the device, right? [...] > +When the set of APIs is introduced, a general question is why we need it in > +DPDK community? Good question :) [...] > +Any devices, having the capability to store/load a piece of info to/from > +the deivce then changed hardware behavior, and applicable to prgdev programming > +model, could be registered as a prgdev device. > + > +The device can be programmed (dynamic) within DPDK or have been prior programmed > +(static) prior to a DPDK application being launched. [...] > +Besides the simple API to upload/download image, the prgdev also introduces a > +mechanism internally to switch drivers and register/unregister device on the > +fly. With this mechanism, apps can use the programmable device, unbind other > +personalities on demand, then program it and bind it back with new personalities. > +Apps can follow below examples to simply complete the whole process. I disagree about the specific bind/unbind for prgdev. We must improve binding inside DPDK for every devices. > +Note that bind/unbind actions are different concept from that a whole device > +attach/detach. For example, ``rte_eal_dev_detach()``, which will try to detach the > +drivers with device and remove the whole device from specific class of devices > +(ethdev, for example). Then, the whole device is invisible until a new 'probe' > +is activated. I do not understand. > +During the whole procedure of image upload/download, prgdev handler is always > +valid and apps can use it operate on programmable device. The reason why unbind > +is necessary is it may break the hardware when programming is in progress while > +other functions are active. Using programmble NIC as an example, it's a little > +impossible to receive/forward packets for hardware while updating firmware. In > +this case, apps need to detach ethdev function before firmware upgrading. Again, > +prgdev handler is still valid, it's function-level detach, different from > +device-level detach. After finishing image download, original function needs to > +attach back, either use same or different drivers, depends on personalities > +changed or not. For a programmble NIC, the driver may be the same. For FPGA, it > +may not, see below examples to get more details. If the personality of the device is changed, it must be seen as a new device from e.g. the ethdev point of view, while keeping the same prgdev device. In other words, a device can have several interfaces at the same time (ethdev, cryptodev, eventdev, prgdev, whatever). I think we can dynamically create/destroy some interfaces while keeping track of the underlying device. > +Another reason to provide bind/unbind action is programmble devices, like FPGA, > +are not identified driver by 'vendor ID' and 'device ID', they might not be > +changed in all the ways, even FPGA is fully programmed. So, it depends on > +internal mechanism of FPGA, not 'vendor ID' and 'device ID' to identify proper > +drivers, either a register value or signature, depending on FPGA hardware > +design. In this case, EAL or other bus driver doesn't have the capability to > +identify proper driver for FPGA device. With prgdev introduced, while FPGA is > +always a prgdev, FPGA can use prgdev as primary driver, to find proper function > +driver. You mean prgdev should help the bus layer to map the right driver interface? It looks weird and dangerous. The standard way to identify a PCI device is to look at its IDs. Other unknown methods must be strongly discussed.