[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49D4BF70.1060301@novell.com>
Date: Thu, 02 Apr 2009 09:36:48 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: Avi Kivity <avi@...hat.com>
CC: Anthony Liguori <anthony@...emonkey.ws>,
Andi Kleen <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
Subject: Re: [RFC PATCH 00/17] virtual-bus
Avi Kivity wrote:
> Gregory Haskins wrote:
>> Avi Kivity wrote:
>>
>>> My 'prohibitively expensive' is true only if you exit every packet.
>>>
>>>
>>>
>>
>> Understood, but yet you need to do this if you want something like iSCSI
>> READ transactions to have as low-latency as possible.
>>
>
> Dunno, two microseconds is too much? The wire imposes much more.
>
No, but thats not what we are talking about. You said signaling on
every packet is prohibitively expensive. I am saying signaling on every
packet is required for decent latency. So is it prohibitively expensive
or not?
I think most would agree that adding 2us is not bad, but so far that is
an unproven theory that the IO path in question only adds 2us. And we
are not just looking at the rate at which we can enter and exit the
guest...we need the whole path...from the PIO kick to the dev_xmit() on
the egress hardware, to the ingress and rx-injection. This includes any
and all penalties associated with the path, even if they are imposed by
something like the design of tun-tap.
Right now its way way way worse than 2us. In fact, at my last reading
this was more like 3060us (3125-65). So shorten that 3125 to 67 (while
maintaining line-rate) and I will be impressed. Heck, shorten it to
80us and I will be impressed.
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (258 bytes)
Powered by blists - more mailing lists