From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7D1C621F3E3 for ; Tue, 17 Nov 2015 11:05:18 -0800 (PST) Received: by obbww6 with SMTP id ww6so14643319obb.0 for ; Tue, 17 Nov 2015 11:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=khVUGYEWcRxm//DqHMvWIsHKb8PKnJAkrH+6FKJdQIY=; b=feoq6EKlAAI2F90AAgx57z+m5q5VchmJEfyE65C17gFpIfvM3Yq2ztmlx4/DrdBIn4 U8uvPgT55G0xTdVc3A4rrLz2TntSn3xzdKt9tuDvODEUCjELyfeeKwDbO9GzsB3z5MZs hRwS5cYF3oc/Fhus9Vjv+bC0trLD/mugWeppFOww7PEVfBChA3IJYhdNanktKfHs5BIC GTFIBMxi2c6NLTjEbrAsUSKmpyJBg3jhJmB9+yHFqQHmGjfPUzl6jD4XDag3V9D2WgWg oD5878hQbABJkpsGp7QmqxsB/PthJf9VpbnQjIrUIKp1UpihvSNFEAxxMEAW5/9L/paO I6gg== MIME-Version: 1.0 X-Received: by 10.182.236.101 with SMTP id ut5mr27123885obc.73.1447787118014; Tue, 17 Nov 2015 11:05:18 -0800 (PST) Received: by 10.202.50.130 with HTTP; Tue, 17 Nov 2015 11:05:17 -0800 (PST) Date: Tue, 17 Nov 2015 20:05:17 +0100 Message-ID: From: Dave Taht To: Kevin Darbyshire-Bryant Content-Type: text/plain; charset=UTF-8 Cc: cake@lists.bufferbloat.net, Jesper Dangaard Brouer Subject: Re: [Cake] Announce - possible new feature - DSCP cleaning X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 19:05:41 -0000 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 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. > > > > > >