2.6.0-test4, 2.5.47, child qdiscs, parent not filled out?

2.6.0-test4, 2.5.47, child qdiscs, parent not filled out?

[bert hubert]

Devik (I hope we can be friends again :-)), others,

I'm currently working on the wondershaper 2.0 which is going to be much more
a massmarket product (still GPL, no worries), and I'm wondering why the
parent field of child qdiscs isn't filled out?

If I create a cbq with several classes, and attach a qdisc to those classes,
a later netlink dump (RTM_GETQDISCS) returns parent as 0:0 for that qdisc,
is this right?

Same holds for HTB and child qdiscs. Basically, I can't find a way to figure
out where qdiscs are actually attached. Or should I look for that in xstats?

Thanks.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Re: 2.6.0-test4, 2.5.47, child qdiscs, parent not filled out?

[devik]

> Devik (I hope we can be friends again :-)), others,

yep I think so :-)

> If I create a cbq with several classes, and attach a qdisc to those classes,
> a later netlink dump (RTM_GETQDISCS) returns parent as 0:0 for that qdisc,
> is this right?

structure Qdisc has DEPRECATED field __parent pointing to parent
qdisc (aparently CBQ needs it).
There is no other "parent" info in the struct so it can't be returned
IMHO.
You will have to parse all clases from root to leaves.

Maybe we could add parent handle to qdisc but it is question to
Alexey probably - I'm not sure how complex would it be to keep
the field in sync ...

devik

Re: 2.6.0-test4, 2.5.47, child qdiscs, parent not filled out?

[bert hubert]

On Wed, Sep 03, 2003 at 11:01:45PM +0200, devik wrote:

> There is no other "parent" info in the struct so it can't be returned
> IMHO. You will have to parse all clases from root to leaves.

That probably means having to understand the innards of all qdiscs? Could
that be done from userspace? Is it in the TCA_OPTIONS attribute?

> Maybe we could add parent handle to qdisc but it is question to
> Alexey probably - I'm not sure how complex would it be to keep
> the field in sync ...

True. 

You can look at why I need this on
CVSROOT=:pserver:anon@outpost.ds9a.nl:/var/cvsroot
password 'cvs' without quotes, module 'netlink++'.

Thanks!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Re: 2.6.0-test4, 2.5.47, child qdiscs, parent not filled out?

[jamal]

olla,

Actually HTB does seem to be missing something; havent looked at the
code - just looking at a black box perspective. Try a very simple test:

Add a root CBQ qdisc and watch the netlink messages produced.
Observe CBQ creating both a root qdisc and class where the children
will be attached.

Repeat same test for HTB - it doesnt create the top class.
I believe it is needed. Sorry too tied up elsewhere to help right now.

cheers,
jamal

On Wed, 2003-09-03 at 17:01, devik wrote:
> > Devik (I hope we can be friends again :-)), others,
> 
> yep I think so :-)
> 
> > If I create a cbq with several classes, and attach a qdisc to those classes,
> > a later netlink dump (RTM_GETQDISCS) returns parent as 0:0 for that qdisc,
> > is this right?
> 
> structure Qdisc has DEPRECATED field __parent pointing to parent
> qdisc (aparently CBQ needs it).
> There is no other "parent" info in the struct so it can't be returned
> IMHO.
> You will have to parse all clases from root to leaves.
> 
> Maybe we could add parent handle to qdisc but it is question to
> Alexey probably - I'm not sure how complex would it be to keep
> the field in sync ...
> 
> devik
> 
> 
>