From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by dpdk.org (Postfix) with ESMTP id 6E3A59432 for ; Wed, 21 Oct 2015 16:39:56 +0200 (CEST) Received: by oiev17 with SMTP id v17so30077965oie.2 for ; Wed, 21 Oct 2015 07:39:56 -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=4+4YUZXVAeWTo/0a6IAGCKIy2PsNg3RGz5C4s4NlJ9A=; b=hdrMfdZty1bEjYCkicV1mSyFxtsYjrRBx9eNmfjMc8VtDiS1GfhDRm+uNaKRU0BEKl TvOjb3pZqlAe5qCTk6a0FkGsB+NgoZQZ1FjL2DJJvu6aPLdUeLkfvMyxy0iMz7iMuwAW ec3bbeMaNAC4uVUYtXPAHNenCJhR9EYHU3CM+4igQjhDv/4WmhA++UUiEsIwmjSoftyw l6SY+8C57Hv+DR72JdBRekfrgcDKNlSQTJ/JqfnZ6jHfj5q3DDSDizYrDkhGFzZF0jV6 9rcy8O7L+z6lyNHkUBuZr4n0u++vJAceuPh9sHpA3mPIXcR1JOl4eRJr+EV0SuJ1etY6 AESQ== X-Gm-Message-State: ALoCoQmYkRFEu382KoLj5VUfOrFnzDsnVsuc9d13eoKzSSbnwaxczl7BCqYrzooYSF6AvbIakicq MIME-Version: 1.0 X-Received: by 10.202.46.207 with SMTP id u198mr5684780oiu.66.1445438395882; Wed, 21 Oct 2015 07:39:55 -0700 (PDT) Received: by 10.76.11.10 with HTTP; Wed, 21 Oct 2015 07:39:55 -0700 (PDT) In-Reply-To: References: <1444992324-5504-1-git-send-email-alejandro.lucero@netronome.com> <1444992324-5504-3-git-send-email-alejandro.lucero@netronome.com> Date: Wed, 21 Oct 2015 15:39:55 +0100 Message-ID: From: Alejandro Lucero To: David Marchand Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" 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 14:39:56 -0000 Hi David, On Wed, Oct 21, 2015 at 6:24 AM, David Marchand wrote: > Hello Alejandro, > > On Fri, Oct 16, 2015 at 12:45 PM, Alejandro.Lucero < > alejandro.lucero@netronome.com> wrote: > >> From: "Alejandro.Lucero" >> >> This patch adds a new UIO kernel driver for supporting PCI VFs with >> Netronome >> nfp6000 card. Future PCI PF support will be based on changes to this >> module. >> >> Signed-off-by: Alejandro.Lucero >> Signed-off-by: Rolf.Neugebauer >> > > Please, can you elaborate on the need for (yet another) uio driver, rather > than make igb_uio work with your hardware ? > > We have two different needs not covered by igb_uio: - pci mask needs to be 40 bits instead of 64 - some old kernel have buggy IOMMU with devices with pci masks as those 40 bits. This can be fixed just using kernel DMA API for a harmless dma memory allocation. We have such a allocation along with the release in our nfp_uio driver. I thought to modify igb_uio adding a kernel param for setting another pci mask than igb default one, but this is to leave to the user the right initialisation. But there is another more important reason for having a different driver: future PF support. Our device is programmable with processing units and functional units being configured by firmware code. Every part of the chip is addressable from the host which is possible through a BSP kernel driver. Device PCI BARs are not the same than network device (PF or VF) PCI BARs: the latter is a subregion of the former. VFs subregions are easy to get thanks to SRIOV. But in order to get the right subregions sizes and addresses for the PF, special firmware symbols are needed. User space programs can use the BSP through specific libraries but that requires support from the BSP, or from another driver doing the same. So nfp_uio will likely add that support. 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. Therefore, the easiest thing to do is to implement the PF support in the nfp_uio by now. I hope this explanation can help to justify nfp_uio. Thanks > Thanks. > > -- > David Marchand >