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 <mst@redhat.com>) 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 <mst@redhat.com>) 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" <mst@redhat.com>
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Paul Moore <paul.moore@hp.com>, David Woodhouse <David.Woodhouse@intel.com>, Jan Kiszka <jan.kiszka@siemens.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>, Herbert Xu <herbert@gondor.hengli.com.au>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>

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