From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751270AbbJAWAf (ORCPT ); Thu, 1 Oct 2015 18:00:35 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:34838 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751151AbbJAWA2 (ORCPT ); Thu, 1 Oct 2015 18:00:28 -0400 Date: Thu, 1 Oct 2015 15:00:36 -0700 From: Stephen Hemminger To: Alexander Duyck Cc: Avi Kivity , dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Message-ID: <20151001150036.7a20b228@urahara> In-Reply-To: <560D8E14.5030500@gmail.com> References: <1443652138-31782-1-git-send-email-stephen@networkplumber.org> <560D11F6.2080609@scylladb.com> <20151001075731.2f079237@urahara> <560D8E14.5030500@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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