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: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane
Date: Wed, 27 Feb 2013 13:08:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Stefan Hajnoczi <address@hidden> writes:

> On Mon, Feb 25, 2013 at 06:53:04PM +0100, Paolo Bonzini wrote:
>> Il 25/02/2013 18:35, mdroth ha scritto:
>> > Yup, don't mean to get ahead of things, my main interest is just in how
>> > we might deal with the interaction between NetClients and virtio-net
>> > dataplane threads without introducing ad-hoc, dataplane-specific
>> > mechanisms. If there was a general way for Nic to tell it's NetClient
>> > peer "hey, i have my own thread/main loop, here's my
>> > {Aio,*}Context, register
>> > your handlers there instead" I think this series might look a lot more
>> > realistic as a default, or at least make merging it less risky.
>> 
>> Yes, I see the point.
>> 
>> The main blocker to this series seems to be hubs, because they interact
>> with multiple NetClients and thus could span multiple AioContexts.
>> Adding proper locking there is going to be interesting. :)
>
> I think folks are pretty fed up with QEMU "vlans" (hubs).  Someone
> braver and with more time on their hands than me might be able to kill
> hubs without breaking their few use cases (-net dump, using the hub with
> -net socket).

Figuring out the 'interesting' locking leaves us with 'interesting'
locking code, and still stuck with "vlans".

Killing "vlans" would avoid the locking problems, and get rid of a
fertile source of 'interesting' problems.

Guess how I'd prefer to see the locking problem solved :)



reply via email to

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