From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: reduce networking latency Date: Mon, 29 Sep 2014 12:04:18 +0300 Message-ID: <20140929090418.GA32069@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm To: David Xu Return-path: Received: from mx1.redhat.com ([209.132.183.28]:7979 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911AbaI2JAx (ORCPT ); Mon, 29 Sep 2014 05:00:53 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Sep 24, 2014 at 02:40:53PM -0400, David Xu wrote: > Hi Michael, > > I found this interesting project from KVM TODO website: > > allow handling short packets from softirq or VCPU context > Plan: > We are going through the scheduler 3 times > (could be up to 5 if softirqd is involved) > Consider RX: host irq -> io thread -> VCPU thread -> > guest irq -> guest thread. > This adds a lot of latency. > We can cut it by some 1.5x if we do a bit of work > either in the VCPU or softirq context. > Testing: netperf TCP RR - should be improved drastically > netperf TCP STREAM guest to host - no regression > > Would you mind saying more about the work either in the vCPU or > softirq context? For TX, we might be able to execute it directly from VCPU context. For RX, from softirq context. > Why it is only for short packets handling? That's just one idea to avoid doing too much work like this. Doing too much work in VCPU context would break pipelining, likely degrading stream performance. Work in softirq context is not accounted against the correct cgroups, doing a lot of work there will mean guest can steal CPU from other guests. > Thanks a > lot! > > > Regards, > > Cong