From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by dpdk.org (Postfix) with ESMTP id D8AE0C3E0 for ; Wed, 21 Oct 2015 17:57:07 +0200 (CEST) Received: by oiad129 with SMTP id d129so31407245oia.0 for ; Wed, 21 Oct 2015 08:57:07 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=IXggydGxzsHM/cqr0z0/xRIUQwPm6bsBpT+yFSPSY64=; b=ibsGp8df+hElv265aaktJZ2TiO0+9Uvn2r0Ubp5cP6kcCEFjioXFUHDbuEej6K8c3A 51BEElRh7px8zFadJ6uOgnX1ueRfFFK4Xxdjm1RtvjLqT27dprMXrrYj0YMSYeooGHEm dTt9F7cm1G8mPnBRLgtfclQ7L0UFj1mcm6cF8anw3sqnuoLFGs/6gIaHxyGGS6xXRcsu HbWOxTrmFeU4vl0E9UqVZxQGngKgtS3w82oYxicF0mH+yRGTDaBlfQaGNcjR9+qZY/x4 dlmVglFnF4oHi3MRkSI72Rlc/FA0TJcwuHwh3jrjtL4f6W0cF5f8762mRQBLi8oVvcwo 6p3A== X-Gm-Message-State: ALoCoQkn9+hp86aMLJLUBSp0V4PNppkHyLOVzR2XhpnABbJW6dMEf6zxojLG+HGLl4Ym59iTlLL7 MIME-Version: 1.0 X-Received: by 10.202.49.215 with SMTP id x206mr6457168oix.81.1445443027334; Wed, 21 Oct 2015 08:57:07 -0700 (PDT) Received: by 10.76.11.10 with HTTP; Wed, 21 Oct 2015 08:57:07 -0700 (PDT) In-Reply-To: <2304404.uKjJZErY2S@xps13> References: <1444992324-5504-1-git-send-email-alejandro.lucero@netronome.com> <2304404.uKjJZErY2S@xps13> Date: Wed, 21 Oct 2015 16:57:07 +0100 Message-ID: From: Alejandro Lucero To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev Subject: Re: [dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card 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, 21 Oct 2015 15:57:08 -0000 Wow! This is just what we (likely) need. We could have that support in our BSP but this is something yet to be approved. Setting per VF pci bus master and pci mask should also be added to BSP. Current PMD submitted would need nfp_uio by now for LSC interrupt support. As I said, this is not critical so NFP devices could be used with that limitation. My concern is tests without using nfp_uio have not been done, just some minor work for proof of concept. I understand interest for not having another UIO driver does exist. We could maintain an external nfp_uio by now till either we get rid of it or we definitely find out it is really needed. any chance to accept nfp_uio by now? Thanks On Wed, Oct 21, 2015 at 4:25 PM, Thomas Monjalon wrote: > 2015-10-21 15:39, Alejandro Lucero: > > On Wed, Oct 21, 2015 at 6:24 AM, David Marchand < > david.marchand@6wind.com> > > wrote: > > > Please, can you elaborate on the need for (yet another) uio driver, > rather > > > than make igb_uio work with your hardware ? > [...] > > I have been looking at the possibility of getting rid of nfp_uio. The > fact > > is our PMD can work without it, both for the PF and VF (not the PMD > version > > already submitted but one under development). The PF support requires > not > > using UIO at all, because the device is attached to the BSP driver. The > > only problem with this approach is we do not have support for interrupts, > > what is not critical (I can see other PMDs not having support for Link > > Status Changes) but we do not like it as programs can register callbacks > > for these interrupts which would not work at all. > > > > Interrupt support could be implemented in the BSP, doing the same UIO or > > VFIO do, but this will require (minor) changes to DPDK for having another > > intr_handle (not UIO, not VFIO). I do not know if other PMDs could also > > make use of such a change but I guess that would help to accept those > > changes. > > We are going to have an external handler (used for mlx5): > http://dpdk.org/ml/archives/dev/2015-October/024678.html > Problem solved :) > > Is it possible to rework your PMD without nfp-uio? > > Thanks >