lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 25 Aug 2019 10:52:27 -0700 From: Cong Wang <xiyou.wangcong@...il.com> To: Akshat Kakkar <akshat.1984@...il.com> Cc: Anton Danilov <littlesmilingcloud@...il.com>, NetFilter <netfilter-devel@...r.kernel.org>, lartc <lartc@...r.kernel.org>, netdev <netdev@...r.kernel.org> Subject: Re: Unable to create htb tc classes more than 64K On Wed, Aug 21, 2019 at 11:00 PM Akshat Kakkar <akshat.1984@...il.com> wrote: > > On Thu, Aug 22, 2019 at 3:37 AM Cong Wang <xiyou.wangcong@...il.com> wrote: > > > I am using ipset + iptables to classify and not filters. Besides, if > > > tc is allowing me to define qdisc -> classes -> qdsic -> classes > > > (1,2,3 ...) sort of structure (ie like the one shown in ascii tree) > > > then how can those lowest child classes be actually used or consumed? > > > > Just install tc filters on the lower level too. > > If I understand correctly, you are saying, > instead of : > tc filter add dev eno2 parent 100: protocol ip prio 1 handle > 0x00000001 fw flowid 1:10 > tc filter add dev eno2 parent 100: protocol ip prio 1 handle > 0x00000002 fw flowid 1:20 > tc filter add dev eno2 parent 100: protocol ip prio 1 handle > 0x00000003 fw flowid 2:10 > tc filter add dev eno2 parent 100: protocol ip prio 1 handle > 0x00000004 fw flowid 2:20 > > > I should do this: (i.e. changing parent to just immediate qdisc) > tc filter add dev eno2 parent 1: protocol ip prio 1 handle 0x00000001 > fw flowid 1:10 > tc filter add dev eno2 parent 1: protocol ip prio 1 handle 0x00000002 > fw flowid 1:20 > tc filter add dev eno2 parent 2: protocol ip prio 1 handle 0x00000003 > fw flowid 2:10 > tc filter add dev eno2 parent 2: protocol ip prio 1 handle 0x00000004 > fw flowid 2:20 Yes, this is what I meant. > > I tried this previously. But there is not change in the result. > Behaviour is exactly same, i.e. I am still getting 100Mbps and not > 100kbps or 300kbps > > Besides, as I mentioned previously I am using ipset + skbprio and not > filters stuff. Filters I used just to test. > > ipset -N foo hash:ip,mark skbinfo > > ipset -A foo 10.10.10.10, 0x0x00000001 skbprio 1:10 > ipset -A foo 10.10.10.20, 0x0x00000002 skbprio 1:20 > ipset -A foo 10.10.10.30, 0x0x00000003 skbprio 2:10 > ipset -A foo 10.10.10.40, 0x0x00000004 skbprio 2:20 > > iptables -A POSTROUTING -j SET --map-set foo dst,dst --map-prio Hmm.. I am not familiar with ipset, but it seems to save the skbprio into skb->priority, so it doesn't need TC filter to classify it again. I guess your packets might go to the direct queue of HTB, which bypasses the token bucket. Can you dump the stats and check? Thanks.
Powered by blists - more mailing lists