All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Amit Shah <amit.shah@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Subject: Re: find_vqs operation starting at arbitrary index
Date: Tue, 2 Jun 2009 20:23:25 +0300	[thread overview]
Message-ID: <20090602172325.GG6827@redhat.com> (raw)
In-Reply-To: <20090602170916.GA9564@amit-x200.pnq.redhat.com>

On Tue, Jun 02, 2009 at 10:39:16PM +0530, Amit Shah wrote:
> On (Tue) Jun 02 2009 [19:32:27], Michael S. Tsirkin wrote:
> > On Tue, Jun 02, 2009 at 08:53:07AM +0930, Rusty Russell wrote:
> > > On Mon, 1 Jun 2009 05:33:48 pm Amit Shah wrote:
> > > > Hello,
> > > >
> > > > The recent find_vqs operation doesn't allow for a vq to be found at an
> > > > arbitrary location; it's meant to be called once at startup to find all
> > > > possible queues and never called again.
> > > >
> > > > This doesn't work for devices which can have queues hot-plugged at
> > > > run-time. This can be made to work by passing the 'start_index' value as
> > > > was done earlier for find_vq, but I doubt something like the following
> > > > will work. The MSI vectors might need some changing as well.
> > > 
> > > There's a fundamental conflict here: find_vqs was added so the PCI MSI code 
> > > knows exactly how many virtqueues there are.
> > > 
> > > So you'll need to sort this out with Michael...
> > > 
> > > Thanks,
> > > Rusty.
> > 
> > I'd like to understand the expected usage some more.  If there's still a
> > small # of hotpluggable queues known in advance, you can request all
> > vectors but have the queues disabled, and then enable as queues arrive.
> > In that case, something like resize_queue or enable_queue might be a
> > good idea.
> 
> Yes, it sounds like a good idea and I was debating this exact question
> -- how many queues should I expect. I currently don't expect more than
> 20 but even that sounds like a largish number.
> 
> > OTOH, if you want to have a potentially unlimited number of queues,
> > you will have to allocate a common vector for all of them
> > as on intel we are limited to 256 total vectors for all devices
> > taken together.  Not sure what a good API for that would be.
> 
> A common vector for all the queues in the device, right? And will that
> also mean each queue gets woken up on any activity on any one of them?
> 
> 		Amit

Yes. This is what find_vqs currently does if it can't allocate a queue
per VQ (actually, per queue with callback: your queues do have
callbacks?).

Of course we can start contemplating more complicated options
for mapping queues to vectors, and the guest/host ABI
supports this.

-- 
MST

      reply	other threads:[~2009-06-02 17:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01  8:03 find_vqs operation starting at arbitrary index Amit Shah
2009-06-01  8:11 ` Michael S. Tsirkin
2009-06-01  8:35   ` Amit Shah
2009-06-01  8:43     ` Michael S. Tsirkin
2009-06-01  8:51       ` Amit Shah
2009-06-01  9:12         ` Michael S. Tsirkin
2009-06-01  9:45         ` Michael S. Tsirkin
2009-06-01 23:23 ` Rusty Russell
2009-06-02 16:32   ` Michael S. Tsirkin
2009-06-02 17:09     ` Amit Shah
2009-06-02 17:23       ` Michael S. Tsirkin [this message]

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=20090602172325.GG6827@redhat.com \
    --to=mst@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=virtualization@lists.linux-foundation.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.