Hi Dave, multiple qdiscs fail to adjust sch->q.qlen after grafting when the old qdisc is non-empty. This permanently damages the counter. TBF additionally needs to adjust stats.backlog. Best regards,
Did you test some of this stuff or just did a mass-edit? I havent paid attention to all the details, but what would decrementing sch->q.qlen on grafting mean on a dsmark? cheers, jamal
Hi Jamal, I've tested tbf and prio changes before and after. Unfortunately I've never used dsmark so I didn't test this part. I did try to make sure my changes make sense, and I still don't see why t
It doesnt make sense to have more than one queue in Dsmark (used as a place holder/work queue while DSCP remarking). If reset() is already setting the length to 0 then it is not useful to set it to
Hi Jamal, the patch was meant to fix the problem that when replacing (or deleting) a leaf queue that still holds packets the packets are not subtracted from the upper queue's q.qlen. dsmark_reset doe
What happens if you add another type of qdisc example RED (after you have deleted pfifo? Not that it makes a lot of sense to add anything than a simple FIFO or even makes sense to add a leaf qdisc t
What happens if you add another type of qdisc example RED (after you have deleted pfifo? Not that it makes a lot of sense to add anything than a simple FIFO or even makes sense to add a leaf qdisc to
Stated in such a general way, that sounds dangerous ;-) tcio, section 2, towards the end: Now, I've of course only documented the status quo, and one could argue whether this actually makes sense. Bu
behaviour I'd expect your patch to fix, no ? Correct, it was done without the patch and the patch is supposed to fix it. I'm going to send a new version which just sets q.qlen to 0 later. Best regard
Now that we have invoked Werner - lets wait for his response then ;-> Sorry, didnt meant to drag this into 5-6 emails thread. I closely looked at your other changes on that patch and they looked fine
Hi Dave, multiple qdiscs fail to adjust sch->q.qlen after grafting when the old qdisc is non-empty. This permanently damages the counter. TBF additionally needs to adjust stats.backlog. Best regards,
Did you test some of this stuff or just did a mass-edit? I havent paid attention to all the details, but what would decrementing sch->q.qlen on grafting mean on a dsmark? cheers, jamal
Hi Jamal, I've tested tbf and prio changes before and after. Unfortunately I've never used dsmark so I didn't test this part. I did try to make sure my changes make sense, and I still don't see why t
Patrick, It doesnt make sense to have more than one queue in Dsmark (used as a place holder/work queue while DSCP remarking). If reset() is already setting the length to 0 then it is not useful to se
Hi Jamal, the patch was meant to fix the problem that when replacing (or deleting) a leaf queue that still holds packets the packets are not subtracted from the upper queue's q.qlen. dsmark_reset doe
Patrick, What happens if you add another type of qdisc example RED (after you have deleted pfifo? Not that it makes a lot of sense to add anything than a simple FIFO or even makes sense to add a leaf
Patrick, What happens if you add another type of qdisc example RED (after you have deleted pfifo? Not that it makes a lot of sense to add anything than a simple FIFO or even makes sense to add a lea
Author: Werner Almesberger <werner@xxxxxxxxxxxxxxx>
Date: Mon, 17 Nov 2003 16:38:34 -0300
Stated in such a general way, that sounds dangerous ;-) tcio, section 2, towards the end: Now, I've of course only documented the status quo, and one could argue whether this actually makes sense. Bu
Patrick, was the experiment "I've now verified experimentally the problem also exists in dsmark" done with or without your behaviour I'd expect your patch to fix, no ? Correct, it was done without t
Now that we have invoked Werner - lets wait for his response then ;-> Sorry, didnt meant to drag this into 5-6 emails thread. I closely looked at your other changes on that patch and they looked fine