From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0098.outbound.protection.outlook.com [157.55.234.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B2E873B25E for ; Wed, 1 Jun 2016 11:54:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=darbyshire-bryant.me.uk; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=de2h/B/BxcBunNpTOZh7i7vxIsE1E9N5FIKE8APMa2g=; b=wrvwJC8buDOfT8HsFkZLzX5KVb56B39+IdNZlUZsmAuAYEik+tFa+dQzS9NdiVBXqDuJZg0ALlihDfuTWcCAB5XKADWc+/MQBCMwnNFONYY+tWuAoU4zdH2Xn7zT6FMXm1/FnLu8usTquohGErlj+I+LQ1CLQOqTHNvNhzoYIv8= Authentication-Results: lists.bufferbloat.net; dkim=none (message not signed) header.d=none; lists.bufferbloat.net; dmarc=none action=none header.from=darbyshire-bryant.me.uk; Received: from [IPv6:2001:470:183f:da2b::4007:25d] (2001:470:183f:da2b::4007:25d) by HE1PR07MB0938.eurprd07.prod.outlook.com (10.162.27.144) with Microsoft SMTP Server (TLS) id 15.1.506.9; Wed, 1 Jun 2016 15:54:55 +0000 To: Jonathan Morton References: <574EC9B6.90708@darbyshire-bryant.me.uk> <8A50E29E-5CEC-4DFB-9227-69EFE66C7D02@gmail.com> CC: From: Kevin Darbyshire-Bryant Message-ID: <574F054B.9080506@darbyshire-bryant.me.uk> Date: Wed, 1 Jun 2016 16:54:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <8A50E29E-5CEC-4DFB-9227-69EFE66C7D02@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [2001:470:183f:da2b::4007:25d] X-ClientProxiedBy: HE1PR0701CA0008.eurprd07.prod.outlook.com (10.165.214.146) To HE1PR07MB0938.eurprd07.prod.outlook.com (10.162.27.144) X-MS-Office365-Filtering-Correlation-Id: 29380c65-391b-4dc8-5c8e-08d38a3513e3 X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB0938; 2:f3lwI9R2OiGDV2yQJ2QG0TIdM3pD6f2Da+XD/AuwVkHZW62Ijxvj8nfnEb6kbBIBGeTaids4uXmH7GRGF0C6kaDkzpe57zUabCKWKr+npj9AbgF5s7Od//72aYuT/TVyfneoJ5cG2eIxkKYybehlePKFmlYPydozA+FlLetm4StNjwY/J4pZfIa2kiM0LYR2; 3:5J0H++ak3IdI1VM/f9gXiuhCIVJXFfeC61OLba5g8RqZJp8BR90maEpLbeV1tIH+K8aYmT6c845oINlk2+12vmOKA16fl52hgAm1211FtI1E44kLk6ePHNU7RQWWBt9u X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB0938; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB0938; 25:NbwHl3fZUkTWV9SnI4lwFc0484ujRxn6hYEUTYPEI3sVvZHd697LIBV+q3UNxgBffR/PQOgiMeBSl+fPjgbZMyiMF67VNGC9JP3PijMsZI+IVPED4tyKz3c6ZPJ0KIqHwRdpGDk24AAScX25qIA7S1EgRR7GPFkooUEPZ8nc566xQ+DGEBzV/vwp4pzySQsk91Jb+3LuJRqH2gOmQnLPMXqwp9aFOKDjQYpb0FPKOJzTw84z/YBoB6vWfjpabw1rQXd+JdUKgW9kxmaZucmuLbwgXTRUIkwqp2s/Ab5DNOkKlLSB2OwVvEG2XMUGOcatltwPPBbCrxJeCWg8Tr0mOUzykErUICijrhJxvzl8XDTWnJv40dkSTS/yzupYpMa3ewg9FCIhDG9VVPqCwZDDp7381XeyUTjOzHi3PNDYXpewaJtMj1A8N8atNdlbW+QvQ9uYWarDJXQ/d7ALkx4Dp4ynDv/uSlihRfJ+1dRPMxipY8pMclOc6m2H7g1ABuF6weKVOZOy/A6tfg1IrBDg7MRd3QMuidXancLOwL3lWMMC9eKThZKL6Qk7GxHAWdg7FoxjVry49Zdyest981jvd59VuiTskY4RnSQ0MmJkI/8MWK8iMA3gOfFEKu/gEbZ5u3qd920ieZsM8sTXAULpaSnXruy625SbqMUoCENBCK81ijMF8848z4jx7n6gP0PovCR6S2fb06BylXwq5yCFX1YzRwLK/rqladGF/Pw8H9U= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:HE1PR07MB0938; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0938; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB0938; 4:uu9+ic6RphT+QcTdDPxcNUvjWVopj1xyIQw0iAjPEJjVlhZjEji/66dbWIZ+fIxxjf/Q1fpuEpvFHrFTvk4/LywJc5VO/ce/g2XNyI5LkGOKkB387WnofyOUybdMpc3zc2ZHZYcqB0BWPqY4Cw6DVgHdItOdG5KcvXctUEtw8WjHCSRh523fkwheP7bii0LYJ2bSO8nTKNXFPfEoBRK/qraVwxAo/hhA/yYs5Pn5j43RwDcKoQcqS59bj2dLp1QI4RF711ipgcrqeqx9dGhAGhLvV3oYnZw1hasTEhcJK0h6nu8aGqboBSBvOo2lHwFXIDY2TGBD/6q2/WnMZf180W9yAkv5QycBieZEXCypm/nLBzhi6MIV9vfCRMe6jqg9DTEmixidQ+4f2ZdCU7wWgYuWRt4WNdkb8RYly1jGJgFofBPvbufwq3fGrdGS+iH0hGuyt55pVP0Bl/agI4G8Kg== X-Forefront-PRVS: 096029FF66 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(24454002)(1411001)(77096005)(2950100001)(2870700001)(5008740100001)(36756003)(189998001)(42186005)(4001350100001)(110136002)(59896002)(86362001)(33656002)(74482002)(54356999)(50986999)(65816999)(87266999)(76176999)(47776003)(92566002)(65956001)(65806001)(5004730100002)(19580405001)(19580395003)(586003)(50466002)(81166006)(6116002)(80316001)(4326007)(2906002)(8676002)(23676002)(83506001)(3076002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0938; H:[IPv6:2001:470:183f:da2b::4007:25d]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIwOTM4OzIzOmUrakdWdzcwZWM2RzYxWjZlU3JFbXNYRGY1?= =?utf-8?B?Q2Vrbm1wVjRlSmppYkJGZFdRWGZhYzgxZ0ZnM2hkODU2SjN0K2FTY1ZmSFpx?= =?utf-8?B?MG5Kb2JRUTYya2JqK1hJUUZpdUJLU29RcW9WUVdpK3dCWnF2bm4vNHkwMnJU?= =?utf-8?B?Vlc1M2NFUUczTnA5bWFHc1pNNEdWZU5zZHB6dXpBSFpMYlpsS2VtUU5wZlNZ?= =?utf-8?B?dWJBL0VJNm4zUldWSDFBdWdrTkRaT1kxZXNqMjd5VGxJd2pCdGdyVWFjVVIw?= =?utf-8?B?cDViZVNrejBhSjVSMC8zSjVROHptOUJPN2ZvazBDZUt3dFdnZUJ5aWtwenJs?= =?utf-8?B?VkV1Zjd4Nms1Ri9KV3BNalFDa1laZkV1eER0YWdBcU5kd2JWWHRjRjZGWm83?= =?utf-8?B?NDNVS29USFAwVzFJbGswNS91V2xYNUlDQXBXQ2RzdVROQ3MzTUQ3ZXE1eWlw?= =?utf-8?B?OWFIS2s2bnc0QXNYdkFNLzY1T2xISFozaTM0NHB0aTJGQ1RHRnM1Q1NQV1By?= =?utf-8?B?SDJPWkFJd1k1OUVpQUIrMWpRaWtVTG1ER1lwWU9kNld6aVRoM045aitlYld5?= =?utf-8?B?a2dYOTM0SytibFIxY0NXdUFKT1VoQnhqOTRNNERpa3lWYnNlUDhNN0FjV08z?= =?utf-8?B?ZFRQWDN1TXVpVm5nR3A2RU9mTmI2dkM5OWoybTNFTHBGKzFoajkvaFBRaFNn?= =?utf-8?B?emVtb1hEWXlYNE5ic0NONWZMejg4ckp2ZXVna0o4eGQ2MytrRzlFNmk2M0RC?= =?utf-8?B?QkQ3anVpOEVSamVqeFhWY3M1Z0VHbFZMaEhVY0t1WGRGRjFUNnlNMjY4Ujcz?= =?utf-8?B?YmtsbnZwNlJzZm1pWEc0aHUzMDBMMWc3ay9ZeHNlcDViQVBzZXdoVkNuVG5Q?= =?utf-8?B?VitoaTRsTUFLUlVBdXVlSHFhZWg3YUt2bHUwMUpyRTNPeW02dVh3TnNqdjBt?= =?utf-8?B?K1dYQTYrcnZoV1p2aXpsNFhGWFhYazY3a3J2RENqRlJnZXIyTWxuV1RKb1Vq?= =?utf-8?B?Zk5zZTZMMnpCNDVodHJVcGZrNU5TZTA1bTRWVEZrd21ma2V5enQ0eVpUUUhQ?= =?utf-8?B?b0dKNEw0TVBGRzRJaGUzVEsvTGpnbjRWbEtMdEVKZjV5RWlGWGdEeXlMNXVO?= =?utf-8?B?UTh0NXV6ai95U1Rzak8zSXZtZzBqcG5qTXpjTVkyQ3kvUnlwU2t6V21iQ2FY?= =?utf-8?B?djJvdERVVEpLVDRyUXF6SUZPUEJ0OEFPTHhlNURnVXNBNFE4YXpXVzRUbHJZ?= =?utf-8?B?ekVtdi9sUTc1bDVtRTlQY3NxRXlTTW45UXBhM2ZKLzZOMU5aelE5dm5iOVFn?= =?utf-8?B?S1o2Z01jMURZM1NHald2RUpDZFpXUUlKODVQRzFLWDZpSm5Ga3VUeE5Vd0RH?= =?utf-8?B?a1EzeEpuLysvcnlUQnFQTTU4em9pQ0E1c2RJcTZxUktEdlQ5b3VaWm9kZFJP?= =?utf-8?Q?K8+CHzhTjCG6eGR2LKLKqks4Qee?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB0938; 5:dqDUKZPpg+RKYmZKVLkvTP80Q7Iefu/EbszmXOO4U6tgdm7P7Po2tSBxAAhxnz0tnddqXbQg70nXjftNbSSeM4WY2j1iO7nI5ZOfXq4WC8sTXUGj5nV2DueARv3vX1tAdZgAL1xcsQWhDFvaSnrkUw==; 24:OaH91LNI02oHRwOXfO6m1WR2iB/9gLy0eylgn75pPsQOcucOSjt770p7z6oN9VfRLPR9GrIzVwFW/y4OefDfmIyk7+/JVHneityU3UFfhbA=; 7:ORmyhv3AIpgmz+0my12GfSxYyzRIumQzXyHZHhQR9OZPzoqh60AeDUD77plo0evX3nNQdr46TFemTYnWNo64IqWaafP918w7U4ktq155xctkiXU/cxOb62Y/C/gaebTor2Gis51UZX9SVPASEGa6QeYvZLeOoyIYo7sldl6nRQVN5a1T1xTRno3U6Cut9Xr1 SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: darbyshire-bryant.me.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2016 15:54:55.8751 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0938 Subject: Re: [Cake] Dropping last_len from stats collection & display. 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: Wed, 01 Jun 2016 15:54:58 -0000 On 01/06/16 15:00, Jonathan Morton wrote: > >> On 1 Jun, 2016, at 14:40, Kevin Darbyshire-Bryant wrote: >> >> Not updating another variable (memory write) for each packet may help cake's CPU usage a little. > > I’ll think about this one. > > I don’t think it should gate the LEDE merge (nor should it require a stats version bump), since as long as the entry remains in the stats struct, it will simply remain zero if not written. > > In future the space could be reused, in which case a version bump would be appropriate. > > - Jonathan Morton > Two points/suggestions/alternate perspectives: Not bumping the version leads to a situation where tc constantly reports the last length as zero. I would suggest that looks odd/oversight/wrong. A version bump at least allows a later tc to know not to output a dead value. I can see your point with regard to the structure size, how about re-adding as u32 __attribute__((used)) last_skblen; /* V3 and below */ to stop the unused variable warning that would otherwise result. The other argument I keep having with myself is "none of this has been released...yet". Aren't we still free to break this as we see fit :-)