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 AB17E8DAC for ; Fri, 2 Oct 2015 01:43:25 +0200 (CEST) Received: by pacex6 with SMTP id ex6so88693001pac.0 for ; Thu, 01 Oct 2015 16:43:25 -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=BGZX1VzeOyzqi6YXYNm9X0hHQbou8mKFOl278waMd6U=; b=oxa7KK1jYSwm1bULd2Djs312bTEuCx4jsV5KnqdXqyuPT78Q38e97o8zMGoXbcwl6J kS+I8D4vWA4wz6qNf+jWASs/DP35NMDzozwQSAMNeqLkM9H9JMWD9Z2wrOyAJUFpWtr8 UR8w5WBM72dcbVXCRNKdYK7BSLHbcEyPei9TDvOzeZQXDjFWUespPwz/lQqu//wabvsx 7dfIFIWnKP0l3IkxDyM/V4PbTQt3BXGBzLszOqbnWb8YMNa+69qvRA7fo2y6651Sn4Zn +eRAp0AnCjmHkqwx4ait+fescOfg+6zzHqIiihKcSigeu4JKcDOrIMaA1qa9bqcUIHMy kExA== X-Received: by 10.66.136.39 with SMTP id px7mr15368864pab.23.1443743005113; Thu, 01 Oct 2015 16:43:25 -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 bw8sm8849133pab.47.2015.10.01.16.43.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Oct 2015 16:43:24 -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> <560DBBAA.3050906@gmail.com> <20151001163918.1bc98774@urahara> From: Alexander Duyck Message-ID: <560DC51B.7030507@gmail.com> Date: Thu, 1 Oct 2015 16:43:23 -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: <20151001163918.1bc98774@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:43:26 -0000 On 10/01/2015 04:39 PM, Stephen Hemminger wrote: > 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. Yes, but in the case of something like a VF it is going to just make a bigger mess of things since INTx doesn't work. So what would you expect your driver to do in that case? Also we have to keep in mind that the MSI-X failure case is very unlikely. One other thing that just occurred to me is that you may want to try using the range allocation call instead of a hard set number of interrupts. Then if you start running short on vectors you don't hard fail and instead just allocate what you can. - Alex