LARTC - Mar 2004 - 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/

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/

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/

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/

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
>