From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751703AbbJDQtk (ORCPT ); Sun, 4 Oct 2015 12:49:40 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:35936 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751506AbbJDQtj (ORCPT ); Sun, 4 Oct 2015 12:49:39 -0400 Subject: Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver To: Alexander Duyck , 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> <560DC51B.7030507@gmail.com> <20151001170403.1ba4dad3@urahara> <560DE03E.3080300@gmail.com> Cc: dev@dpdk.org, Avi Kivity , hjk@hansjkoch.de, gregkh@linux-foundation.org, linux-kernel@vger.kernel.org From: Vlad Zolotarov Message-ID: <5611589F.3010002@cloudius-systems.com> Date: Sun, 4 Oct 2015 19:49:35 +0300 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: <560DE03E.3080300@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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