From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <toke@toke.dk>
Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by huchra.bufferbloat.net (Postfix) with ESMTPS id 4711221F420
	for <cake@lists.bufferbloat.net>; Tue,  3 Nov 2015 04:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at mail2.tohojo.dk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310;
	t=1446555584; bh=bKrxIf+4iVp4khGCHiehe29lUiZ0S+Ft+KQQIugMMes=;
	h=From:To:Subject:Date;
	b=LZUuZC2lBnSVwgyNjyH13pGYhDd2iQtOErlnoVkb/mDB0/1Dvg3OFSnD7d4/yRogT
	D5QUSHR0ZHZ0+2WgjP21VOQ3nzDDLozlR8SG0f82U2tYsNS9fRVfvrwemM2EYgxXsy
	wbDI/KKLBLddq385xjvYiCjjmAqQLfkdPXZdHeRg=
Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000)
	id 135CEC402A1; Tue,  3 Nov 2015 13:59:44 +0100 (CET)
From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
To: cake@lists.bufferbloat.net
Date: Tue, 03 Nov 2015 13:59:44 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87oafbnsqn.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Subject: [Cake] Correct 'change' behaviour
X-BeenThere: cake@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Cake - FQ_codel the next generation <cake.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cake>,
	<mailto:cake-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cake>
List-Post: <mailto:cake@lists.bufferbloat.net>
List-Help: <mailto:cake-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cake>,
	<mailto:cake-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 13:00:35 -0000

So we've seen a couple of issues with reconfiguration being weird (i.e.
retaining previous values). Looking at the code in cake_change() and the
iproute2 code, this seems to stem from the fact that tc only sets the
parameters (in the netlink message) that are actually specified on the
command line, and the kernel only changes the parameters specified in
the netlink message.

This leads to the different behaviour: On init, not specifying a
parameter means "give me a sensible default", whereas on a reconfigure
it means "don't change this parameter from its current value". This is
obviously inconsistent. I'd argue that the right thing to do is the
former in all cases; is there any reason why that would not be the case?
If not, I'll go fix it :)

-Toke