[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080918.024655.22661052.davem@davemloft.net>
Date: Thu, 18 Sep 2008 02:46:55 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: alexander.h.duyck@...el.com
Cc: netdev@...r.kernel.org, jarkao2@...il.com,
herbert@...dor.apana.org.au, kaber@...sh.net
Subject: Re: [RFC PATCH] sched: only dequeue if packet can be queued to
hardware queue.
From: Alexander Duyck <alexander.h.duyck@...el.com>
Date: Wed, 17 Sep 2008 23:43:02 -0700
> diff --git a/net/sched/sch_atm.c b/net/sched/sch_atm.c
> index 43d3725..91a40b2 100644
> --- a/net/sched/sch_atm.c
> +++ b/net/sched/sch_atm.c
> @@ -516,12 +516,31 @@ static struct sk_buff *atm_tc_dequeue(struct Qdisc *sch)
>
> pr_debug("atm_tc_dequeue(sch %p,[qdisc %p])\n", sch, p);
> tasklet_schedule(&p->task);
> - skb = p->link.q->dequeue(p->link.q);
> + skb = p->link.q->ops->dequeue(p->link.q);
> if (skb)
> sch->q.qlen--;
> return skb;
> }
>
So what is the difference between qdisc->dequeue and qdisc->ops->dequeue?
The same applies to ->enqueue.
qdisc->{dequeue,enqueue} are given the value of ops->{dequeue,enqueue}
at the time of qdisc creation. I can only see two reasons for their
existence:
1) We used to allow overriding ->enqueue and ->dequeue by certain
modules. I see no such use like this in the current tree.
2) For performance it's kept as a copy in the qdisc.
Either way, changing ->ops->dequeue into ->dequeue doesn't seem to be
correct, unless you have some explanation.
This is done in a few other places in your patch.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists