From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753474Ab0DMQww (ORCPT ); Tue, 13 Apr 2010 12:52:52 -0400 Received: from david.siemens.de ([192.35.17.14]:17266 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752063Ab0DMQwv (ORCPT ); Tue, 13 Apr 2010 12:52:51 -0400 Message-ID: <4BC4A139.3010605@siemens.com> Date: Tue, 13 Apr 2010 18:52:09 +0200 From: Jan Kiszka User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eric Dumazet CC: "Michael S. Tsirkin" , "David S. Miller" , Herbert Xu , Paul Moore , David Woodhouse , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , qemu-devel Subject: Re: [PATCH] tun: orphan an skb on tx References: <20100413145944.GA7716@redhat.com> <4BC48F79.5090409@siemens.com> <1271176838.16881.537.camel@edumazet-laptop> In-Reply-To: <1271176838.16881.537.camel@edumazet-laptop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Eric Dumazet wrote: > Le mardi 13 avril 2010 à 17:36 +0200, Jan Kiszka a écrit : >> Michael S. Tsirkin wrote: >>> The following situation was observed in the field: >>> tap1 sends packets, tap2 does not consume them, as a result >>> tap1 can not be closed. >> And before that, tap1 may not be able to send further packets to anyone >> else on the bridge as its TX resources were blocked by tap2 - that's >> what we saw in the field. >> > > After the patch, tap1 is able to flood tap2, and tap3/tap4 not able to > send one single frame. Is it OK ? I think if that's a real issue, you have to apply traffic shaping to the untrusted nodes. The existing flow-control scheme was fragile anyway as you had to translate packet lengths on TX side to packet counts on RX. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1jLq-0000DF-Nn for qemu-devel@nongnu.org; Tue, 13 Apr 2010 12:52:38 -0400 Received: from [140.186.70.92] (port=35582 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1jLp-0000Ci-AV for qemu-devel@nongnu.org; Tue, 13 Apr 2010 12:52:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1jLn-00005H-Nf for qemu-devel@nongnu.org; Tue, 13 Apr 2010 12:52:37 -0400 Received: from david.siemens.de ([192.35.17.14]:17231) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1jLn-00004x-Di for qemu-devel@nongnu.org; Tue, 13 Apr 2010 12:52:35 -0400 Message-ID: <4BC4A139.3010605@siemens.com> Date: Tue, 13 Apr 2010 18:52:09 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20100413145944.GA7716@redhat.com> <4BC48F79.5090409@siemens.com> <1271176838.16881.537.camel@edumazet-laptop> In-Reply-To: <1271176838.16881.537.camel@edumazet-laptop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , qemu-devel , Herbert Xu , "David S. Miller" Eric Dumazet wrote: > Le mardi 13 avril 2010 =C3=A0 17:36 +0200, Jan Kiszka a =C3=A9crit : >> Michael S. Tsirkin wrote: >>> The following situation was observed in the field: >>> tap1 sends packets, tap2 does not consume them, as a result >>> tap1 can not be closed. >> And before that, tap1 may not be able to send further packets to anyon= e >> else on the bridge as its TX resources were blocked by tap2 - that's >> what we saw in the field. >> >=20 > After the patch, tap1 is able to flood tap2, and tap3/tap4 not able to > send one single frame. Is it OK ? I think if that's a real issue, you have to apply traffic shaping to the untrusted nodes. The existing flow-control scheme was fragile anyway as you had to translate packet lengths on TX side to packet counts on RX. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux