From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755077Ab2DIHeJ (ORCPT ); Mon, 9 Apr 2012 03:34:09 -0400 Received: from sting.hengli.com.au ([178.18.18.71]:44613 "EHLO fornost.hengli.com.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754729Ab2DIHeH (ORCPT ); Mon, 9 Apr 2012 03:34:07 -0400 Date: Mon, 9 Apr 2012 15:33:54 +0800 From: Herbert Xu To: "Michael S. Tsirkin" Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" , Jamal Hadi Salim , Stephen Hemminger , Jason Wang , Neil Horman , Jiri Pirko , Jeff Kirsher , Eric Dumazet , =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Ben Hutchings Subject: Re: [PATCH] net: orphan queued skbs if device tx can stall Message-ID: <20120409073354.GA3218@gondor.apana.org.au> References: <20120408171323.GA16012@redhat.com> <20120408234951.GA15993@gondor.apana.org.au> <20120409072849.GA12014@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120409072849.GA12014@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 09, 2012 at 10:28:49AM +0300, Michael S. Tsirkin wrote: > > > 1) Doesn't this break local UDP push-back? > > What is meant by UDP pushback here? Two tap > devices communicating by UDP packets locally? > This was always broken, see below. I mean push-back from UDP transmission to the physical NIC. Your patch breaks that as now the guest will have no push-back whatsoever so anything that transmits UDP without protocol-level congestion control will start dropping most of their packets. Granted you can argue that these apps are broken, but they do exist and we've always catered for them, both on baremetal and under virtualisation. > Thus we get this situation > tap1 sends packets, some of them to tap2, tap2 does not consume them, > as a result tap2 queue overflows, tap2 stops forever and > packets get queued in the qdisc, now tap1 > send buffer gets full so it can not communicate to any destination. > > So the problem is one VM can block all networking from another one. This should be addressed in the backend, as it can distinguish between packets going out to physical and packets stuck going to a local VM. In the latter case you can then duplicate and release the sender's memory. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Xu Subject: Re: [PATCH] net: orphan queued skbs if device tx can stall Date: Mon, 9 Apr 2012 15:33:54 +0800 Message-ID: <20120409073354.GA3218@gondor.apana.org.au> References: <20120408171323.GA16012@redhat.com> <20120408234951.GA15993@gondor.apana.org.au> <20120409072849.GA12014@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" , Jamal Hadi Salim , Stephen Hemminger , Jason Wang , Neil Horman , Jiri Pirko , Jeff Kirsher , Eric Dumazet , =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Ben Hutchings To: "Michael S. Tsirkin" Return-path: Content-Disposition: inline In-Reply-To: <20120409072849.GA12014@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Mon, Apr 09, 2012 at 10:28:49AM +0300, Michael S. Tsirkin wrote: > > > 1) Doesn't this break local UDP push-back? > > What is meant by UDP pushback here? Two tap > devices communicating by UDP packets locally? > This was always broken, see below. I mean push-back from UDP transmission to the physical NIC. Your patch breaks that as now the guest will have no push-back whatsoever so anything that transmits UDP without protocol-level congestion control will start dropping most of their packets. Granted you can argue that these apps are broken, but they do exist and we've always catered for them, both on baremetal and under virtualisation. > Thus we get this situation > tap1 sends packets, some of them to tap2, tap2 does not consume them, > as a result tap2 queue overflows, tap2 stops forever and > packets get queued in the qdisc, now tap1 > send buffer gets full so it can not communicate to any destination. > > So the problem is one VM can block all networking from another one. This should be addressed in the backend, as it can distinguish between packets going out to physical and packets stuck going to a local VM. In the latter case you can then duplicate and release the sender's memory. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt