[Cake] Announce - possible new feature - DSCP cleaning
kevin at darbyshire-bryant.me.uk
Wed Nov 18 06:17:42 EST 2015
On 17/11/15 19:05, Dave Taht wrote:
> I have had about .01% braincells on cake for 2 months, and only
> causually was reading the list. It is my hope that this time - as the
> test results are looking quite good - we can at least get an RFC patch
> upstream for further review.
> A) One big debate I remember going by was about accuracy of various
> settings, where one value would be weirdly rounded to another when
> read back.
Can, opener, worms all over the place! I suspect you're referring to
tin target values (and intervals) drifting away from the defaults of
5ms/100ms. This is because cake_set_rate() calculates how long a
MTU*1.5 packet will take to send and if it's longer than the supplied
target value it'll use the calculated value instead. Interval is sanity
checked to be at least 'used_target' * 8. This is most obviously
observed in a rate specified & diffserv config where tin++ gets reduced
bandwidth (reduced rate) so the likelihood of MTU*1.5 duration exceeding
specified target increases. This looks like weird rounding. The jury
hasn't even been assembled, let alone sat as to whether these
(potentially) increasing targets/intervals on 'slow' links is a good
thing(tm) or not.
> I do not have a problem with a pure 64 bit interface between userspace
> and kernelspace, if that will alleviate the problems. The cost of
> doing that, now, is trivial.
Again, I think what you're seeing/thinking of is evidence of an internal
calculation process rather than insufficient bits between kernel/user
space. Although it does only speak in microsecond (not millisecond or
> Try to cast yourself into a future - 20 years ahead - with a 10240
> cpus embedded in your head, when the onboard network-to-brain
> interfaces have 8ns latency each, and think upon how someone would
> curse us for not having forbearance enough to understand how much
> different the brain-cell dscp had to be to get multicast to all the
> neurons.... (or something like that. :))
> Another way to help spur visualization like that, is think 20 years
> past - to 1995 - and where networking stood then.
> B) Also, I think, but am not sure, that most parsers of tc -s qdisc
> output will break unless the root of the qdisc has 0 indentation and
> the rest, at least 2.
> C) And I kind of expect netdev to want all those stats in some sysfs
> thing rather than tc, but will defer to stephen/jesper - guys, will
> this sort of tc output go upstream?
> d at snapon:~/git/tc-adv/tc$ ./tc -s qdisc show dev eno1
> qdisc cake 8002: root refcnt 2 unlimited diffserv4 flows rtt 100.0ms raw
> Sent 6079713916 bytes 5489146 pkt (dropped 0, overlimits 0 requeues 28656)
> backlog 0b 0p requeues 28656
> memory used: 612600b of 15140Kb # not huge on parsing this
> capacity estimate: 724522Kbit # not huge on parsing this
That's a function of the sprint_size(), sprint_time(), sprint_rate()
(and matching get_*() ) helpers provided by tc. Similar 'playing with'
units can be seen in the threshold values for each tin. A 'classic'
example demonstrating both A) and unit playing:
qdisc cake 8005: dev eth0 root refcnt 6 bandwidth 1Mbit diffserv4 flows rtt 100.0ms raw
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
capacity estimate: 1Mbit
Tin 0 Tin 1 Tin 2 Tin 3
thresh 1Mbit 937504bit 750Kbit 250Kbit <-tin 1
target 18.2ms 19.4ms 24.2ms 72.7ms
interval 145.3ms 155.0ms 193.8ms 581.4ms
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
More information about the Cake