Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht <dave.taht@gmail.com>]

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.

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.

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
             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       4.6ms       924us         0us       1.1ms
Av-delay       1.2ms       598us         0us       454us
Sp-delay       312us         0us         0us       179us
  pkts         43938      104843           0      468916
  bytes     63945533   154488126           0   708247426
way-inds           0           2           0         333
way-miss           6         528           0          10
way-cols           0           0           0           0
  drops            0           0           0           0
  marks           17           2           0           0
Sp-flows           0           1           0           0
Bk-flows           1          13           0           1
last-len       28766          66           0       68130
max-len        68130       68130           0       68130






On Tue, Nov 17, 2015 at 7:52 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
>
> On 17/11/15 10:12, Dave Taht wrote:
>> we can break anything until it goes upstream. I'm not satisified with
>> the api (or wasn't 2 months back)....
>
> Could you elucidate on what is wrong with the API?  My understanding of
> the present code is that additional options can be transferred between
> kernel space & user space (tc) with 'ease' via the netlink API.  Indeed
> the 'squash' enable/disable option is passed as a new option via this
> API.  Also look at how easy the recently implented rtt, target & memory
> options were to introduce without backward/forward compatibility issues.
>
> Where it falls down is where one passed option is used to control more
> than one thing - that's not an API thing really, it's how we use the
> API. For example and in my opinion, squash should not have been passed
> as a 'diffserv mode' as this limits how combinations of diffserv mode &
> squash may be implemented.  That's precisely why I took the step to
> split out the diffserv mode and squash mode (like for example 'atm'
> compensation or not)  Because 'squash' was previously regarded as a
> diffserv mode it does cause a compatibility issue (it won't blow up, but
> it may not go into quite the mode expected, or the reporting of mode via
> tc may not quite match'
>
> Personally, i'd say break it now while we can and get what I consider a
> better implementation out there.  I'm not the only person out here, on
> this list, I may be wrong.
>
>
>
>
>
>