[Cake] Announce - possible new feature - DSCP cleaning
dave.taht at gmail.com
Tue Nov 17 14:05:17 EST 2015
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
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 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
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 at 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.
More information about the Cake