From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [virtio-dev] Zerocopy VM-to-VM networking using virtio-net Date: Mon, 27 Apr 2015 16:38:47 +0200 Message-ID: <553E49F7.6010805@siemens.com> References: <20150422170138.GA8388@stefanha-thinkpad.redhat.com> <553E2D07.9040406@siemens.com> <553E31DC.6040108@siemens.com> <553E480B.1020502@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Luke Gorrie Cc: Andrew Jones , "Michael S. Tsirkin" , Rik van Riel , Linux Virtualization , Stefan Hajnoczi , Paolo Bonzini , "Dr. David Alan Gilbert" List-Id: virtualization@lists.linuxfoundation.org Am 2015-04-27 um 16:36 schrieb Luke Gorrie: > On 27 April 2015 at 16:30, Jan Kiszka wrote: > >> Today, we have posted interrupts to avoid the vm-exit on the target CPU, >> but there is nothing yet (to my best knowledge) to avoid the exit on the >> sender side (unless we ignore security). That's the same problem with >> intra-guest IPIs, BTW. >> >> For throughput and given NAPI patterns, that's probably not an issue as >> you noted. It may be for latency, though, when almost every cycle counts. >> > > Poll-mode networking applications (DPDK, Snabb Switch, etc) are typically > busy-looping to poll the vring. They may have a very short usleep() between > checks to save power but they don't wait on their eventfd. So for those > particular applications latency is on the order of tens of microseconds > even without guest exits. That's one side, don't forget the others (the "normal" guests). Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux