From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: reduce networking latency Date: Thu, 23 Oct 2014 07:15:30 +0300 Message-ID: <20141023041530.GA3871@redhat.com> References: <20140929090418.GA32069@redhat.com> 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]:12707 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750764AbaJWELz (ORCPT ); Thu, 23 Oct 2014 00:11:55 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Oct 22, 2014 at 04:35:07PM -0400, David Xu wrote: > 2014-10-15 14:30 GMT-04:00 David Xu : > > 2014-09-29 5:04 GMT-04:00 Michael S. Tsirkin : > >> 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. > >> > > Do you mean for RX, we directly put data to a shared buffer accessed > by guest VM bypassing the IO thread? For TX, in vCPU context network > data is added to the shared buffer and kick host IRQ to send them? Yes, that's the idea. > >>> 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