I will try it out and then get back to you. Thanks for all the help :) On Thu, Oct 2, 2014 at 9:12 PM, Remy Mudingay <remy.mudingay@xxxxxxxxx> wrote: > Hi Akshat, > > What I mean is that the handle 1: can have upto 65k classes and so can 2: and 3: and so on. > Therefore you can do the following > > 1: root handle (htb/hsfc, etc classful qdisc) > 1:2 class (parent class is 1:) > 2:1 leaf sfq/fq/codel qdisc (parent handle is 1:2) > .... > Don't just take my word on this, I strongly encourage to try it out. > > Remy > >> On 02 Oct 2014, at 16:49, Akshat Kakkar <akshat.1984@xxxxxxxxx> wrote: >> >> Thanks for the sysctl option. That might help. >> >> Regarding 64K limit, as shown in the example you have given, the leaf >> handle can only be from 1: to fffe: i.e. 64K. total class limit can be >> 64K * 64K i.e 4G but for the lead SFQ ( as SFQ handle can't have minor >> number) so for an interface, it can at max be fffe i.e. 64K. Is my >> understanding correct on this? or do you want to say that for class >> handle 1:1 I can define 64K SFQs and then for class handle 1:2 I can >> again have 64K SFQs??? >> >>> On Tue, Sep 30, 2014 at 7:04 PM, Remy Mudingay <remy.mudingay@xxxxxxxxx> wrote: >>> Hi Akshat, >>> >>> The 65K (65535) limit is only for a specific handle and not the >>> maximum number of classes that one can create on a system. You can >>> create/attach more classes but you need to give them a new (leaf) >>> handle for your sfq qdiscs. >>> >>> Here's an example (using htb) ; >>> >>> tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit >>> >>> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100kbit ceil 1mbit >>> >>> .... >>> >>> tc class add dev eth0 parent 1:1 classid 1:ffe htb rate 100kbit ceil 1mbit >>> >>> >>> >>> tc qdisc add dev eth0 parent 1:1 handle 1: sfq >>> >>> tc qdisc add dev eth0 parent 1:ffe handle ffff: sfq >>> >>> >>> To answer your question about setting a default qdisc. This is >>> possible from a specific kernel version (I can't recall which version) >>> but I know that 3.11 and onwards support setting it either via sysctl >>> ; >>> >>> net.core.default_qdisc = sfq >>> >>> or by issuing ; >>> >>> echo "sfq" > /proc/sys/net/core/default_qdisc >>> >>> >>> The changes are effective (when using sysctl.conf) after a reboot or >>> when adding after adding a qdisc and then deleting it from an >>> interface. >>> >>> I hope that helps. >>> >>> >>> Remy >>> >>> >>> >>> >>>> On 30 September 2014 14:16, Akshat Kakkar <akshat.1984@xxxxxxxxx> wrote: >>>> >>>> If I want to define classes more than 64k (i.e. ffff), I need to use >>>> class hierarchy or nested classes. >>>> But, if I want to give each one of them SFQ then I can't do that, as >>>> then I will have to define separate qdisc for each one of them and >>>> each SFQ will require to be given a handle starting from 1: and >>>> ending at fffe: i.e. only 64K and not more then that. For classes not >>>> having SFQ (as the number is exhausted), the qdisc remains as SFQ. >>>> >>>> So in a way, each leaf class gets a queue for sure but not SFQ. >>>> >>>> Is there a way, to make SFQ as the default qdisc so that we don't have >>>> to specify it separately and hence will never run short of them? >>>> >>>> I apologise if I have confused the things. >>>> >>>> Thanks in anticipation. >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe lartc" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> -- >>> To unsubscribe from this list: send the line "unsubscribe lartc" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
