From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C967D3B2B0 for ; Sun, 12 Jun 2016 14:00:03 -0400 (EDT) Received: by mail-lf0-x231.google.com with SMTP id j7so48758372lfg.1 for ; Sun, 12 Jun 2016 11:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wVyeocs4998gNJ4ORRUY/vytCsdQXLfzqiGHEyozRkA=; b=wEnBgMtj0v2X/APSjFu6dE8wMXnjfiLcZYdOukvpD+53sWbRSmMFs+tPW3qVcD7a5A IOxuJCGMTIZhlXDrtepXXDv1FSZUR7dBpVBRX02XWWjRIxUMDSqkk+hdV+PrOchQg2gW TIpEEDShh297QihiIqEuRTG1boGBBtlY7G12YUsp/BQWdc8G99VVgxCfiBc8dhgk/8Wp xI1aRoJ+3vPzIAlmynPPDm+R4D4JnTZefH/PYQG8cEvXWCJm4umAvWYOunTMcUiVw58+ eeMVbJVOisltQfb3ljKM0O81BQz2UKQtprkzOjYoPB4v03vyMDq67u9qCfNbpAIpGtzL eHUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wVyeocs4998gNJ4ORRUY/vytCsdQXLfzqiGHEyozRkA=; b=AlL2QbkICcdAJm4l8Aar4qKgrA8mA1kCs57Y5aRVsMtgWzW9Lx3Zjm+rMiwAkpx00w EbCiE6SHN1FK4pN4q/4ljq255i8MKZ+kDbG5CqrWUXIGtMtv9w0VmEd5V32s2MFoe6j6 gfoa7iXJ7Bqqf6fdmwRuC2yFnrISXoIiSXlKTvzmR6PAE7vh2R7tYTC6DzWBdD4gDdE7 gu22dLWE+hwYPhz5W4rlq6GvZWr4Jd0FgqMjxmbEVYx0aX0WqxAUh7wP7xsrImBoI4J5 LWegxYhb8Vi7p+y5o/3sxg4bdLZf87j4mAPj4rQ+SFYXMW5ep66jboWgk7GVvqqo+3TP 2UFw== X-Gm-Message-State: ALyK8tLElSCcu8//KQdSCAcoMoyidAmTL2tWpxcp7GS03o4f5I3Y2B/MT5jkJ//UWfma5Q== X-Received: by 10.25.33.2 with SMTP id h2mr2414515lfh.186.1465754402674; Sun, 12 Jun 2016 11:00:02 -0700 (PDT) Received: from bass.home.chromatix.fi (176-93-9-44.bb.dnainternet.fi. [176.93.9.44]) by smtp.gmail.com with ESMTPSA id f6sm2306695lbt.31.2016.06.12.10.59.54 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Jun 2016 11:00:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <1465749085.7945.81.camel@edumazet-glaptop3.roam.corp.google.com> Date: Sun, 12 Jun 2016 20:59:48 +0300 Cc: Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <5756ADEC.9070305@darbyshire-bryant.me.uk> <8EE35B4F-5C28-41C7-8795-93A6F606B3A8@gmail.com> <5756E2CA.2020700@darbyshire-bryant.me.uk> <575BD5D0.4060702@darbyshire-bryant.me.uk> <98AFD8C3-2343-4B8B-BFB0-6F877161A039@gmail.com> <1465749085.7945.81.camel@edumazet-glaptop3.roam.corp.google.com> To: Eric Dumazet X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] Possible BUG - parent backlog incorrectly updated in case of NET_XMIT_CN X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 18:00:04 -0000 >> And there=E2=80=99s also the problem that we might not need to drop = packets as >> large as the incoming packet in order to fit the latter into the = queue >> - so this corrected correction may be *negative* (the queue is longer >> than before) - but qdisc_tree_reduce_backlog() only takes an unsigned >> parameter here. >=20 > That's a very minor detail. >=20 > If the code does : >=20 > reduce_backlog(unsigned quantity) > { > q->backlog -=3D quantity; > } >=20 > Then the fact that @quantity is signed or unsigned is irrelevant. Not so - unless you are very sure that q->backlog is the same size as = quantity. In an increasingly 64-bit world, that is by no means assured = in the future. I don=E2=80=99t like relying on wraparound behaviour = without making that assumption explicit, which is precisely what the = signed types in C are for. >> IMHO the NET_XMIT_CN semantics are broken. It might be better to = drop >> support for it, since it should rarely be triggered. >=20 > What exact part is broken ? > Semantic looks good to me. It=E2=80=99s broken in that a negative correction may be required in the = first place. It places additional burden on every producer of the CN = signal who isn=E2=80=99t a tail-dropper. I can only assume that the = behaviour was designed with only tail-drop in mind - and as we both = know, that is not the only option any more. It appears to me that there are four things than enqueue() may want to = tell its caller: 1: That the packet was enqueued successfully (NET_XMIT_SUCCESS). 2: That the packet was enqueued successfully, but some other relevant = packet had to be dropped due to link congestion. 3: That the packet was *not* enqueued, and this was due to link = congestion. This is potentially useful for tail-dropping queues, = including AQMs. 4: That the packet was *not* enqueued, for some reason other than link = congestion; the =E2=80=9Cerror case". Currently NET_XMIT_CN appears to cover case 3, whereas Cake normally = wants cases 1 & 2 (and will only signal case 4 if a GSO aggregate = couldn=E2=80=99t be segmented). For the time being, I have changed my development branch of Cake to = always signal case 1 except for the error case. - Jonathan Morton