From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752531Ab0DMRoe (ORCPT ); Tue, 13 Apr 2010 13:44:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39307 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751983Ab0DMRoc (ORCPT ); Tue, 13 Apr 2010 13:44:32 -0400 Date: Tue, 13 Apr 2010 20:39:19 +0300 From: "Michael S. Tsirkin" To: Eric Dumazet Cc: Jan Kiszka , "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 Message-ID: <20100413173919.GC26011@redhat.com> References: <20100413145944.GA7716@redhat.com> <4BC48F79.5090409@siemens.com> <1271176838.16881.537.camel@edumazet-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1271176838.16881.537.camel@edumazet-laptop> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 13, 2010 at 06:40:38PM +0200, 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 ? Yes :) This was always possible. Number of senders needed to flood a receiver might vary depending on send/recv queue size that you set. External sources can also fill your RX queue if you let them. In the end, we need to rely on the scheduler for fairness, or apply packet shaping. > Back to the problem : tap1 cannot be closed. > > Why ? because of refcounts ? Yes. > When a socket with inflight tx packets is closed, we dont block the > close, we only delay the socket freeing once all packets were delivered > and freed. > Which is wrong, since this is under userspace control, so you get unkillable processes. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1kA6-00063C-Fg for qemu-devel@nongnu.org; Tue, 13 Apr 2010 13:44:34 -0400 Received: from [140.186.70.92] (port=43934 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1kA4-00062U-3I for qemu-devel@nongnu.org; Tue, 13 Apr 2010 13:44:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1kA1-0008KO-IF for qemu-devel@nongnu.org; Tue, 13 Apr 2010 13:44:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38166) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1kA1-0008KG-8d for qemu-devel@nongnu.org; Tue, 13 Apr 2010 13:44:29 -0400 Date: Tue, 13 Apr 2010 20:39:19 +0300 From: "Michael S. Tsirkin" Message-ID: <20100413173919.GC26011@redhat.com> References: <20100413145944.GA7716@redhat.com> <4BC48F79.5090409@siemens.com> <1271176838.16881.537.camel@edumazet-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1271176838.16881.537.camel@edumazet-laptop> 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 , Jan Kiszka , "linux-kernel@vger.kernel.org" , qemu-devel , Herbert Xu , "netdev@vger.kernel.org" , "David S. Miller" On Tue, Apr 13, 2010 at 06:40:38PM +0200, Eric Dumazet wrote: > Le mardi 13 avril 2010 =E0 17:36 +0200, Jan Kiszka a =E9crit : > > 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. > >=20 > > And before that, tap1 may not be able to send further packets to anyo= ne > > else on the bridge as its TX resources were blocked by tap2 - that's > > what we saw in the field. > >=20 >=20 > After the patch, tap1 is able to flood tap2, and tap3/tap4 not able to > send one single frame. Is it OK ? Yes :) This was always possible. Number of senders needed to flood a receiver might vary depending on send/recv queue size that you set. External sources can also fill your RX queue if you let them. In the end, we need to rely on the scheduler for fairnes= s, or apply packet shaping. > Back to the problem : tap1 cannot be closed. >=20 > Why ? because of refcounts ? Yes. > When a socket with inflight tx packets is closed, we dont block the > close, we only delay the socket freeing once all packets were delivered > and freed. >=20 Which is wrong, since this is under userspace control, so you get unkillable processes. --=20 MST