From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 69C63914 for ; Tue, 7 Mar 2017 14:05:17 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id t189so4224047wmt.1 for ; Tue, 07 Mar 2017 05:05:17 -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=8uYgcXXW6xnWud4k2AON8oe3YTL0h1Tw2Kl7CSOwYdQ=; b=m1jC0E8lk0IZBG5HyzByXq0ceYHR4RI3kvrVtGvTafzbpiMD9stG0Kd8hV5CDCnGu0 uWhpSPQv/2Cal2OSaiSk9rbO1F/vEiSCK2MrY7ZaaXTl/BdxLwP+DFUs60hBUecvIMza EZrAwFoK29XVpA6FfbbkS3kFCTSg4F8mXeP8ZtjSzJfQUtSGy3GaVsjxcAPJFHet1UBL L7kPbXpZUoYAqj2mLZs8Jt7CnKLKq4ystbxA0mgmKhC8FWEp4WzfpZNhF47pKnHzwzkG ucXdGRt4C3qgeMV9Szoy0sXZvcz2tLHk2XA1DP8zm9xvY8vfYOitlpPj05nJwGbQuv/b 9Zig== 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=8uYgcXXW6xnWud4k2AON8oe3YTL0h1Tw2Kl7CSOwYdQ=; b=G/nfbaKEIyx22b1/JXYLAVPhunlDOZmWHrtRFBhzwE/Eshmo10vDAWRexormcWMTi0 cOItExaRXBxtCMXOgwXmEUwGJ22omAMltIAGUgJPwDk3kORL8CBz/+ffFQhffjDPiRIz PGWBm8VkLelybUgtVIqEBu+LYcMuDRyMB6W+N84y5VI2Otv6t0fmt+wU1lTSk4tRy5m3 jKTtlrc7jw7JOu9MdeiqssrtHoACutfnZaS2uEF9hGnYu89/mE+r0C9DRZh+oM83x2hu G6/k3VGpKWIlcE+Esn8r2SIWDSV9MHkoDM+zuFE9FUm2tF8EANTZO4KeidwqGLgSUdyt SvBg== X-Gm-Message-State: AMke39nyCPvRlYScAjpYMU2VBaNZI2ynpr2tKDkWopWPpJbfqrbP8wTPAmTOnHV1I2nLQnyL X-Received: by 10.28.128.209 with SMTP id b200mr799197wmd.140.1488891917089; Tue, 07 Mar 2017 05:05:17 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id q5sm31259851wrd.32.2017.03.07.05.05.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 05:05:16 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson , "Chen, Jing D" Cc: dev@dpdk.org, "Liang, Cunming" , "Rogers, Gerald" , "Wiles, Keith" , "Mcnamara, John" Date: Tue, 07 Mar 2017 14:05:15 +0100 Message-ID: <496309275.NbCXWNhGLl@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170307111231.GA254436@bricha3-MOBL3.ger.corp.intel.com> References: <1488427438-13646-1-git-send-email-jing.d.chen@intel.com> <4341B239C0EFF9468EE453F9E9F4604D3C5FEB70@shsmsx102.ccr.corp.intel.com> <20170307111231.GA254436@bricha3-MOBL3.ger.corp.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: Tue, 07 Mar 2017 13:05:17 -0000 2017-03-07 11:12, Bruce Richardson: > On Tue, Mar 07, 2017 at 10:34:06AM +0000, Chen, Jing D wrote: > > From: Thomas Monjalon > > > > +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. > > > > First of all, let us try to imagine what is the safe status for device before apps > > intending to download some image to it - apps wouldn't operate on the device, > > any behaviors like configuring registers, receive/transmit data may impair the > > device or make the download failed. > > Following first answer to prevent app accessing device during image > > downloading, how can we achieve that? Detach drivers with device is a smart > > idea, right? But the problem is how can apps use prgdev API to download image > > after all drivers detached with the device? > > So, the final question is how can we just detached others driver except prgdev > > one? I can't find answer in current DPDK framework, that's why I'd like to introduce > > bind/unbind functions to detach other drivers from the device. > > > > I'm open to this problem. If any suggestion or mechanism can help on it, I can > > remove these 2. > > > > BTW, not all devices or image download actions need the device to detach the > > device, depending on hardware implementation. Thanks for the explanations. It sounds interesting. > > > > +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. > > > > For programmable Ethernet device, it's not truce. But for FPGA, it's. When FPGA > > is produced, the device ID indicate what model it is and won't be changed > > anyway, even being reprogrammed. It used some not-generic mechanism, like > > AFU id to distinguish the personalities. So, for FPGA, a prgdev driver can be used > > as primary driver to identify personalities and then register to specific devices. > > Sounds like we would need an FPGA bus driver in that case. I think that > would be a better solution than having a specific device driver loading > other drivers. Good suggestion. What do you think of a FPGA bus to consider more parameters than the PCI BDF when matching a device driver? How other systems manage the drivers for a FPGA-programmed device?