From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr60056.outbound.protection.outlook.com [40.107.6.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 927F13B2A4 for ; Sat, 16 Dec 2017 03:35:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=darbyshire-bryant.me.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iiHrFZi09iViaLYAGLrrbXwZQ4Hnh0xxuuuqMHR2Zmk=; b=XaFm0R4AZEOK1ofrgA5y9YbJfz/3NMRQQT+IVHEWMXfuJhNjHB74w4fWoPsHj/+yWLw7FfAkipRJ9N/PH6ByWRmeAzk0GAG2qW1ig1ftO1FUoM4xJ+u9UJMJY+HskhkFzrkDIHUzOw7nlKczwu8bhcXd5ngcbeT5c3demhOZ/3c= Received: from HE1PR07MB1036.eurprd07.prod.outlook.com (10.162.27.28) by HE1PR07MB1033.eurprd07.prod.outlook.com (10.162.27.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.10; Sat, 16 Dec 2017 08:35:05 +0000 Received: from HE1PR07MB1036.eurprd07.prod.outlook.com ([fe80::b560:2cf9:13b8:387b]) by HE1PR07MB1036.eurprd07.prod.outlook.com ([fe80::b560:2cf9:13b8:387b%13]) with mapi id 15.20.0323.018; Sat, 16 Dec 2017 08:35:03 +0000 From: Kevin Darbyshire-Bryant To: Dave Taht CC: Cake List Thread-Topic: [Cake] options for shrinking cake xstats Thread-Index: AQHTbiYO+RjTeZgXdkCZU20060gF1qNFtTsA Date: Sat, 16 Dec 2017 08:35:03 +0000 Message-ID: <65FBBA53-7D46-4980-BC9C-515459D31EB5@darbyshire-bryant.me.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kevin@darbyshire-bryant.me.uk; x-originating-ip: [167.98.58.242] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1033; 6:ZcKu/UbVPpWWiS34Gs4iXh4NasU6jcfz6rkqvM3oPUrtyWL04g2UP62lTVsEBpiwkL2Bo10/qACUA3wcWaLvg0vUAG6ySV5mFVEY3wtbOXuDvmBRGNpT6azecHG9Sq+OP03j8zY0X2DTT0AzB6BPNwIFKm+rIJUMhDRO9OoX1RrrBbn3HqshKKLWD01q/rYan/QOpkvQpLoyuxMu+RjnSpjhufVPaugGzhd+kzWgImUlZHFIqZ3t9vsONSNrAUNt3YMlwkm3mAlx6wVRPUFcq5jKaZZ/zyq+h10Umk2EJ/Yc0dGpK7EDlZaMfWrwL2k6L3+sMsSObf31GVyzDjRk9XaQfG39uPlLMyjVJW96VdQ=; 5:ymqWQ9leyvTJ2Uz2Q/AsB7jOZtr9KyaLzSBOu6qEY73d0016G4y9be2Fxielmm2FbHQa+OIAgUeotwbwmQyUwpd+H50wQ6MPh2VWnq5glPOzdas0Lf0cXCw4EzPXiQcT8SUiK0tvycrlEYRJvWlbkKKKQU2ALo5JhgpuT/w25X8=; 24:AeIWlblV3ACSxDI9OPz6vlhmMv+AP02ejKFB07wXtMKBtQ/RQ4G6sST9TcfudYxK6Kp4T8qme+z9opXjZ+iZrOjnXfpSCb1KX5dLdfi0Igc=; 7:I8QgtLgG3gEllBv11vzk7mHagOuXwBaT/LgyT5rjtWVWp9MPSAlRqATzbdsCkk0pMJFS72lkzFsg765+Sus3tj4fFQuq4wWymbbXKR6+ZpAA9RiflZP9EehfthR81/RJtTzMFSxL4WVgGQ6AzitB7bcPrXWLc3EsUz+5RXosLXUCsqebnU1MeE/wZd/wYincU7MUIrrgRxqGUiI2Ide7OlXrLVhzpOvCR4/zL3lmJ0/icQhXUJAY/hYYt60C4RRK x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9d1fb115-6163-4412-ddfe-08d5445fe749 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307)(49563074); SRVR:HE1PR07MB1033; x-ms-traffictypediagnostic: HE1PR07MB1033: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231023)(10201501046)(3002001)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:HE1PR07MB1033; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR07MB1033; x-forefront-prvs: 0523CF0711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(366004)(396003)(346002)(376002)(199004)(54094003)(189003)(24454002)(229853002)(6436002)(97736004)(5250100002)(99936001)(6486002)(2906002)(99286004)(33656002)(6506007)(6512007)(478600001)(66066001)(8936002)(53546011)(14454004)(8676002)(86362001)(81166006)(81156014)(2900100001)(76176011)(59450400001)(7736002)(82746002)(5660300001)(305945005)(83716003)(36756003)(39060400002)(316002)(106356001)(25786009)(3660700001)(6246003)(74482002)(3280700002)(6116002)(3846002)(102836003)(53936002)(6916009)(42882006)(2950100002)(4326008)(68736007)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1033; H:HE1PR07MB1036.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: darbyshire-bryant.me.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_8060087B-6A3F-4B20-A103-69E4DC3ADAC3"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-OriginatorOrg: darbyshire-bryant.me.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 9d1fb115-6163-4412-ddfe-08d5445fe749 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2017 08:35:03.3877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9151708b-c553-406f-8e56-694f435154a4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1033 Subject: Re: [Cake] options for shrinking cake xstats 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: Sat, 16 Dec 2017 08:35:08 -0000 --Apple-Mail=_8060087B-6A3F-4B20-A103-69E4DC3ADAC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This didn=E2=80=99t seem to generate any response so I=E2=80=99ll have a = go :-) > On 6 Dec 2017, at 00:06, Dave Taht wrote: >=20 > as 1400+ bytes on the parisc stack, is a bit much. That said, I don't > see much possibility for shrinkage overall. How much over do you happen to know? I see a number of options (6 or = so) that are in essence binary flags passed as u32, could they be u8 = instead saving 3 bytes per flag =3D 6 * 3 =3D 18 bytes. >=20 > A) if we resort to having a struct new_cake_xstats[q->tin_cnt], we > still end up with a big stack on the diffserv8 case (that won't get > caught by a static checker) >=20 > B) I'm on record as disliking any statistics calculation that is not > directly needed by the algorithm. Putting my asbestos suit on, that's > peak_delay_us, avge_delay_us, base_delay_us, way_indirect_hits, > way_misses, way_collisions, bulk_flow_count, and a few others. Dons flamethrower: I have found most of these stats very useful in = determining when odd behaviour is occurring. unresponsive flows = highlighted an ECN oddity ;-) max_len hightlighted some unexpected = behaviour in sqm-scripts for the me the other day (4 hours of my life = I=E2=80=99ll never get back). I=E2=80=99m not a fan in losing them. = Removes flamethrower. >=20 > C) Can we return a tuple to tc saying "we have 8 queues, poll me for = each=E2=80=9D? Passing a structure per tin seems an ideal solution if it can be done. = I=E2=80=99ve no idea how. It must be possible, isn=E2=80=99t that the = point of the netlink interface?I wonder if that nice Mr Shemminger can = offer some clues? >=20 > D) Put the extended stats in sysfs, instead? Not a fan - I like the way =E2=80=98tc=E2=80=99 returns all the = useful/relevant info in one place - I personally don=E2=80=99t care for = digging around the filesystem. >=20 > E) ?? >=20 > struct tc_cake_traffic_stats { > __u32 packets; > __u32 link_ms; // essentially unused, but we could promote > packets to u64. > __u64 bytes; > }; >=20 > #define TC_CAKE_MAX_TINS (8) > struct tc_cake_xstats { > __u16 version; /* =3D=3D 5, increments when struct extended */ > __u8 max_tins; /* =3D=3D TC_CAKE_MAX_TINS */ > __u8 tin_cnt; /* <=3D TC_CAKE_MAX_TINS */ >=20 > __u32 threshold_rate[TC_CAKE_MAX_TINS]; > __u32 target_us[TC_CAKE_MAX_TINS]; > struct tc_cake_traffic_stats sent[TC_CAKE_MAX_TINS]; > struct tc_cake_traffic_stats dropped[TC_CAKE_MAX_TINS]; > struct tc_cake_traffic_stats ecn_marked[TC_CAKE_MAX_TINS]; > struct tc_cake_traffic_stats backlog[TC_CAKE_MAX_TINS]; > __u32 interval_us[TC_CAKE_MAX_TINS]; > __u32 way_indirect_hits[TC_CAKE_MAX_TINS]; > __u32 way_misses[TC_CAKE_MAX_TINS]; > __u32 way_collisions[TC_CAKE_MAX_TINS]; > __u32 peak_delay_us[TC_CAKE_MAX_TINS]; /* ~=3D bulk flow delay = */ > __u32 avge_delay_us[TC_CAKE_MAX_TINS]; > __u32 base_delay_us[TC_CAKE_MAX_TINS]; /* ~=3D sparse flows = delay */ > __u16 sparse_flows[TC_CAKE_MAX_TINS]; > __u16 bulk_flows[TC_CAKE_MAX_TINS]; > __u16 unresponse_flows[TC_CAKE_MAX_TINS]; /* v4 - was u32 = last_len */ > __u16 spare[TC_CAKE_MAX_TINS]; /* v4 - split last_len */ > __u32 max_skblen[TC_CAKE_MAX_TINS]; > __u32 capacity_estimate; /* version 2 */ > __u32 memory_limit; /* version 3 */ > __u32 memory_used; /* version 3 */ > struct tc_cake_traffic_stats ack_drops[TC_CAKE_MAX_TINS]; /* v5 = */ > }; >=20 They=E2=80=99re my thoughts, but what do I know? :-) Cheers, Kevin D-B GPG fingerprint: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A --Apple-Mail=_8060087B-6A3F-4B20-A103-69E4DC3ADAC3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEASyssijGxT6XdZEjs6I4m53iM0oFAlo02rYACgkQs6I4m53i M0ppGhAA3DMr9nfPuQgOo7Zz4zwYSgL8i74iu0r4SADzx6jYvUNgDqnxHIOa6YUG wjWMXb2DJ3Zp4g6QvsTtACFQs2B4uUiaqvmGKfcvUi6ibkRfVa3EHTqHs2k9cE/o r8iS0GXuhziGfvkeZ7nB2gekupPf7VcRf0fWF3wIWAUoC/qwxkere7TotD9JKGQK XyDGZ1f7W7TcMP/KB4zwk3oxMgkHCtk7OJ8q7StQfZE6BRiKjBCK90tbaYF7U325 rNHgd30gVvhh/1rffrlMtqmn7FZKAmK5FWLfEOYxTpHFjT68z6J5xchWTmA8mRkV cQIOtj0z1nsE3/0oArV8eLrRTQV+Ohn5aUjYepg/6kZrXPAWNsz/8+mqZawkLRUR /8C3KH69qmLtSTwfvajCNmJTcuFo+XqmDAUupm1vTypPxho+7z7h1vSLy2IPL60g 8KfbHllrrCHoi6dV6sATr5hLNjBEmry2dWty2NEOXcvphZi/bQbSeX1VsHxn7d9R UYfkbybhUEtb/tUfYALNmJnOtHBl5aGE3JlfTA8lxwOMeHQlqfehj0p0UJSYUBHe 4noT5z7pdnJmZqlqxZWFbk0MqWtxuxohw5LEC4O6s8MdvRAIwp6tOmo8UKw7R+yl 1v5myrqwxTOY73yCJqwp5khmFHH4wtWiN1lPczuxaWjnO7mHbLo= =WgC/ -----END PGP SIGNATURE----- --Apple-Mail=_8060087B-6A3F-4B20-A103-69E4DC3ADAC3--