All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wilfried Weissmann <Wilfried.Weissmann@gmx.at>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] [HTB] htb_dequeue_tree assertion (kernel 2.4.21-ac4)
Date: Sat, 19 Jul 2003 11:42:57 +0000	[thread overview]
Message-ID: <marc-lartc-105861509407539@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105855808906499@msgid-missing>

devik wrote:
> If you read comment above htb_dequeue_tree, it should be called
> only when it is sure that there are packets inside of the level/prio.
> It is known by other HTB mechanism (per-level activity lists).
> 
> Thus the bugtrap is to catch case where class was inserted
> into activity list because it had packets in its sub-qdisc
> but when we actually decide to dequeue - it has no packet.
> It is weird - can qdisc lose packets even when dequeue was
> not called ??

If you change the depth of the leave queue then it is possible to drop 
packets or if you completely exchange the queue. Which would also 
explain why the assertion only occurs when the configuration is altered.

Greetings,
Wilfried

> 
> -------------------------------
>     Martin Devera aka devik
> Linux kernel QoS/HTB maintainer
>   http://luxik.cdi.cz/~devik/
> 
> On Fri, 18 Jul 2003, Wilfried Weissmann wrote:
> 
> 
>>Hello,
>>
>>I think the BUG_TRAP() in the htb_dequeue_tree() is wrong. First it
>>checks if the class pointer "cl" is NULL, which is obviously right. But
>>I do not understand why we also check whenever the queue length of the
>>leaf queue is zero "cl->un.leaf.q->q.qlen". I would have put that in the
>>expression of the "if" statements that comes afterwards. A queue length
>>of 0 is not an error condition that should be reported (please, correct
>>me if I misunderstood the code).
>>I can pretty much reliably trigger the assertion with a well utilized
>>gigabit ethernet link when I flush and reactivate the TC configuration
>>every 3 seconds. It looks like the error occurs only when confiuration
>>changes are made.
>>I will some some more tests on monday when I am back at the office to
>>verify that the queue length is (not) the problem.
>>
>>bye,
>>wilfried
>>
>>static struct sk_buff *
>>htb_dequeue_tree(struct htb_sched *q,int prio,int level)
>>{
>>	struct sk_buff *skb = NULL;
>>	//struct htb_sched *q = (struct htb_sched *)sch->data;
>>	struct htb_class *cl,*start;
>>	/* look initial class up in the row */
>>	start = cl = htb_lookup_leaf (q->row[level]+prio,prio,q->ptr[level]+prio);
>>
>>	do {
>>		BUG_TRAP(cl && cl->un.leaf.q->q.qlen); if (!cl) return NULL;
>>		HTB_DBG(4,1,"htb_deq_tr prio=%d lev=%d cl=%X defic=%d\n",
>>				prio,level,cl->classid,cl->un.leaf.deficit[level]);
>>
>>		if (likely((skb = cl->un.leaf.q->dequeue(cl->un.leaf.q)) != NULL))
>>			break;
>>		if (!cl->warned) {


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2003-07-19 11:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-18 19:53 [LARTC] [HTB] htb_dequeue_tree assertion (kernel 2.4.21-ac4) Wilfried Weissmann
2003-07-19  9:25 ` devik
2003-07-19 11:42 ` Wilfried Weissmann [this message]
2003-07-20  7:28 ` devik
2003-07-20 20:59 ` Wilfried Weissmann
2003-07-21  8:49 ` Wilfried.Weissmann
2003-07-21  9:10 ` devik
2003-07-23  7:39 ` devik
2003-07-23 18:35 ` Wilfried Weissmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-105861509407539@msgid-missing \
    --to=wilfried.weissmann@gmx.at \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.