From: "Michael S. Tsirkin" <mst@redhat.com> To: Eric Dumazet <eric.dumazet@gmail.com> Cc: Jan Kiszka <jan.kiszka@siemens.com>, "David S. Miller" <davem@davemloft.net>, Herbert Xu <herbert@gondor.hengli.com.au>, Paul Moore <paul.moore@hp.com>, David Woodhouse <David.Woodhouse@intel.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org> Subject: Re: [PATCH] tun: orphan an skb on tx Date: Tue, 13 Apr 2010 20:39:19 +0300 [thread overview] Message-ID: <20100413173919.GC26011@redhat.com> (raw) In-Reply-To: <1271176838.16881.537.camel@edumazet-laptop> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com> 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> Subject: [Qemu-devel] Re: [PATCH] tun: orphan an skb on tx Date: Tue, 13 Apr 2010 20:39:19 +0300 [thread overview] Message-ID: <20100413173919.GC26011@redhat.com> (raw) In-Reply-To: <1271176838.16881.537.camel@edumazet-laptop> 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
next prev parent reply other threads:[~2010-04-13 17:44 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-04-13 14:59 [PATCH] tun: orphan an skb on tx Michael S. Tsirkin 2010-04-13 14:59 ` [Qemu-devel] " Michael S. Tsirkin 2010-04-13 15:12 ` Herbert Xu 2010-04-13 15:12 ` [Qemu-devel] " Herbert Xu 2010-04-13 15:12 ` Herbert Xu 2010-04-13 15:36 ` Jan Kiszka 2010-04-13 15:36 ` [Qemu-devel] " Jan Kiszka 2010-04-13 16:40 ` Eric Dumazet 2010-04-13 16:40 ` [Qemu-devel] " Eric Dumazet 2010-04-13 16:52 ` Jan Kiszka 2010-04-13 16:52 ` [Qemu-devel] " Jan Kiszka 2010-04-13 17:39 ` Michael S. Tsirkin [this message] 2010-04-13 17:39 ` Michael S. Tsirkin 2010-04-13 18:31 ` Eric Dumazet 2010-04-13 18:31 ` [Qemu-devel] " Eric Dumazet 2010-04-13 20:25 ` Michael S. Tsirkin 2010-04-13 20:25 ` [Qemu-devel] " Michael S. Tsirkin 2010-04-13 20:38 ` Eric Dumazet 2010-04-13 20:38 ` [Qemu-devel] " Eric Dumazet 2010-04-13 20:43 ` Michael S. Tsirkin 2010-04-13 20:43 ` [Qemu-devel] " Michael S. Tsirkin 2010-04-14 0:58 ` Herbert Xu 2010-04-14 0:58 ` [Qemu-devel] " Herbert Xu 2010-04-14 0:58 ` Herbert Xu 2010-04-14 11:55 ` David Miller 2010-04-14 11:55 ` [Qemu-devel] " David Miller 2010-04-14 11:55 ` David Miller 2015-02-01 11:20 ` David Woodhouse 2015-02-01 11:20 ` [Qemu-devel] " David Woodhouse 2015-02-01 12:26 ` Michael S. Tsirkin 2015-02-01 12:26 ` [Qemu-devel] " Michael S. Tsirkin 2015-02-01 13:33 ` David Woodhouse 2015-02-01 13:33 ` [Qemu-devel] " David Woodhouse 2015-02-01 20:19 ` David Miller 2015-02-01 20:19 ` [Qemu-devel] " David Miller 2015-02-01 21:29 ` David Woodhouse 2015-02-01 21:29 ` [Qemu-devel] " David Woodhouse 2015-02-02 5:07 ` David Miller 2015-02-02 5:07 ` [Qemu-devel] " David Miller 2015-02-02 5:07 ` David Miller 2015-02-02 7:27 ` David Woodhouse 2015-02-02 7:27 ` [Qemu-devel] " David Woodhouse 2015-02-02 8:24 ` Steffen Klassert 2015-02-02 8:24 ` [Qemu-devel] " Steffen Klassert 2015-02-02 15:30 ` David Woodhouse 2015-02-02 15:30 ` [Qemu-devel] " David Woodhouse 2015-02-02 15:23 ` Phil Sutter 2015-02-02 15:23 ` [Qemu-devel] " Phil Sutter 2015-02-02 15:47 ` David Woodhouse 2015-02-02 15:47 ` [Qemu-devel] " David Woodhouse 2015-02-04 0:19 ` David Miller 2015-02-04 0:19 ` [Qemu-devel] " David Miller 2015-02-04 6:35 ` David Woodhouse 2015-02-04 6:35 ` [Qemu-devel] " David Woodhouse 2021-06-25 15:56 ` Bringing the SSL VPN data path back in-kernel David Woodhouse 2010-04-21 11:35 ` [PATCH] tun: orphan an skb on tx Michael S. Tsirkin 2010-04-21 11:35 ` [Qemu-devel] " Michael S. Tsirkin 2010-04-21 11:46 ` Jan Kiszka 2010-04-21 11:46 ` [Qemu-devel] " Jan Kiszka 2010-04-21 11:45 ` Michael S. Tsirkin 2010-04-21 11:45 ` [Qemu-devel] " Michael S. Tsirkin 2010-04-21 19:16 ` [stable] " Greg KH 2010-04-21 19:16 ` [Qemu-devel] " Greg KH 2010-09-14 15:20 ` Michael S. Tsirkin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100413173919.GC26011@redhat.com \ --to=mst@redhat.com \ --cc=David.Woodhouse@intel.com \ --cc=davem@davemloft.net \ --cc=eric.dumazet@gmail.com \ --cc=herbert@gondor.hengli.com.au \ --cc=jan.kiszka@siemens.com \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=paul.moore@hp.com \ --cc=qemu-devel@nongnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.