[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49D4B799.5080902@novell.com>
Date: Thu, 02 Apr 2009 09:03:21 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: Avi Kivity <avi@...hat.com>
CC: Herbert Xu <herbert@...dor.apana.org.au>, anthony@...emonkey.ws,
andi@...stfloor.org, linux-kernel@...r.kernel.org, agraf@...e.de,
pmullaney@...ell.com, pmorreale@...ell.com, rusty@...tcorp.com.au,
netdev@...r.kernel.org, kvm@...r.kernel.org,
Mark McLoughlin <markmc@...hat.com>
Subject: Re: [RFC PATCH 00/17] virtual-bus
Avi Kivity wrote:
> Gregory Haskins wrote:
>
>
>
>>> It's more of a "schedule and forget" which I think brings you the
>>> win. The host disables notifications and schedules the actual tx work
>>> (rx from the host's perspective). So now the guest and host continue
>>> producing and consuming packets in parallel. So long as the guest is
>>> faster (due to the host being throttled?), notifications continue to
>>> be disabled.
>>>
>> Yep, when the "producer::consumer" ratio is > 1, we mitigate
>> signaling. When its < 1, we signal roughly once per packet.
>>
>>
>>> If you changed your rx_isr() to process the packets immediately
>>> instead of scheduling, I think throughput would drop dramatically.
>>>
>> Right, that is the point. :) This is that "soft asic" thing I was
>> talking about yesterday.
>>
>
> But all that has nothing to do with where the code lives, in the
> kernel or userspace.
Agreed, but note Ive already stated that some of my boost is likely from
in-kernel, while others are unrelated design elements such as the
"soft-asic" approach (you guys dont read my 10 page emails, do you? ;).
I don't deny that some of my ideas could be used in userspace as well
(Credit if used would be appreciated :).
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (258 bytes)
Powered by blists - more mailing lists