From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eric.dumazet@gmail.com>
Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(Client CN "smtp.gmail.com",
	Issuer "Google Internet Authority" (verified OK))
	by huchra.bufferbloat.net (Postfix) with ESMTPS id 934AF2020B8
	for <codel@lists.bufferbloat.net>; Mon,  9 Jul 2012 07:55:28 -0700 (PDT)
Received: by eeke50 with SMTP id e50so6837518eek.16
	for <codel@lists.bufferbloat.net>; Mon, 09 Jul 2012 07:55:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=RAGv0V/KZ/tnbJZ+DwhCzuYe7hJmBb1v+hCOrDQc+oA=;
	b=KOKs65vb3Kbw/Z0CI7QbCJ8o0at8FPqSC/yIRMQI21nIMHjqxSCrHEUL/5dxoTZgaN
	G9jBbj7w5hUuNT9eaYAhQnS8A2uQZ1NRb0T0BtWA/T/65gIgJOXiZLPYBiqETZiV6/rp
	LwZ1egufEzuOtP65fNfZvy7cL0wu+9Z2PZyD/beSWy/gPVMGeGYSZ2Tz1vc/nqqRi2VW
	Vt5zM2YWI+SBvIyifZKVxWmZGLsES5tONObH7jcfXzTV/5bLqUfVEeWvTx0Ce1CpMhHk
	hxMIz+BKPeba1gTh7HThivWJDiYLP+ZhRjLMQhZ6nc6lyWWigpoOIRlFVF2H3xgTFxGo
	PqnA==
Received: by 10.14.37.69 with SMTP id x45mr9790982eea.48.1341845726142;
	Mon, 09 Jul 2012 07:55:26 -0700 (PDT)
Received: from [172.28.88.203] ([74.125.122.49])
	by mx.google.com with ESMTPS id x52sm94495837eea.11.2012.07.09.07.55.23
	(version=SSLv3 cipher=OTHER); Mon, 09 Jul 2012 07:55:25 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Miller <davem@davemloft.net>
In-Reply-To: <20120709.000834.1182150057463599677.davem@davemloft.net>
References: <CAA93jw7ywd0auqN=k2J4fLOGYMLRH+agWr4P+_CisgvRtvgJUw@mail.gmail.com>
	<1340945457.29822.7.camel@edumazet-glaptop>
	<1341396687.2583.1757.camel@edumazet-glaptop>
	<20120709.000834.1182150057463599677.davem@davemloft.net>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 09 Jul 2012 16:55:22 +0200
Message-ID: <1341845722.3265.3065.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: nanditad@google.com, netdev@vger.kernel.org, ycheng@google.com,
	codel@lists.bufferbloat.net, mattmathis@google.com, ncardwell@google.com
Subject: Re: [Codel] [RFC PATCH] tcp: limit data skbs in qdisc layer
X-BeenThere: codel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: CoDel AQM discussions <codel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/codel>
List-Post: <mailto:codel@lists.bufferbloat.net>
List-Help: <mailto:codel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 14:55:29 -0000

On Mon, 2012-07-09 at 00:08 -0700, David Miller wrote:

> I'm suspicious and anticipate that 10G will need more queueing than
> you are able to get away with tg3 at 1G speeds.  But it is an exciting
> idea nonetheless :-)

There is a fundamental problem calling any xmit function from skb
destructor.

skb destructor can be called while qdisc lock is taken, so we can
deadlock trying to reacquire it.

One such path is the dev_deactivate_queue() -> qdisc_reset() ->
qdisc_reset_queue(), but also any dropped skbs in qdisc.

So I should only do this stuff from a separate context, for example a
tasklet or timer.

Alternative would be to use dev_kfree_skb_irq() for all dropped skbs in
qdisc layer.