From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Zolotarov Subject: Re: [PATCH 0/2] uio_msi: device driver Date: Sun, 4 Oct 2015 19:49:35 +0300 Message-ID: <5611589F.3010002@cloudius-systems.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> <20151001163918.1bc98774@urahara> <560DC51B.7030507@gmail.com> <20151001170403.1ba4dad3@urahara> <560DE03E.3080300@gmail.com> Mime-Version: 1.0 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 To: Alexander Duyck , Stephen Hemminger Return-path: Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id ECF578D9E for ; Sun, 4 Oct 2015 18:49:37 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so90487937wic.0 for ; Sun, 04 Oct 2015 09:49:37 -0700 (PDT) In-Reply-To: <560DE03E.3080300@gmail.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" FYI: I've just posted to linux-kernel list patches that add support for both MSI and MSI-X interrupt modes to uio_pci_generic driver. It addresses most (all) remarks on this thread and also fixes some issues this code has, e.g. not disabling msi-x in remove(), etc. U are all welcome to comment... ;) thanks, vlad On 10/02/15 04:39, Alexander Duyck wrote: > On 10/01/2015 05:04 PM, Stephen Hemminger wrote: >> On Thu, 1 Oct 2015 16:43:23 -0700 >> Alexander Duyck wrote: >> >>> 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. >> I tried that but the bookkeeping gets messy since there is no good >> way to communicate that back to userspace and have it adapt. > > Actually I kind of just realized that uio_msi_open is kind of messed > up. So if the MSI-X allocation fails due to no resources it will > return a positive value indicating the number of vectors that could be > allocated, a negative value if one of the input values is invalid, or > 0. I'm not sure if returning a positive value on failure is an issue > or not. I know the open call is supposed to return a negative value > or the file descriptor if not negative. I don't know if the return > value might be interpreted as a file descriptor or not. > > Also if MSI-X is supported by the hardware, but disabled for some > reason by the kernel ("pci=nomsi") then this driver is rendered > inoperable since it will never give you anything but -EINVAL from the > open call. > > I really think you should probably look at taking care of enabling > MSI-X and maybe MSI as a fall-back in probe. At least then you can > post a message about how many vectors are enabled and what type. Then > if you cannot enable any interrupts due to MSI being disabled you can > simply fail at probe time and let then load a different driver. > > - Alex