From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH v2 00/31] Implement user mode network for kvm tools Date: Mon, 4 Jul 2011 11:43:15 +0200 Message-ID: <20110704094315.GA24439@elte.hu> References: <1309423279-3093-1-git-send-email-asias.hejun@gmail.com> <4E0C96FF.4090801@codemonkey.ws> <4E0D1238.3020506@gmail.com> <20110701115308.GJ20990@elte.hu> <27C3F9A0-8814-41A4-A45E-05A9B57DC139@suse.de> <20110703194215.GA27022@elte.hu> <46843B06-C11F-4FD3-8A85-54DDE0DF5D3D@suse.de> <20110704091127.GA22943@elte.hu> <8F1C9683-1EA9-4DC0-AF2B-5749B5E2FD09@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Asias He , Anthony Liguori , Stefan Hajnoczi , Pekka Enberg , Cyrill Gorcunov , Sasha Levin , Prasad Joshi , kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:44556 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753901Ab1GDJnZ (ORCPT ); Mon, 4 Jul 2011 05:43:25 -0400 Content-Disposition: inline In-Reply-To: <8F1C9683-1EA9-4DC0-AF2B-5749B5E2FD09@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: * Alexander Graf wrote: > > On 04.07.2011, at 11:11, Ingo Molnar wrote: > > > > > * Alexander Graf wrote: > > > >>>> I don't see how it would. Once you overrun device buffers, you > >>>> have to do something. Either you drop packets or you stall the > >>>> guest. I'd usually prefer the former :). > >>> > >>> What scenario do you see where we'd have to drop packets? > >>> > >>> When the guest sends packets, we send them over to the host TCP > >>> socket - no blocking. > >> > >> When the guest sends packets, I'd hope you have 2 threads: > >> > >> * vcpu > >> * virtio network queue process > >> > >> So those two run in parallel now, with the network queue processing > >> packets while the vcpu pushes packets into the ring. What if the > >> network thread is slower than the vcpu fills the ring? You only > >> have so many entries in a vring. > >> > >>> When the host receives packets it should only read data out of > >>> the host socket(s) if the vring buffer suggests that there's > >>> space available. > >> > >> I agree :). > >> > >>> So i don't see we'd need to drop packets or block things - we > >>> just have to react to packets and to vring space availability in > >>> a straightforward way. > >> > >> Well, the only way for the sending path is to stall the vcpu, > >> otherwise the guest figures "oh, I can't push packets into the > >> vring, let's just drop it", no? > > > > No, that's not how the Linux TCP/IP implementation works. > > > > Filled up TX rings are pretty normal on physical hardware: we do not > > drop packets but the TCP state machine keeps buffering and filling > > the device as it can. > > > > The same will happen with virtual guests as well - there's no packet > > dropping nor 'blocking of the whole guest'. > > I see. Can you guarantee that other guests (in case that ever gets > implemented) behave the same? Do you mean can i remove 100% of fear, uncertainty and doubt about an unknown 'black box' guest OS? No. But the queueing logic of TCP/IP stacks is pretty similar in practice so i'd be very surprised if Windows (which i guess you must be referring to) dropped packets due to TX overflow. It would be very stupid to drop packets on TX: the sending stack has to buffer the TCP stream *anyway* (and has no choice about that, the app cannot resend the socket data), so it achieves nothing from dropping the packet and adding resend complexity to itself. Thanks, Ingo