qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane
Date: Fri, 22 Feb 2013 12:31:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

Il 22/02/2013 11:43, Stefan Hajnoczi ha scritto:
>> > 
>> > It can and should stay. :)  BHs are tied to an AioContext.  Running
>> > thread-creation BHs from the AioContext's main thread ensures that the
>> > worker threads inherit the right attributes for e.g. real-time.
> When I say "this can stay" I mean that worker threads will be spawned
> from the QEMU iothread, not from the caller's thread.

Ah :)

> Why?
> 
> Because if we decide to change this then we can no longer have a global
> set of worker threads and a single work queue.  It would make worker
> threads scoped to just one AioContext.
> 
> Do we really want to go there?  It kind of defeats the purpose of a
> thread-pool to have one thread-pool per AioContext (i.e. per virtio-blk
> device).

I think scoped worker threads are simpler to implement and have little
or no lock contention (I have patches for lockless thread-pool, but I'm
not 100% sure they're correct---and they're a bit ugly).  Also, with
many virtio-blk threads you could hit the 64-thread limit that
thread-pool has, so it may require some tuning.

More importantly, scoped worker thread do not require an external
iothread to exist at all.

We can switch from one solution to the other easily (benchmarking takes
more time than coding, in all likelihood), so it's not urgent to choose
one over the other now.

>> We will use two BlockDriverStates if the same backing file
>> happens to be shared by two disks (BTW, anybody ever checked what kind
>> of havoc happens if you commit to such a BDS? :)).
> 
> AFAIK we don't share backing file BlockDriverStates today.

Indeed, we don't share BDSs but commit operations could cause the same
file to be backed by two BDSs, one read-only and one read-write.

>> What's still missing here is TCG support.  Perhaps you can emulate
>> ioeventfd at the hw/virtio.c level and always going through a host
>> notifier.  In retrospect, perhaps it was a mistake to make ioeventfd a
>> non-experimental option.
> 
> That's true.  We need to emulate ioeventfd.  For virtio-pci we can cheat
> by simply notifying the EventNotifier from the virtqueue kick handler.
> But really we should implement an ioeventfd equivalent at the pio/mmio
> emulation level in QEMU.

Not a big deal anyway (like the irqfd).

Paolo



reply via email to

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