Re: [Cake] cake coding comments

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dave,

On Nov 19, 2015, at 09:55 , Dave Taht <dave.taht@gmail.com> wrote:

> I sat down to try and think outside the boxes we are in...
> 
> dropping: Dropping an 3+ packet TSO "superpacket" will cause a tcp
> reset - would split and drop be possible/useful?
> 
> backports as far back as 3.2 seem to be needed.
> 
>         - breaking out all the compatability cruft to a separate file
> would be good
> 
> 
> 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
> 
>         - we also still use 64 bit time - which I'd intended for the
> never started cake_drop monitor and also
> 
>         - because 32 bit wraparound gave me a headache.
> 
>         - some notes in the file about differences from this and
> published codel would be good
> 
>         - can't we use the skb->timestamp nowadays rather than the
> control block?
> 
> 
> hashing on the mac address seems to be possible in the new dissect
> api? How? mpls?
> 
> 
> What proof do we have that 8 way set associative hash is efficient?
> Would 4 way be OK?
> 
> 
> How correct is the dynamic quantum scaling?
> 
> 
> What is an optimal trade-off between the total number of flows, the
> size of the hash, and bandwidth?
> 
> At 1GigE? 10GigE and higher?
> 
> 
> Autosizing the memory limit is good only when bandwidth is specified.
> 
> 
> Does a bandwidth 100mbit exactly = ethernet at 100Mbit? Is it better than BQL?

	That one is easy: out of the box no "bandwidth 100mbit” 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’s brutto bandwidth, with fast ethernet the 14 Bytes the kernel ads just do not cut it… thanks to Kevin’s 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 “mac-header”). 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.

> 
> 
> Should we be able to increase or decrease the number of flows in the API?
> 
> Is there a way to get away from act_mirred for inbound shaping and
> stick cake in there directly?
> 
> How low can we cut the interval to in a DC scenario?
> 
> 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

> 
> 
> 
> Dave Täht
> 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