From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by dpdk.org (Postfix) with ESMTP id C679A8D90 for ; Fri, 2 Oct 2015 01:03:08 +0200 (CEST) Received: by padhy16 with SMTP id hy16so87693956pad.1 for ; Thu, 01 Oct 2015 16:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Lc48h+bTtdElWtY5k+IIXAj0UpWANrHkTMAXS0qR5tk=; b=Uy8uMqANu0qviSguxAZfZfgChI+effKfxBgPw60N2g6FSHy66GK2vAFC8hQfcNZZao r1h0MY4lQKSAsZb7mqhJJyQ4Fgzu7BjqrJL9pnAWk3ncB0lY8Alk2roxgYVMtJkSJ0gi kuL2zRCrLmSELsJoxg4ss2kikHWbKY7WBWhI5ouzRnNrDyPhKwJ2QTJkeeh+bZJyn4NO Xc56B9uTM37gSZu5uOVwiDEnvUFcrWNtxZFzfAGhyqFfoyh5emLdEFtoCOIMaOxHR2Zs gR4m5Plv/vKAZRle/NFJy9YxSbrW00OSwR6RlnWorgSIog5F/PnBIROcf6mZxg3Lnvs8 LmVQ== X-Received: by 10.66.228.71 with SMTP id sg7mr15531294pac.70.1443740588087; Thu, 01 Oct 2015 16:03:08 -0700 (PDT) Received: from [192.168.1.188] (static-50-53-21-5.bvtn.or.frontiernet.net. [50.53.21.5]) by smtp.googlemail.com with ESMTPSA id tp6sm8692312pbc.81.2015.10.01.16.03.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 16:03:06 -0700 (PDT) To: Stephen Hemminger References: <1443652138-31782-1-git-send-email-stephen@networkplumber.org> <560D11F6.2080609@scylladb.com> <20151001075731.2f079237@urahara> <560D8E14.5030500@gmail.com> <20151001150036.7a20b228@urahara> From: Alexander Duyck Message-ID: <560DBBAA.3050906@gmail.com> Date: Thu, 1 Oct 2015 16:03:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20151001150036.7a20b228@urahara> Content-Type: text/plain; charset=windows-1252; format=flowed 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:03:09 -0000 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. - Alex