qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 0/5] Introduce "-object iothread-group"


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH RFC 0/5] Introduce "-object iothread-group"
Date: Tue, 11 Jul 2017 15:15:43 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

On Mon, Jul 10, 2017 at 03:20:22PM +0800, Fam Zheng wrote:
> Last time we've looked at "-object iothread,spawns=N" but it was a bit 
> abusive.
> A dedicated "iothread-group" class is cleaner from the interface point of 
> view.
> This series does that.
> 
> It has the same set of poll parameters as the existing "iothread" object, plus
> a "size" option to specify how many threads to start. Using iothread-group
> doesn't require the user to explicitly create the contained IOThreads. The
> IOThreads are created by the group object.
> 
> Internally, IOThreads share one AioContext.  This is to make it easier to 
> adapt
> this to the current data plane code (see the last patch). But it is an
> implementation detail, and will change depending on the block layer multiqueue
> needs.
> 
> TODO:
> 
> - qmp_query_iothread_groups, in addition to proper QOM @child property from
>   IOThreadGroup to its IOThread instances.
> - Add virtio-scsi.
> - Variant of iothread_stop_all().
> 
> Fam Zheng (5):
>   aio: Wrap poll parameters into AioContextPollParams
>   iothread: Don't error on windows
>   iothread: Extract iothread_start
>   Introduce iothread-group
>   virtio-blk: Add iothread-group property

From your TODO note above it looks like you plan to duplicate IOThread
interfaces for IOThreadGroup?  This means existing query-iothreads users
no longer see the full view of all IOThreads.

I think it would be cleaner to define and query IOThreads like they are
today but change virtio-blk/virtio-scsi to accept a list of IOThreads.
That way existing management tool functionality can be used and the only
tweak is that devices can now be added to multiple IOThreads.

It would be nice to express the group relationship in QOM instead of
open coding a new group object.  The majority of the RFC code creates a
child/link list relationship that QOM should support for any type, not
just IOThread.

Adding Eric Blake so we can discuss QMP requirements further.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]