What are the steps needed to add my own traffic scheduler to TC? My understanding is that I need to do something in the net/sched/ directory: add a schedular eg sch_blue.c, change the Makefile, config.in and sch_api.c; add the appropriate qopt, xstats struct... in the include/linux/pkt_sched.h. I''ve got it all compiled without warnings or error. When I typed "tc add dev eth0 root blue limit 1000kB......", it complained "Unknown qdisc "blue", hence option "limit" is unparsable". When I typed "tc add dev eth0 root red limit 1000kB.....", it worked fine (of course). The code I wrote was a complete copy of the sch_red.c, with text changed to blue instead of red. TC is not happy with my blue scheduler. What have I done wrong? Have I missed something? Linux Kernel version 2.4.20-8 Many Thanks, Kennedy _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
TC is like iptables, you need to add suport to tc binary for your module, else you wont be able to configure it. I dont know how to do this , but try to find some analogy with other modules you will need to modify tc makefile, and add aditional module. ----- Original Message ----- From: "Kennedy Cheng" <kennedy.cheng@jungle.bt.co.uk> To: <lartc@mailman.ds9a.nl> Sent: Wednesday, March 03, 2004 5:17 PM Subject: [LARTC] how to add my own traffic scheduler to TC> What are the steps needed to add my own traffic scheduler to > TC? > > My understanding is that I need to do something in the net/sched/ > directory: add a schedular eg sch_blue.c, change the Makefile, config.in > and sch_api.c; add the appropriate qopt, xstats struct... in the > include/linux/pkt_sched.h. I''ve got it all compiled without warnings or > error. When I typed ''"''tc add dev eth0 root blue limit 1000kB......''"'', it > complained ''"''Unknown qdisc ''"''blue''"'', hence option ''"''limit''"'' is > unparsable''"''. > When I typed ''"''tc add dev eth0 root red limit 1000kB.....''"'', it worked > fine (of course). > > The code I wrote was a complete copy of the sch_red.c, with text changed > to blue instead of red. TC is not happy with my blue scheduler. What > have I done wrong? Have I missed something? > > Linux Kernel version 2.4.20-8 > > Many Thanks, > Kennedy > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Nuutti Kotivuori
2004-Mar-03 22:32 UTC
Blue and SFB (Was: how to add my own traffic scheduler to TC)
Kennedy Cheng wrote:> What are the steps needed to add my own traffic scheduler to TC?From your small example there, I would guess you are working on a Blue scheduler for TC. Hence I''d like to ask publically from everyone around - has anyone seen any efforts to implement Blue[1]? What about SFB, eg. Stochastic Fair Blue? The Blue algorithm seems really straightforward to implement, so I really wonder why it hasn''t been done already? SFB is ofcourse more complex in several ways, but perhaps a lot of code could be reused from SFQ, since the basic idea of hashing flows is the same. Thanks, -- Naked Footnotes: [1] http://www.thefengs.com/wuchang/work/blue/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Patrick McHardy
2004-Mar-04 03:56 UTC
Re: Blue and SFB (Was: how to add my own traffic scheduler to TC)
There is a blue implementation for Linux at http://home.sch.bme.hu/~bartoki/projects/thesis/2001-May-26/ Regards Patrick BTW: Regarding your remaining HFSC questions (I just discovered them on lartc), I''m going to answer them tomorrow. Nuutti Kotivuori wrote:> Kennedy Cheng wrote: > >>What are the steps needed to add my own traffic scheduler to TC? > > >>From your small example there, I would guess you are working on a Blue > scheduler for TC. > > Hence I''d like to ask publically from everyone around - has anyone > seen any efforts to implement Blue[1]? What about SFB, eg. Stochastic > Fair Blue? > > The Blue algorithm seems really straightforward to implement, so I > really wonder why it hasn''t been done already? SFB is ofcourse more > complex in several ways, but perhaps a lot of code could be reused > from SFQ, since the basic idea of hashing flows is the same. > > Thanks, > -- Naked > > Footnotes: > [1] http://www.thefengs.com/wuchang/work/blue/ > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Kennedy Cheng
2004-Mar-04 10:51 UTC
Re: Blue and SFB (Was: how to add my own traffic scheduler to TC)
I was not trying to implement the Blue algorithm. It was just a name I picked as an example. Perhaps I should take a look at Blue as well. Kennedy Nuutti Kotivuori wrote:> Kennedy Cheng wrote: > > What are the steps needed to add my own traffic scheduler to TC? > > >From your small example there, I would guess you are working on a Blue > scheduler for TC. > > Hence I''d like to ask publically from everyone around - has anyone > seen any efforts to implement Blue[1]? What about SFB, eg. Stochastic > Fair Blue? > > The Blue algorithm seems really straightforward to implement, so I > really wonder why it hasn''t been done already? SFB is ofcourse more > complex in several ways, but perhaps a lot of code could be reused > from SFQ, since the basic idea of hashing flows is the same. > > Thanks, > -- Naked > > Footnotes: > [1] http://www.thefengs.com/wuchang/work/blue/ > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Thanks Roy, I found the answers. I didn''t know I had to modify the kernel QoS library (which I did) as well as the iproute2 library (which I didn''t). It is working now :) Thanks, Kennedy Roy wrote:> TC is like iptables, you need to add suport to tc binary for your module, > else you wont be able to configure it. > I dont know how to do this , but try to find some analogy with other modules > you will need to modify tc makefile, and add aditional module. > > ----- Original Message ----- > From: "Kennedy Cheng" <kennedy.cheng@jungle.bt.co.uk> > To: <lartc@mailman.ds9a.nl> > Sent: Wednesday, March 03, 2004 5:17 PM > Subject: [LARTC] how to add my own traffic scheduler to TC > > > What are the steps needed to add my own traffic scheduler to > > TC? > > > > My understanding is that I need to do something in the net/sched/ > > directory: add a schedular eg sch_blue.c, change the Makefile, config.in > > and sch_api.c; add the appropriate qopt, xstats struct... in the > > include/linux/pkt_sched.h. I''ve got it all compiled without warnings or > > error. When I typed ''"''tc add dev eth0 root blue limit 1000kB......''"'', it > > complained ''"''Unknown qdisc ''"''blue''"'', hence option ''"''limit''"'' is > > unparsable''"''. > > When I typed ''"''tc add dev eth0 root red limit 1000kB.....''"'', it worked > > fine (of course). > > > > The code I wrote was a complete copy of the sch_red.c, with text changed > > to blue instead of red. TC is not happy with my blue scheduler. What > > have I done wrong? Have I missed something? > > > > Linux Kernel version 2.4.20-8 > > > > Many Thanks, > > Kennedy > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Patrick McHardy wrote:> There is a blue implementation for Linux at > http://home.sch.bme.hu/~bartoki/projects/thesis/2001-May-26/Nice! I briefly scanned the implementation and it didn''t look too bad. Some oddities here and there (such as changing HZ from 100 to 1024??). But, as the implementation is rather old, it would require a complete overhaul for 2.6 I think. It is a shame it wasn''t worked in to the Linux kernel when it was still current, as I think the algorithm could have a lot of uses. What is the process of getting new traffic schedulers in the kernel? I guess most of the netfilter stuff goes through netfilter development and patch-o-matic - but there isn''t anything similar for QoS, is there?> BTW: Regarding your remaining HFSC questions (I just discovered > them on lartc), I''m going to answer them tomorrow.No rush. I did realize that I posted the reply only to the list through gmane, but didn''t consider it important enough to resend directly. -- Naked _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Nuutti Kotivuori wrote:> Patrick McHardy wrote: > >>There is a blue implementation for Linux at >>http://home.sch.bme.hu/~bartoki/projects/thesis/2001-May-26/ > > > Nice! > > I briefly scanned the implementation and it didn''t look too bad. Some > oddities here and there (such as changing HZ from 100 to 1024??).Yes, it seems to be in a good form. The HZ change doesn''t make much sense for a work-conserving scheduler, the PSCHED_CLOCK_SOURCE change is there to get a higher clock resolution.> But, as the implementation is rather old, it would require a complete > overhaul for 2.6 I think. It is a shame it wasn''t worked in to the > Linux kernel when it was still current, as I think the algorithm could > have a lot of uses.I couldn''t sleep this morning so I started to fix up the code for 2.6 ;) It''s almost no work, the QoS-subsystem hasn''t changed much since 2.4.3. I should be done today or tommorrow.> What is the process of getting new traffic schedulers in the kernel? I > guess most of the netfilter stuff goes through netfilter development > and patch-o-matic - but there isn''t anything similar for QoS, is > there?No, there isn''t. The usual way it to submit new stuff to netdev for discussion, if it is useful and of good quality it usually is accepted. Regards Patrick _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> Nuutti Kotivuori wrote: >> But, as the implementation is rather old, it would require a complete >> overhaul for 2.6 I think. It is a shame it wasn''t worked in to the >> Linux kernel when it was still current, as I think the algorithm could >> have a lot of uses. >I''ve completed the port and tested it yesterday, unfortunately it''s not useable in the real world as is. There is a strong bias against non-ECN flows because their packets are simply dropped instead of marked. At high load (50 ECN vs. 1 non-ECN flow) and a marking probability of about 10% the non-ECN flow simply stalls. I can send you the patch if you''re interested .. Regards Patrick _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Patrick McHardy wrote:> I''ve completed the port and tested it yesterday, unfortunately it''s > not useable in the real world as is. There is a strong bias against > non-ECN flows because their packets are simply dropped instead of > marked. At high load (50 ECN vs. 1 non-ECN flow) and a marking > probability of about 10% the non-ECN flow simply stalls. > I can send you the patch if you''re interested ..Thank you, I am really interested. I will try how it behaves for me in various circumstances. What you say, though, is probably true - and the situation is even more accentuated when considering that different TCP stacks react to ECN and packet drops differently - a single drop percent will not be enough. Which ofcourse brings us to SFB - with Stochastic Fair Blue, the drop percentage for the non-ECN flow should be significantly lower and the connections should transfer more or less fairly. -- Naked _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Nuutti Kotivuori wrote:> Patrick McHardy wrote: > >>I''ve completed the port and tested it yesterday, unfortunately it''s >>not useable in the real world as is. There is a strong bias against >>non-ECN flows because their packets are simply dropped instead of >>marked. At high load (50 ECN vs. 1 non-ECN flow) and a marking >>probability of about 10% the non-ECN flow simply stalls. >>I can send you the patch if you''re interested .. > > > Thank you, I am really interested.Patch is attached. Use the original tc patch.> > I will try how it behaves for me in various circumstances. > > What you say, though, is probably true - and the situation is even > more accentuated when considering that different TCP stacks react to > ECN and packet drops differently - a single drop percent will not be > enough.OTOH, with only ECN flows it works great, not a single packet drop after a couple of minutes, without BLUE there were multiple thousands.> Which ofcourse brings us to SFB - with Stochastic Fair Blue, the drop > percentage for the non-ECN flow should be significantly lower and the > connections should transfer more or less fairly.I''m going to check this out, don''t know anything about it. Regards Patrick> > -- Naked >