From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754224Ab0DNA6m (ORCPT ); Tue, 13 Apr 2010 20:58:42 -0400 Received: from ringil.hengli.com.au ([216.59.3.182]:59438 "EHLO arnor.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752711Ab0DNA6l (ORCPT ); Tue, 13 Apr 2010 20:58:41 -0400 Date: Wed, 14 Apr 2010 08:58:22 +0800 From: Herbert Xu To: Eric Dumazet Cc: "Michael S. Tsirkin" , Jan Kiszka , "David S. Miller" , Paul Moore , David Woodhouse , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , qemu-devel Subject: Re: [PATCH] tun: orphan an skb on tx Message-ID: <20100414005822.GD18044@gondor.apana.org.au> References: <20100413145944.GA7716@redhat.com> <4BC48F79.5090409@siemens.com> <1271176838.16881.537.camel@edumazet-laptop> <20100413173919.GC26011@redhat.com> <1271183463.16881.545.camel@edumazet-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1271183463.16881.545.camel@edumazet-laptop> 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 Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote: > > Herbert Acked your patch, so I guess its OK, but I think it can be > dangerous. The tun socket accounting was never designed to stop it from flooding another tun interface. It's there to stop it from transmitting above a destination interface TX bandwidth and cause unnecessary packet drops. It also limits the total amount of kernel memory that can be pinned down by a single tun interface. In this case, all we're doing is shifting the accounting from the "hardware" queue to the qdisc queue. So your ability to flood a tun interface is essentially unchanged. BTW we do the same thing in a number of hardware drivers, as well as virtio-net. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} 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] tun: orphan an skb on tx Date: Wed, 14 Apr 2010 08:58:22 +0800 Message-ID: <20100414005822.GD18044@gondor.apana.org.au> References: <20100413145944.GA7716@redhat.com> <4BC48F79.5090409@siemens.com> <1271176838.16881.537.camel@edumazet-laptop> <20100413173919.GC26011@redhat.com> <1271183463.16881.545.camel@edumazet-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Michael S. Tsirkin" , Jan Kiszka , "David S. Miller" , Paul Moore , David Woodhouse , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , qemu-devel To: Eric Dumazet Return-path: Received: from ringil.hengli.com.au ([216.59.3.182]:59438 "EHLO arnor.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752711Ab0DNA6l (ORCPT ); Tue, 13 Apr 2010 20:58:41 -0400 Content-Disposition: inline In-Reply-To: <1271183463.16881.545.camel@edumazet-laptop> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote: > > Herbert Acked your patch, so I guess its OK, but I think it can be > dangerous. The tun socket accounting was never designed to stop it from flooding another tun interface. It's there to stop it from transmitting above a destination interface TX bandwidth and cause unnecessary packet drops. It also limits the total amount of kernel memory that can be pinned down by a single tun interface. In this case, all we're doing is shifting the accounting from the "hardware" queue to the qdisc queue. So your ability to flood a tun interface is essentially unchanged. BTW we do the same thing in a number of hardware drivers, as well as virtio-net. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} 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 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1qwJ-0000ip-45 for qemu-devel@nongnu.org; Tue, 13 Apr 2010 20:58:47 -0400 Received: from [140.186.70.92] (port=56470 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1qwG-0000id-Nq for qemu-devel@nongnu.org; Tue, 13 Apr 2010 20:58:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1qwE-0005pt-HC for qemu-devel@nongnu.org; Tue, 13 Apr 2010 20:58:44 -0400 Received: from ringil.hengli.com.au ([216.59.3.182]:34290 helo=arnor.apana.org.au) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1qwD-0005pM-TA for qemu-devel@nongnu.org; Tue, 13 Apr 2010 20:58:42 -0400 Date: Wed, 14 Apr 2010 08:58:22 +0800 From: Herbert Xu Message-ID: <20100414005822.GD18044@gondor.apana.org.au> References: <20100413145944.GA7716@redhat.com> <4BC48F79.5090409@siemens.com> <1271176838.16881.537.camel@edumazet-laptop> <20100413173919.GC26011@redhat.com> <1271183463.16881.545.camel@edumazet-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1271183463.16881.545.camel@edumazet-laptop> Subject: [Qemu-devel] Re: [PATCH] tun: orphan an skb on tx List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Dumazet Cc: Paul Moore , David Woodhouse , "Michael S. Tsirkin" , Jan Kiszka , "linux-kernel@vger.kernel.org" , qemu-devel , "netdev@vger.kernel.org" , "David S. Miller" On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote: > > Herbert Acked your patch, so I guess its OK, but I think it can be > dangerous. The tun socket accounting was never designed to stop it from flooding another tun interface. It's there to stop it from transmitting above a destination interface TX bandwidth and cause unnecessary packet drops. It also limits the total amount of kernel memory that can be pinned down by a single tun interface. In this case, all we're doing is shifting the accounting from the "hardware" queue to the qdisc queue. So your ability to flood a tun interface is essentially unchanged. BTW we do the same thing in a number of hardware drivers, as well as virtio-net. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt