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
nanosecond) resolution.
> 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@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