From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nCucqaYNXCaiZUVHhiusjkPy9vzcm3OimATrkjtWUeU=; b=VZcn3Q/6e0J7z88l9mJp641ix7rdAR7W9Qjv8FvLt+AZuMq7fEZMqSudey7D005pUu +yPp65O/zfMy4r3gKd/ROOgJ54IH8jKJV7hkJcZl+SnUJY032GYI34fOwSsKiiFjx0o1 ioX40vR/AWcHMn4CVaexCMhJoNrRVFvFL4TMzJn1yDzXEATicWuJxmymeODvqKhMq6Io U1LWYvx/cwsyyeSTYdTkFjkyZLMwNCsy7N8HiabvL7/M2cKd292xh2dBByHQAGGPHvhK ehOYYE3V7kXKMZKeuJaTz3HUX+XkIblah8mvAv7ID9yeIKNBMBY7NTkrhvY/V7C9c+Qo uVpQ== X-Gm-Message-State: ALoCoQmuTLmI2e2kocE0Kl2giQcEBRRRxmpc6bTZMq2yTQX9exuqYTdBylgl+CkPWAHaYnXd1YDf X-Received: by 10.180.182.116 with SMTP id ed20mr7435000wic.19.1443977377761; Sun, 04 Oct 2015 09:49:37 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-180-197-252.red.bezeqint.net. [79.180.197.252]) by smtp.googlemail.com with ESMTPSA id ex17sm10064952wid.23.2015.10.04.09.49.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Oct 2015 09:49:36 -0700 (PDT) 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> 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 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: Sun, 04 Oct 2015 16:49:38 -0000 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