[Cake] tc coding comments

[Cake] tc coding comments

[Dave Taht]

Maybe: squash and wash? Squash would be best effort only, wash would
be whatever diffserv model

The "tc standard" for compound variables is mostly whatever_it_is, not
whatever-it-is or "whatever it is"

drops: Dropped_bytes might be a good indicator also

indentation is needed to differentiate between qdisc invocations on mq
and full blown dumps

tc qdisc add dev whatever root cake bandwidth 50gbit does not work

"unlimited" vs "bandwidth X" is asymmetric. "bandwidth unlimited"?

is tc qdisc change dev whatever root cake bandwidth new_bandwidth
Xmbit # is efficient, not drop packets on the change itself?


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

Re: [Cake] tc coding comments

[Sebastian Moeller]

Hi Dave,


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

> Maybe: squash and wash? Squash would be best effort only, wash would
> be whatever diffserv model

	Since besteffort is the default already, I believe there is no need to link two otherwise orthogonal toggles. diffservN (we could add diffserv1 as alias to besteffort?) The man page can then easily explain the options independently and people can predict their interaction, something along the line of:
“The diffserv mode defines how cake reacts to DSCP markings in queued packets, with besteffort treating all markings the same and hence effectively ignores them. Squash defines how cake treats the DSCP bits of packets it passes on the the next layer, by default the markings are conserved, the squash keyword instructs cake to re-mapp all DSCPs to 0”


> 
> The "tc standard" for compound variables is mostly whatever_it_is, not
> whatever-it-is or "whatever it is"
> 
> drops: Dropped_bytes might be a good indicator also
> 
> indentation is needed to differentiate between qdisc invocations on mq
> and full blown dumps
> 
> tc qdisc add dev whatever root cake bandwidth 50gbit does not work

	Potentially caused by -ENOADEQUATETESTHARDWARE and hence not tested ;) ?

> 
> "unlimited" vs "bandwidth X" is asymmetric. "bandwidth unlimited”?

	Good idea, this is only really needed to change away from a limited mode, so users can be expected to request bandwidth explicitly…

Best Regards
	Sebastian

> 
> is tc qdisc change dev whatever root cake bandwidth new_bandwidth
> Xmbit # is efficient, not drop packets on the change itself?
> 
> 
> 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] tc coding comments

[Kevin Darbyshire-Bryant]

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



On 19/11/15 08:56, Dave Taht wrote:
> Maybe: squash and wash? Squash would be best effort only, wash would
> be whatever diffserv model
I like 'wash'.  Done.  Squash is implemented as a synonym for
'besteffort wash' in tc.

Due to the lack of screaming otherwise I have now merged the
'squash/wash' branches of both sch-cake, tc-adv & toke's iproute2 repo's
into master.  It is compile & run tested on openwrt Archer c7 v2.  tc is
compile & run tested on Mint 17.2.  sch-cake is compile tested.

If interested in this release, you need to update both cake & tc.  Old
cake/new tc (or vice verca) may not go into quite the diffserv mode
you're expecting otherwise, especially if you're old school 'squash'ing.

There's an obvious enhancement here too: Specify egress dscp code per tin.



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

Re: [Cake] tc coding comments

[Toke Høiland-Jørgensen]

Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:

> There's an obvious enhancement here too: Specify egress dscp code per
> tin.

I think that is opening a whole 'nother can of configuration complexity
worms that we are better off steering clear of. Especially if they are
to be implemented as regular tc options; we already have way too many of
those.

-Toke

Re: [Cake] tc coding comments

[Kevin Darbyshire-Bryant]

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



On 19/11/15 11:15, Toke Høiland-Jørgensen wrote:
> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>
>> There's an obvious enhancement here too: Specify egress dscp code per
>> tin.
> I think that is opening a whole 'nother can of configuration complexity
> worms that we are better off steering clear of. Especially if they are
> to be implemented as regular tc options; we already have way too many of
> those.
>
> -Toke

ROFL - Why do you think I haven't done it? ;-)


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

Re: [Cake] tc coding comments

[Kevin Darbyshire-Bryant]

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



On 19/11/15 08:56, Dave Taht wrote:
> tc qdisc add dev whatever root cake bandwidth 50gbit does not work
Grins.  I was sort of looking at this yesterday.  It's a 32 bit integer
'limit' within tc.  tc works in bits per second, but what it passes to
kernel is bytes per second (>>3)  So the 32bit netlink API interface can
potentially cope with 34359738360 bits per second(2^32 -1 * 8),
unfortunately tc's get_rate() can only cope with 4294967295 (2^32 -1)
bits per second.  get_rate64() would solve that along with a 64bit
netlink api rate path.

A quick look at iproute2 master reveals netem, tbf & htb as the only
users so far of get_rate64()




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