From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 1CAA13B2A4 for ; Sat, 16 Dec 2017 03:45:56 -0500 (EST) Received: from hms-beagle2.lan ([79.210.203.204]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M8IuM-1fCr6x2IAk-00vyOi; Sat, 16 Dec 2017 09:45:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: <65FBBA53-7D46-4980-BC9C-515459D31EB5@darbyshire-bryant.me.uk> Date: Sat, 16 Dec 2017 09:45:53 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <60FF23DB-9335-40B9-A604-B07B97215BE4@gmx.de> References: <65FBBA53-7D46-4980-BC9C-515459D31EB5@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:KzpC/k0Atl0nwU/CfXxvXO+HjjvkhycJozr6M1YghrGMzpjd5xG 0/vMCnMw60mSwTfZLlCZP9vlsIIw7xaSSyZxeKYmKanjRN4XNCRzDbzw2Eep/rfvagGyw1E fyj3GIGcRES2bPhqcDcFh/kpPpmjF5DxDyIRS1R8IlWk2ducU/GZ/48MDlWkuL3F+tSEvx5 jHGd17Owqm6qeEGHQ8j6w== X-UI-Out-Filterresults: notjunk:1;V01:K0:g5cNPLIVU80=:nYk+CqlGfsz5TOyYlnehZP vTYdnz7BtA58rbPpYIO++/kfbrQZntbX3iwjOPX8kxAJXxfdqzxttFZwhl5N8WK4LnXBca2pv m9DDi14zMUfVKeO5mOfhc0ODzSKbCDyG2vbSkLdkpXWI5rJ9LJSSh8ZHzThSeabEwQIhY0dHX EaoDMOAN9i7FESVZVAcipGEtJzmluMnnzCCUV2bpbJa1TlVyJyFNnYXVpM3oyDTuPjkDjbWh0 Vh0Udqrv0791SGYmfIG7Ss/JsHqFh1QN4b38fecSbK8xNmnZbScMULUOKqRB3EOMnsfLWckMn gI5PJRPGyC9H6uqLLF+0QYSgpNt9BCtj/0nPdqtIx/qQ+MulysfOuJCHJzJjm3dZyCkMf64yE s5G9uHkofi2nqHPJXvTddbQ/bhTpENidVOlDsDzCFKxQbeaLvBxpuvy/SLYr0rW7BQWARvpZw NjYzBExL5xL3yC5UVeUPHXVzKkHLSje7CJt4satrtqbtiGTCOjHpFfAav8lVG/PskhctyZDdQ 2DGHazj6G0wsetBy+TcaNLpTWvxhFL85L+IjkWjfYjt0Jj6MjqbHDEvPjO7eK96Lkmhy7kG1V pRQr0IqlGhwVr1s+4dlNd1Dm58EMUnf9F0tBnz30pweSUQ0Xp9zOuLqBQaiVRuw44+0o48VnU Cr5JKdCnrUjr7YQMNSbp/NHvzyYg7qsr7WzSnLXhOmIL0FT5NeYyNWZEe0anAZnsCoeEVSywp p4oAmVX4rDN6P5HXWwxzaQimLb5uFM2/Frw6R+wXvGcULfAPSdPicjICYS6o1IhOIPDbLGCeL ZAmw3LwA7VulbKL80T+Pmy2XBGHyaZkCaIsD0/5wUiWCdJIEWw= 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:45:57 -0000 Hi Kevin, > On Dec 16, 2017, at 09:35, Kevin Darbyshire-Bryant = wrote: >=20 > This didn=E2=80=99t seem to generate any response so I=E2=80=99ll have = a go :-) >=20 >> 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. That got me thinkong, how about a u8 interpreted as a bitfield? Then we = go from 6 * 4 =3D 24 to 1 byte... (or make it a u32 leaving plenty of = room for the future ;) ) >>=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. I wonder whether we could make gathering and reporting those = conditional on a keyword like "expensive_stats" so that only users = wanting the information pay the cost... >>=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. Mmh, but what if tc did that digging for us, so no change from = observable tc behavior, just a different implementation? But as always, I have no real clue on these things and am mostly = improvising on Kevin's theme here... Best Regards Sebastian >>=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 >=20 > They=E2=80=99re my thoughts, but what do I know? :-) >=20 > Cheers, >=20 > Kevin D-B >=20 > GPG fingerprint: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake