From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Liu, Jiang" <gerry@linux.alibaba.com>,
"Liu, Jing2" <jing2.liu@linux.intel.com>,
Zha Bin <zhabin@linux.alibaba.com>,
linux-kernel@vger.kernel.org, slp@redhat.com,
virtio-dev@lists.oasis-open.org, jing2.liu@intel.com,
chao.p.peng@intel.com
Subject: Re: [virtio-dev] Re: [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3
Date: Sun, 5 Jan 2020 06:25:59 -0500 [thread overview]
Message-ID: <20200105062023-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <7e151886-408e-2c1d-3958-77c26b8a4ac0@redhat.com>
On Fri, Jan 03, 2020 at 05:12:38PM +0800, Jason Wang wrote:
>
> On 2020/1/3 下午2:14, Liu, Jiang wrote:
> > > Ok, I get you now.
> > >
> > > But still, having fixed number of MSIs is less flexible. E.g:
> > >
> > > - for x86, processor can only deal with about 250 interrupt vectors.
> > > - driver may choose to share MSI vectors [1] (which is not merged but we will for sure need it)
> > Thanks for the info:)
> > X86 systems roughly have NCPU * 200 vectors available for device interrupts.
> > The proposed patch tries to map multiple event sources to an interrupt vector, to avoid running out of x86 CPU vectors.
> > Many virtio mmio devices may have several or tens of event sources, and it’s rare to have hundreds of event sources.
> > So could we treat the dynamic mapping between event sources and interrupt vectors as an advanced optional feature?
> >
>
> Maybe, but I still prefer to implement it if it is not too complex. Let's
> see Michael's opinion on this.
>
> Thanks
I think a way for the device to limit # of vectors in use by driver is
useful. But sharing of vectors doesn't really need any special
registers, just program the same vector for multiple Qs/interrupts.
--
MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Liu, Jiang" <gerry@linux.alibaba.com>,
"Liu, Jing2" <jing2.liu@linux.intel.com>,
Zha Bin <zhabin@linux.alibaba.com>,
linux-kernel@vger.kernel.org, slp@redhat.com,
virtio-dev@lists.oasis-open.org, jing2.liu@intel.com,
chao.p.peng@intel.com
Subject: Re: [virtio-dev] Re: [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3
Date: Sun, 5 Jan 2020 06:25:59 -0500 [thread overview]
Message-ID: <20200105062023-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <7e151886-408e-2c1d-3958-77c26b8a4ac0@redhat.com>
On Fri, Jan 03, 2020 at 05:12:38PM +0800, Jason Wang wrote:
>
> On 2020/1/3 下午2:14, Liu, Jiang wrote:
> > > Ok, I get you now.
> > >
> > > But still, having fixed number of MSIs is less flexible. E.g:
> > >
> > > - for x86, processor can only deal with about 250 interrupt vectors.
> > > - driver may choose to share MSI vectors [1] (which is not merged but we will for sure need it)
> > Thanks for the info:)
> > X86 systems roughly have NCPU * 200 vectors available for device interrupts.
> > The proposed patch tries to map multiple event sources to an interrupt vector, to avoid running out of x86 CPU vectors.
> > Many virtio mmio devices may have several or tens of event sources, and it’s rare to have hundreds of event sources.
> > So could we treat the dynamic mapping between event sources and interrupt vectors as an advanced optional feature?
> >
>
> Maybe, but I still prefer to implement it if it is not too complex. Let's
> see Michael's opinion on this.
>
> Thanks
I think a way for the device to limit # of vectors in use by driver is
useful. But sharing of vectors doesn't really need any special
registers, just program the same vector for multiple Qs/interrupts.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2020-01-05 11:26 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-25 2:50 [PATCH v1 0/2] support virtio mmio specification Version 3 Zha Bin
2019-12-25 2:50 ` [PATCH v1 1/2] x86/msi: Enhance x86 to support platform_msi Zha Bin
2019-12-26 8:21 ` Jason Wang
2019-12-26 8:21 ` [virtio-dev] " Jason Wang
2020-01-17 13:58 ` Thomas Gleixner
2020-01-17 14:06 ` Liu, Jiang
2020-01-19 2:27 ` Liu, Jing2
2020-01-19 2:27 ` [virtio-dev] " Liu, Jing2
2020-01-19 14:57 ` Thomas Gleixner
2019-12-25 2:50 ` [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3 Zha Bin
2019-12-25 10:20 ` Jason Wang
2019-12-25 10:20 ` [virtio-dev] " Jason Wang
2019-12-25 15:20 ` Liu, Jiang
2019-12-26 8:09 ` Jason Wang
2019-12-26 8:09 ` [virtio-dev] " Jason Wang
2019-12-26 12:35 ` Liu, Jiang
2019-12-26 13:16 ` Liu, Jiang
2020-01-02 6:28 ` Jason Wang
2020-01-02 6:28 ` [virtio-dev] " Jason Wang
2020-01-03 6:50 ` Liu, Jiang
2020-01-05 10:42 ` Michael S. Tsirkin
2020-01-05 10:42 ` [virtio-dev] " Michael S. Tsirkin
2020-01-06 7:24 ` Liu, Jing2
2020-01-06 7:24 ` [virtio-dev] " Liu, Jing2
2020-01-09 16:06 ` Liu, Jiang
2020-01-09 16:47 ` Michael S. Tsirkin
2020-01-09 16:47 ` [virtio-dev] " Michael S. Tsirkin
2019-12-25 22:28 ` kbuild test robot
2019-12-25 22:28 ` kbuild test robot
2019-12-26 1:44 ` kbuild test robot
2019-12-26 1:44 ` kbuild test robot
2019-12-26 8:40 ` Jason Wang
2019-12-26 8:40 ` [virtio-dev] " Jason Wang
2019-12-27 9:37 ` Liu, Jing2
2019-12-27 9:37 ` Liu, Jing2
2020-01-02 6:33 ` Jason Wang
2020-01-02 6:33 ` Jason Wang
2020-01-02 9:13 ` Liu, Jing2
2020-01-02 9:13 ` Liu, Jing2
2020-01-03 3:24 ` Jason Wang
2020-01-03 3:24 ` Jason Wang
2020-01-03 6:14 ` Liu, Jiang
2020-01-03 9:12 ` Jason Wang
2020-01-03 9:12 ` Jason Wang
2020-01-05 11:25 ` Michael S. Tsirkin [this message]
2020-01-05 11:25 ` Michael S. Tsirkin
2020-01-06 2:51 ` Jason Wang
2020-01-06 2:51 ` Jason Wang
2020-01-05 11:04 ` Michael S. Tsirkin
2020-01-05 11:04 ` [virtio-dev] " Michael S. Tsirkin
2020-01-09 6:15 ` Liu, Jing2
2020-01-09 6:15 ` [virtio-dev] " Liu, Jing2
2020-01-09 13:26 ` Michael S. Tsirkin
2020-01-09 13:26 ` [virtio-dev] " Michael S. Tsirkin
2020-01-15 7:06 ` Liu, Jing2
2020-01-15 7:06 ` [virtio-dev] " Liu, Jing2
2020-01-21 5:03 ` Liu, Jing2
2020-01-21 5:03 ` Liu, Jing2
2020-01-02 6:55 ` [PATCH v1 0/2] support virtio mmio specification Version 3 Jason Wang
2020-01-02 6:55 ` [virtio-dev] " Jason Wang
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=20200105062023-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=chao.p.peng@intel.com \
--cc=gerry@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=jing2.liu@intel.com \
--cc=jing2.liu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=slp@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=zhabin@linux.alibaba.com \
/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.