Re: Kernel BUG: Qos seg. fault

Re: Kernel BUG: Qos seg. fault

[Dmitry Torokhov]

> > Since TBF has only one child no matter what I contend that
> > implementing filters for TBF does not make sense, filters should
> > be attached either to TBF's child ot to TBF's parent but not to
> > TBF itself.
> 
> Ok, understood. Why does TBF have only one child?

It just does... TBF as far as I understand is a simple rate
limiting tool for your network link. I implemented the child
qdisc for TBF so you can change default fifo queue in it to
SFQ or PRIO. It supposed to be very lightweight. If you need
something more complex/fancy then you probably want HTB or CBF.

It's all just my opinion though.

Dmitry

Re: Kernel BUG: Qos seg. fault

[jamal]

On Mon, 2004-05-24 at 17:53, Dmitry Torokhov wrote:


> It just does... 

you mean just "because" ? ;-> Semantics allow you to do more.

> TBF as far as I understand is a simple rate
> limiting tool for your network link. 

Consider it a scheduler really.

> I implemented the child
> qdisc for TBF so you can change default fifo queue in it to
> SFQ or PRIO. It supposed to be very lightweight. If you need
> something more complex/fancy then you probably want HTB or CBF.

Ok, I thought you were trying to hierachical token buckets. Why coulnt
you go the extra step?
In any case, i agree what you have is a lightweight improvement; but you
could go the next mile.
Your original patch should be sufficient in the case you just want to
stay there.

cheers,
jamal

Re: Kernel BUG: Qos seg. fault

[Jaume Catarineu]

Hi all,

After reading all your messages I share the Dmitry's point of view. It 
seems quite clear that implementing filters for TBF does not make sense. 
  However, if it is the case, it could be nice a warning message that 
informs the user about the weird command introduced.

Another option (a little more complicated) would be to "decay" 
automatically the filter to the TBF's child qdisc. That ougth to be 
announced to the user also and maybe it won't be allways possible (with 
the default noop_qdisc is useless, isn't it?).

I will take a tour into the source code :)

Actually, the original sequence must be rewrited to:
  tc qdisc add dev lo root handle 1: tbf rate 250kbit burst 5k limit 5k
  tc qdisc add dev lo parent 1: handle 20:  prio
  tc qdisc add dev lo parent 20:1 handle 210: sfq perturb 10
  tc qdisc add dev lo parent 20:2 handle 220: tbf rate 250kbit limit 5k 

  tc qdisc add dev lo parent 20:3 handle 230: sfq perturb 10

  tc filter add dev lo protocol ip parent 20: prio 1 handle 2 \
                                              fw flowid 20:3

The key is the "parent 20:" (not the original "parent 1:") in the filter 
line.

I must say that I got astonished viewing how quick you solved the quiz. 
Now I don't simply believe in free software, now I really TRUST in it.

Jaume,

Re: Kernel BUG: Qos seg. fault (part II)

[jamal]

On Mon, 2004-05-24 at 23:29, Jaume Catarineu wrote:
> Hi again,
> 
> I've found another problem that seems strongly related to the first one.
> In this case we just need a TBF root qdisc:
> 
>   tc qdisc add dev lo root handle 1: tbf rate 250kbit burst 5k limit 5k
> 
> After adding it, when we ask for the filters...
> 
>   tc filter show dev lo
> 
> Voilà!
> 
>    Segmentation fault
> 
> Does the patch provided by Dmitry arrange this? And the Jamal's patch? 
> Which is better?

Use Dmitry's patch. I believe it would fix the above too.
You should get an EINVAL error unless you specify the correct
child id (such as tc filter show dev lo parent 20: )

cheers,
jamal

Kernel BUG: Qos seg. fault (part II)

[Jaume Catarineu]

Hi again,

I've found another problem that seems strongly related to the first one.
In this case we just need a TBF root qdisc:

  tc qdisc add dev lo root handle 1: tbf rate 250kbit burst 5k limit 5k

After adding it, when we ask for the filters...

  tc filter show dev lo

Voilà!

   Segmentation fault

Does the patch provided by Dmitry arrange this? And the Jamal's patch? 
Which is better?

Thanks,
Jaume,

Re: Kernel BUG: Qos seg. fault

[Dmitry Torokhov]

On Monday 24 May 2004 05:09 pm, jamal wrote:
> On Mon, 2004-05-24 at 17:53, Dmitry Torokhov wrote:
> 
> 
> > It just does... 
> 
> you mean just "because" ? ;-> Semantics allow you to do more.
> 
> > TBF as far as I understand is a simple rate
> > limiting tool for your network link. 
> 
> Consider it a scheduler really.
> 
> > I implemented the child
> > qdisc for TBF so you can change default fifo queue in it to
> > SFQ or PRIO. It supposed to be very lightweight. If you need
> > something more complex/fancy then you probably want HTB or CBF.
> 
> Ok, I thought you were trying to hierachical token buckets. Why coulnt
> you go the extra step?
> In any case, i agree what you have is a lightweight improvement; but you
> could go the next mile.
> Your original patch should be sufficient in the case you just want to
> stay there.
> 

Yes, I think we should stay right here. If we go that next mile we will
get HTB and we already have a decent implementation ;)

-- 
Dmitry

Re: Kernel BUG: Qos seg. fault (part II)

[Jaume Catarineu]

> Use Dmitry's patch. I believe it would fix the above too.
> You should get an EINVAL error unless you specify the correct
> child id (such as tc filter show dev lo parent 20: )

The patch works with kernel 2.6.4 (also for 2.4.25), and solves the two 
segmentations faults. :)

Jaume,