Control: tags -1 upstream On Thu, 2018-03-29 at 14:31 +0200, Václav Zindulka wrote: > Hello, > > thank you both for tips. I'll fix it in program for now. I may try to > have > a look at hfsc source one day, but now I have to finish my project > and get > it to production state. > > > ---- > S pozdravem / Best Regards > > Vaclav Zindulka
You can also try to ask the same question on the netdev kernel mailing list, as Stephen said this is probably due to code in the kernel. > > On Wed, Mar 28, 2018 at 1:32 AM, Stephen Hemminger < > step...@networkplumber.org> wrote: > > > On Mon, 26 Mar 2018 13:34:39 +0100 > > Luca Boccassi <bl...@debian.org> wrote: > > > > > On Sat, 2018-03-24 at 14:43 +0100, Vaclav Zindulka wrote: > > > > Package: iproute2 > > > > Version: 4.14.1-1~bpo9+1 > > > > Severity: normal > > > > > > > > Dear Maintainer, > > > > > > > > I found some problems in tc class show and tc filter show > > > > commands. > > > > We > > > > use tc in large scale (thousands of subnets) on multiple > > > > servers. > > > > Whole > > > > shaping system is udergoing large overview and I'm rewriting it > > > > almost > > > > from the scratch. Tc rules are one of key elements so I started > > > > to > > > > check > > > > and change its whole structure. Until now we had everything in > > > > parent > > > > qdisc 1:0 (all tc filter rules, tc classes). Now I decided to > > > > change > > > > it, > > > > so a lot of classes have its own hfsc qdiscs and in this qdiscs > > > > I > > > > create > > > > whole new structure of tc classes, tc filters a tc qdiscs. > > > > Let's say > > > > it > > > > is a tree within a tree. I can provide simple (prototype) bash > > > > script, > > > > which led to my discovery. (https://pastebin.com/A57x8fq5 - > > > > comments > > > > are > > > > in czech since I didn't plan to release it anywhere :-) - I can > > > > provide > > > > further info if needed. > > > > > > > > Problem is very annoying since I need to get > > > > stats from tc -s class show dev ...etc. > > > > > > > > 1. First problem - tc class show dev enp0s31f6 prints whole > > > > structure > > > > two times. I compared it with "sudo tc -s class show dev > > > > enp0s31f6" | > > > > grep > > > > -c "class" vs "sudo tc -s class show dev enp0s31f6" | sort | > > > > uniq | > > > > grep > > > > -c "class" which produces about a half of records. Reference > > > > class > > > > 2000:ffff (produced by my script 2000 - 4fff) is shown twice > > > > (same > > > > for > > > > 2000: root). I'm not sure about behavior of executing command > > > > twice > > > > in this case but it can't be defined twice for sure. Tc is > > > > veeery > > > > picky > > > > :-) > > > > > > > > 2. Second problem - tc filter show dev enp0s31f6 show just the > > > > parent > > > > 1:0 rules. This one is not so critical, since I don't read > > > > stats > > > > regularly, but for debugging it is very inconvenient since one > > > > has to > > > > know classId of whole parent (let's say 2000:0 qdisc in which > > > > all > > > > those > > > > filters reside). When I execute tc filter show dev enp0s31f6 > > > > parent > > > > 2000: (including colon :-) I get all those defined filter rules > > > > and > > > > hash > > > > tables. But not with base command. > > > > > > > > I discovered this on version 4.9 from stable stretch > > > > repository. I > > > > tried > > > > to install backport version 4.14 but resutls were exactly the > > > > same. I > > > > didn't try to reboot after upgrade yet tho. I'll do this after > > > > finishing > > > > this bugreport. I didn't try to compile newest version from > > > > source > > > > since > > > > I need some kind of stable solution to put it on 21 servers. > > > > > > > > What I expected was to see defined classes just once. And to > > > > see tc > > > > filter rules with base show command without specifying parent's > > > > classid > > > > for every hfsc qdisc containing additional rules and hash > > > > tables. > > > > > > Hi, > > > > > > Since you mentioned it's working in the same way in 4.9 to 4.14 > > > it > > > doesn't look like it's a regression, so a better place to ask > > > would > > > probably be netdev: http://vger.kernel.org/vger-lists.html#netdev > > > > > > Stephen, any comment on the behaviour described above? > > > > > > > No idea, the print code in iproute2 is just taking what kernel > > passes back and displays. Most likely it is in hfsc code which to > > be honest > > is not widely used by the kernel maintainers. I wouldn't be > > surprised if it > > had bugs. > > -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
