From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D47EC21F316 for ; Thu, 19 Nov 2015 02:23:51 -0800 (PST) Received: from hms-beagle.am28.uni-tuebingen.de ([134.2.92.110]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Mey7N-1ZjmOo1tdJ-00Oat1; Thu, 19 Nov 2015 11:23:47 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 19 Nov 2015 11:23:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84BE3E0F-5181-42E0-9674-02E18EDB9FBA@gmx.de> References: To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:XHNGp2dqA9gF9Wb4qjiL3lFvXouSz8hQFfscqE86kTY1CcGe7LX X6ravf9xMm4Qo9+yAIzD7z6mP7hpJc6AmVC2weGO6j8YWDhKs6HR9Y7YBWL1eG1JIVBxgVz CWI/M/7N/kPyRMheeSSR+kIViVWxbuD72J88bv6eNEy4GI7VNeGcuAogKglQviRYGYn1hrC 7cx3Z2ddRHigwAOBTm43g== X-UI-Out-Filterresults: notjunk:1;V01:K0:3Oe2o9kjfdk=:DT2h4wnS+J8Ik+Z9UE2Cx8 /UAFtA8a5hyscnkDDWkyeFxjDqe5lTm5SKqkYPCq0Dpk/wZeRpsj+ryDGkKNdUvvrgnmQ8ztN IFtkvjpqtku0AUX6XWdyk2pCCbQLNwzrDdK7EYQSlkQ7r5u1+IXkiPiJmsH7BuCGMmzuMkkU6 NFAZBVaZj45NC1mibv0Cp6vZ7b7rQeQnS9uIMxeMWh3ahB4rATI+Xq6fOmSarsMvrsyOYwTyc u7lAJOrbrMtbVAPd/GbQwpfSh08G4aJQxh/6Z+eBLdvYdm/ztTAjoD0/hKN+LVLqgeklBl8nS VIhX8JTx2D9j+fgCFHvHD/Lpd4rkBJP3sf2eMILb5Z8X1S7KKt7zgVNub3R7w/K3XUmgacQ7g WgQDy1EJ+jmQna7bWwCMPzQ3WB+B0+Vel7AmQ3vg86LT7umFgIRWj5Ym7CfMdQkHGyTrOSeWs u848oopsyQcqweCuAZz7iKxvlrupjxpOAe11EThGHaU0Ia0R4jsiHVquN21v1MPvzamCfMkU9 wAs9pcVa7RVhwMvD9XNVWY3XWGTuh80MvBiwFMHsGc0E4z+m0ADA0NvaxHx3tLy8yPHG5re+E 7IaYNDr3nkGEu1wZ/73bDDBEzUK6RY+4wQHRkvuR3ehVQEnzJyIgK0ffwilLa/BchGPEzpVKk Zx0nBVrcCIOPCbdCaEg/dT76GFwi/ujfCULgp7eumMWAi+GbVC0u2EvQ7bE9FGslvLYg48g6W iy9bKP6mOmtvCm0HsEK8AZAF5dpiN30uqkNa99OerOCmxj/WMkPLfn4lho82l3QpPNsn6smMx bTEu6bV Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] cake coding comments X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 10:24:14 -0000 Hi Dave, On Nov 19, 2015, at 09:55 , Dave Taht wrote: > I sat down to try and think outside the boxes we are in... >=20 > dropping: Dropping an 3+ packet TSO "superpacket" will cause a tcp > reset - would split and drop be possible/useful? >=20 > backports as far back as 3.2 seem to be needed. >=20 > - breaking out all the compatability cruft to a separate file > would be good >=20 >=20 > codel5.h - I've longed to clean this up to make the state machine more > clear and to fit in 80 columns for years now >=20 > - we also still use 64 bit time - which I'd intended for the > never started cake_drop monitor and also >=20 > - because 32 bit wraparound gave me a headache. >=20 > - some notes in the file about differences from this and > published codel would be good >=20 > - can't we use the skb->timestamp nowadays rather than the > control block? >=20 >=20 > hashing on the mac address seems to be possible in the new dissect > api? How? mpls? >=20 >=20 > What proof do we have that 8 way set associative hash is efficient? > Would 4 way be OK? >=20 >=20 > How correct is the dynamic quantum scaling? >=20 >=20 > What is an optimal trade-off between the total number of flows, the > size of the hash, and bandwidth? >=20 > At 1GigE? 10GigE and higher? >=20 >=20 > Autosizing the memory limit is good only when bandwidth is specified. >=20 >=20 > Does a bandwidth 100mbit exactly =3D ethernet at 100Mbit? Is it better = than BQL? That one is easy: out of the box no "bandwidth 100mbit=94 will = not work as well as it should, especially with smallish packets = saturating the link. Close to actual line rate one needs to account for = the real on wire size as accounted against the link=92s brutto = bandwidth, with fast ethernet the 14 Bytes the kernel ads just do not = cut it=85 thanks to Kevin=92s work we have keywords to request that cake = accounts for the whole per packet overhead (see ether-all which still = assumes that the kernel added the 14 bytes =93mac-header=94). BQL seems = better in that it does not care about these details , but keeps the NICs = buffer small when the buffer is serviced BQL will allow to re-fill it, = so BQL should also work well for avian carriers in a simpler more = efficient way than cake. I guess in the and cake does more and is hence = better than pure BQL but on slow machines BQL alone should keep a line = rate link well controlled. >=20 >=20 > Should we be able to increase or decrease the number of flows in the = API? >=20 > Is there a way to get away from act_mirred for inbound shaping and > stick cake in there directly? >=20 > How low can we cut the interval to in a DC scenario? >=20 > VPNs vs the Tin system? A VPN by choice multiplexes flows over a smaller set of flows = and hence will not efficiently use the different Tins. If we allow = passing of the internal markings to the tunnel packet header we really = really should squash these on exit from our DSCP domain not to divulge = information about the encapsulated connection (ECN is different in that = we collect this information from outside our domain anyway, and we = really should pass ECN marking onto the packets after decapsulation, but = I digress) Best Regards Sebastian >=20 >=20 >=20 > Dave T=E4ht > Let's go make home routers and wifi faster! With better software! > https://www.gofundme.com/savewifi > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake