From: Vlad Zolotarov <vladz@cloudius-systems.com>
To: Alexander Duyck <alexander.duyck@gmail.com>,
Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, Avi Kivity <avi@scylladb.com>,
hjk@hansjkoch.de, gregkh@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] uio_msi: device driver
Date: Sun, 4 Oct 2015 19:49:35 +0300 [thread overview]
Message-ID: <5611589F.3010002@cloudius-systems.com> (raw)
In-Reply-To: <560DE03E.3080300@gmail.com>
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 <alexander.duyck@gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Vlad Zolotarov <vladz@cloudius-systems.com>
To: Alexander Duyck <alexander.duyck@gmail.com>,
Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, Avi Kivity <avi@scylladb.com>,
hjk@hansjkoch.de, gregkh@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver
Date: Sun, 4 Oct 2015 19:49:35 +0300 [thread overview]
Message-ID: <5611589F.3010002@cloudius-systems.com> (raw)
In-Reply-To: <560DE03E.3080300@gmail.com>
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 <alexander.duyck@gmail.com> 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
next prev parent reply other threads:[~2015-10-04 16:49 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 22:28 [PATCH 0/2] uio_msi: device driver Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-09-30 22:28 ` [PATCH 1/2] uio: add support for ioctls Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-09-30 22:28 ` [PATCH 2/2] uio: new driver to support PCI MSI-X Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-10-01 8:33 ` Michael S. Tsirkin
2015-10-01 8:33 ` Michael S. Tsirkin
2015-10-01 10:37 ` Michael S. Tsirkin
2015-10-01 10:37 ` Michael S. Tsirkin
2015-10-01 16:06 ` Michael S. Tsirkin
2015-10-01 16:06 ` Michael S. Tsirkin
2015-10-01 14:50 ` Stephen Hemminger
2015-10-01 14:50 ` Stephen Hemminger
2015-10-01 15:22 ` Michael S. Tsirkin
2015-10-01 15:22 ` Michael S. Tsirkin
2015-10-01 16:31 ` Michael S. Tsirkin
2015-10-01 16:31 ` Michael S. Tsirkin
2015-10-01 17:26 ` Stephen Hemminger
2015-10-01 17:26 ` Stephen Hemminger
2015-10-01 18:25 ` Michael S. Tsirkin
2015-10-01 18:25 ` Michael S. Tsirkin
2015-10-05 21:54 ` Michael S. Tsirkin
2015-10-05 21:54 ` Michael S. Tsirkin
2015-10-05 22:09 ` Vladislav Zolotarov
2015-10-05 22:49 ` Michael S. Tsirkin
2015-10-05 22:49 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 7:33 ` Stephen Hemminger
2015-10-06 7:33 ` [dpdk-dev] " Stephen Hemminger
2015-10-06 12:15 ` Avi Kivity
2015-10-06 12:15 ` [dpdk-dev] " Avi Kivity
2015-10-06 14:07 ` Michael S. Tsirkin
2015-10-06 15:41 ` Avi Kivity
2015-10-06 15:41 ` [dpdk-dev] " Avi Kivity
2015-10-16 17:11 ` Thomas Monjalon
2015-10-16 17:11 ` [dpdk-dev] " Thomas Monjalon
2015-10-16 17:20 ` Stephen Hemminger
2015-10-16 17:20 ` [dpdk-dev] " Stephen Hemminger
2015-10-06 13:42 ` Michael S. Tsirkin
2015-10-06 13:42 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 8:23 ` Vlad Zolotarov
2015-10-06 8:23 ` [dpdk-dev] " Vlad Zolotarov
2015-10-06 13:58 ` Michael S. Tsirkin
2015-10-06 13:58 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 14:49 ` Vlad Zolotarov
2015-10-06 15:00 ` Michael S. Tsirkin
2015-10-06 15:00 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 16:40 ` Vlad Zolotarov
2015-10-06 16:40 ` [dpdk-dev] " Vlad Zolotarov
2015-10-01 23:40 ` Alexander Duyck
2015-10-01 23:40 ` [dpdk-dev] " Alexander Duyck
2015-10-02 0:01 ` Stephen Hemminger
2015-10-02 0:01 ` [dpdk-dev] " Stephen Hemminger
2015-10-02 1:21 ` Alexander Duyck
2015-10-02 1:21 ` [dpdk-dev] " Alexander Duyck
2015-10-02 0:04 ` Stephen Hemminger
2015-10-02 2:33 ` Alexander Duyck
2015-10-02 2:33 ` [dpdk-dev] " Alexander Duyck
2015-10-01 8:36 ` [PATCH 0/2] uio_msi: device driver Michael S. Tsirkin
2015-10-01 8:36 ` Michael S. Tsirkin
2015-10-01 10:59 ` Avi Kivity
2015-10-01 10:59 ` [dpdk-dev] " Avi Kivity
2015-10-01 14:57 ` Stephen Hemminger
2015-10-01 19:48 ` Alexander Duyck
2015-10-01 19:48 ` [dpdk-dev] " Alexander Duyck
2015-10-01 22:00 ` Stephen Hemminger
2015-10-01 22:00 ` [dpdk-dev] " Stephen Hemminger
2015-10-01 23:03 ` Alexander Duyck
2015-10-01 23:03 ` [dpdk-dev] " Alexander Duyck
2015-10-01 23:39 ` Stephen Hemminger
2015-10-01 23:39 ` [dpdk-dev] " Stephen Hemminger
2015-10-01 23:43 ` Alexander Duyck
2015-10-02 0:04 ` Stephen Hemminger
2015-10-02 0:04 ` [dpdk-dev] " Stephen Hemminger
2015-10-02 1:39 ` Alexander Duyck
2015-10-04 16:49 ` Vlad Zolotarov [this message]
2015-10-04 16:49 ` Vlad Zolotarov
2015-10-04 19:03 ` Greg KH
2015-10-04 20:49 ` Vlad Zolotarov
2015-10-04 20:49 ` [dpdk-dev] " Vlad Zolotarov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5611589F.3010002@cloudius-systems.com \
--to=vladz@cloudius-systems.com \
--cc=alexander.duyck@gmail.com \
--cc=avi@scylladb.com \
--cc=dev@dpdk.org \
--cc=gregkh@linux-foundation.org \
--cc=hjk@hansjkoch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.