[Cake] cake coding comments

[Cake] cake coding comments

[Dave Taht]

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?


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?



Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi

Re: [Cake] cake coding comments

[Sebastian Moeller]

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

Re: [Cake] cake coding comments

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]



On 19/11/15 08:55, Dave Taht wrote:
> I sat down to try and think outside the boxes we are in...
>
>
> How low can we cut the interval to in a DC scenario?
1usec floor.  Specifying an rtt of 20usec would set interval to 20usec
and target to 1usec.  'datacentre' currently sets target to 5usec,
interval 100usec.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] cake coding comments

[Dave Taht]

In other news I just took a hack and slash through tc output. Which
could use more hacking and slashing.

http://pastebin.com/xWZViMDP for those of you with proportional fonts in email.


root@snapon:~/git/tc-adv/tc# ./tc -s qdisc show dev eno1
qdisc cake 8004: root refcnt 2 unlimited diffserv4 flows rtt 100.0ms raw
 Sent 7274837008 bytes 4911119 pkt (dropped 0, overlimits 0 requeues 39977)
 backlog 0b 0p requeues 39977
 memory used: 625850b of 15140Kb
 capacity estimate: 841462Kbit
             Tin 0       Tin 1       Tin 2       Tin 3
  thresh        0bit        0bit        0bit        0bit
  target       5.0ms       5.0ms       5.0ms       5.0ms
  interval   100.0ms     100.0ms     100.0ms     100.0ms
  pk_delay     1.4ms       871us         0us       387us
  av_delay     524us       369us         0us       203us
  sp_delay       5us        13us         0us         1us
  pkts        115935      177925           1      632990
  bytes   171360140b  264615514b       1008b  953769597b
  way_inds         0           0           0           0
  way_miss         9          86           1          15
  way_cols         0           0           0           0
  drops            0           0           0           0
  marks           10           1           0           0
  sp_flows         0           1           1           0
  bk_flows         3           2           0           1
  last_len        66          66        1008       18168
  max_len      68130       68130        1008       68130



On Thu, Nov 19, 2015 at 1:20 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
>
> On 19/11/15 08:55, Dave Taht wrote:
>> I sat down to try and think outside the boxes we are in...
>>
>>
>> How low can we cut the interval to in a DC scenario?
> 1usec floor.  Specifying an rtt of 20usec would set interval to 20usec
> and target to 1usec.  'datacentre' currently sets target to 5usec,
> interval 100usec.

hmm.

>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>