From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by dpdk.org (Postfix) with ESMTP id B19538DAC for ; Fri, 2 Oct 2015 01:39:08 +0200 (CEST) Received: by padhy16 with SMTP id hy16so88484644pad.1 for ; Thu, 01 Oct 2015 16:39:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=1ZfQj3re/0zHqZwrcBXqJmIrI0Hk0yAVcUTJSGFWvLg=; b=H7slBGRH5aST0qvK3z/j4ZcD5DQ6W6SpBrWS5zO3Hu2gFrpv3SjJcWy8mTHAisVtjr o//d+3SDVuTwJ1qDvt4RkROrLMxEYT7bliGpRJbSY6eUa7yzqccyBUyYKfTr356Xi/Pj xSZJTM/nMLiZalKSEPR6Nw+8ozqHcuR1mF/qc9qwpd4auFbOsAv8FVd2D2AosGxuAMN4 h/Rz+nPP8qRjY8zqwBXhZHjQsgkb9hR24Wb9RlV5y2T1IkEeO8NvRJRQFqORi9IyRhDP KBBPu7SQh0/C1RVT+2Zss+sD+7uTq7NImPsKBMJkgJ2abS4KUBdwiA03guIqS/llk4it 5ZPw== X-Gm-Message-State: ALoCoQn56B8BxPMFD55Z0IdUWmjzw2W/kOGh4upkWJju1CH132kSNSqD8/6YHX95m3R/pfvhU6yW X-Received: by 10.66.219.74 with SMTP id pm10mr15594140pac.93.1443742748139; Thu, 01 Oct 2015 16:39:08 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id cn4sm8766524pbc.94.2015.10.01.16.39.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 16:39:08 -0700 (PDT) Date: Thu, 1 Oct 2015 16:39:18 -0700 From: Stephen Hemminger To: Alexander Duyck Message-ID: <20151001163918.1bc98774@urahara> In-Reply-To: <560DBBAA.3050906@gmail.com> References: <1443652138-31782-1-git-send-email-stephen@networkplumber.org> <560D11F6.2080609@scylladb.com> <20151001075731.2f079237@urahara> <560D8E14.5030500@gmail.com> <20151001150036.7a20b228@urahara> <560DBBAA.3050906@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Avi Kivity , hjk@hansjkoch.de, gregkh@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver 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: Thu, 01 Oct 2015 23:39:09 -0000 On Thu, 1 Oct 2015 16:03:06 -0700 Alexander Duyck wrote: > On 10/01/2015 03:00 PM, Stephen Hemminger wrote: > > On Thu, 1 Oct 2015 12:48:36 -0700 > > Alexander Duyck wrote: > > > >> On 10/01/2015 07:57 AM, Stephen Hemminger wrote: > >>> On Thu, 1 Oct 2015 13:59:02 +0300 > >>> Avi Kivity wrote: > >>> > >>>> On 10/01/2015 01:28 AM, Stephen Hemminger wrote: > >>>>> This is a new UIO device driver to allow supporting MSI-X and MSI devices > >>>>> in userspace. It has been used in environments like VMware and older versions > >>>>> of QEMU/KVM where no IOMMU support is available. > >>>> Why not add msi/msix support to uio_pci_generic? > >>> That is possible but that would meet ABI and other resistance from the author. > >>> Also, uio_pci_generic makes it harder to find resources since it doesn't fully > >>> utilize UIO infrastructure. > >> I'd say you are better off actually taking this in the other direction. > >> From what I have seen it seems like this driver is meant to deal with > >> mapping VFs contained inside of guests. If you are going to fork off > >> and create a UIO driver for mapping VFs why not just make it specialize > >> in that. You could probably simplify the code by dropping support for > >> legacy interrupts and IO regions since all that is already covered by > >> uio_pci_generic anyway if I am not mistaken. > >> > >> You could then look at naming it something like uio_vf since the uio_msi > >> is a bit of a misnomer since it is MSI-X it supports, not MSI interrupts. > > The support needs to cover: > > - VF in guest > > - VNIC in guest (vmxnet3) > > it isn't just about VF's > > I get that, but the driver you are talking about adding is duplicating > much of what is already there in uio_pci_generic. If nothing else it > might be worth while to look at replacing the legacy interrupt with > MSI. Maybe look at naming it something like uio_pcie to indicate that > we are focusing on assigning PCIe and virtual devices that support MSI > and MSI-X and use memory BARs rather than legacy PCI devices that are > doing things like mapping I/O BARs and using INTx signaling. > > My main argument is that we should probably look at dropping support for > anything that isn't going to be needed. If it is really important we > can always add it later. I just don't see the value in having code > around for things we aren't likely to ever use with real devices as we > are stuck supporting it for the life of the driver. I'll go ahead and > provide a inline review of your patch 2/2 as I think my feedback might > make a bit more sense that way. Ok, but having one driver that can deal with failures with msi-x vector setup and fallback seemed like a better strategy.