I checked that the filters cannot classify the traffic -
all the traffics are enqueued to the default class,
so they cannot allocate their bandwidth.
I followed the cbq kernel source code line by line and here is a cbq_classify:
(see my comments between the lines)
// net/sched/sch_cbq.c (kernel version 2.4.19)
static struct cbq_class *
cbq_classify(struct sk_buff *skb, struct Qdisc *sch)
{
struct cbq_sched_data *q = (struct cbq_sched_data*)sch->data;
struct cbq_class *head = &q->link;
struct cbq_class **defmap;
struct cbq_class *cl = NULL;
u32 prio = skb->priority;
struct tcf_result res;
/*
* Step 1. If skb->priority points to one of our classes, use it.
*/
if (TC_H_MAJ(prio^sch->handle) == 0 &&
(cl = cbq_class_lookup(q, prio)) != NULL)
return cl;
for (;;) {
int result = 0;
defmap = head->defaults;
/*
* Step 2+n. Apply classifier.
*/
<<my comment>> in 'tc_classify' function, if the traffic has an appropriate
<<my comment>> filter, class is selected for the traffic.
<<my comment>> Normally, appropriate classes are selected on the Pentium CPU,
<<my comment>> but not on the MPC8250 (PowerPC based CPU) for the same traffic
<<my comment>> and the same tc configuration, so 'goto fallback'
<<my comment>> I used u32 filter for packet classification : Is u32_classify
<<my comment>> function eventually called?
if (!head->filter_list
|| (result = tc_classify(skb, head->filter_list, &res)) < 0)
goto fallback;
if ((cl = (void*)res.class) == NULL) {
if (TC_H_MAJ(res.classid))
cl = cbq_class_lookup(q, res.classid);
else if ((cl = defmap[res.classid&TC_PRIO_MAX]) == NULL)
cl = defmap[TC_PRIO_BESTEFFORT];
if (cl == NULL || cl->level >= head->level)
goto fallback;
}
#ifdef CONFIG_NET_CLS_POLICE
switch (result) {
case TC_POLICE_RECLASSIFY:
return cbq_reclassify(skb, cl);
case TC_POLICE_SHOT:
return NULL;
default:
break;
}
#endif
<<my comment>> if the traffic founds its filters,
<<my comment>> class is returned at this point (on the Pentium CPU).
if (cl->level == 0)
return cl;
/*
* Step 3+n. If classifier selected a link sharing class,
* apply agency specific classifier.
* Repeat this procdure until we hit a leaf node.
*/
head = cl;
}
fallback:
cl = head;
/*
* Step 4. No success...
*/
if (TC_H_MAJ(prio) == 0 &&
!(cl = head->defaults[prio&TC_PRIO_MAX]) &&
!(cl = head->defaults[TC_PRIO_BESTEFFORT]))
return head;
return cl;
}
but one thing strange is when I check the filter list with the command
'tc filter show dev eth0' nothing wrong in the filter lists.
Any Idea or recommendation for more investigation?
On Wed, Apr 23, 2003 at 08:58:12AM +0200, Andreani Luca wrote:
> I have thr same problem with a similar ppc based processor (the MPC8245).
> I tried to resolve the problem for three months without any result.
> I noticed that the problem should be in the filters and that the behaviour
> is different if the traffic is local (to the router box) or to be forwarded.
> Any idea?
>
> -----Messaggio originale-----
> Da: soyoung@xxxxxxxxxxxxxxx [mailto:soyoung@xxxxxxxxxxxxxxx]
> Inviato: mercoledì 23 aprile 2003 8.05
> A: Stef Coene
> Cc: lartc@xxxxxxxxxxxxxxx
> Oggetto: Re: [LARTC] [Q]About Using TC in MPC8250
>
>
> MPC8250 is a CPU name produced by Motorola.
> It is a kind of Motorola PowerPC processor. Linux can run on the MPC8250.
>
> Every kernel functions regarding to TC CBQ looks working -
> I followed the CBQ kernel code step by step and found no problems.
> But the bandwidth I allocated is not guaranteed.
>
> I think it is related to CPU characteristics,
> but I don't have any specific knowledge about it.
>
> I don't think the script is wrong, 'cause I used that script for other
> linux (running on normal i386 machine) and it works good.
>
> Anyway here is a script.
>
> --
>
> /sbin/tc qdisc del dev eth1 root handle 1:
>
> /sbin/tc qdisc add dev eth1 root handle 1: cbq bandwidth 102400Kbit avpkt
> 1500 cell 8
>
> /sbin/tc class add dev eth1 parent 1: classid 1:2 cbq bandwidth 102400Kbit
> rate 102Kbit allot 1514 cell 8 weight 10Kbit prio 3 maxburst 16 avpkt 1500
> bounded
> /sbin/tc filter add dev eth1 parent 1: protocol ip prio 3 u32 match ip src
> 10.0.10.72 match ip dst 10.0.0.47 flowid 1:2
>
>
>
>
> On Tue, Apr 22, 2003 at 01:26:18PM +0200, Stef Coene wrote:
> > On Tuesday 22 April 2003 13:18, soyoung@xxxxxxxxxxxxxxx wrote:
> > > Hi,
> > >
> > > I'm running Linux 2.4.17 on MPC8250 CPU for bandwidth management with TC
> > > CBQ. All the functions in CBQ looks working - including TC,
> > > but the class can't use its allocated bandwidth,
> > > so I can't use bandwidth management with TC on MPC8250.
> > Can you be more specific? What's your script? How did you test it?
> >
> > > No external error founds when running TC.
> > > I think the correctness for calculating bandwidth in each class is the
> > > problem.
> > >
> > > Is there anyone who has run CBQ in TC on MPC8250? or do you have some
> good
> > > idea to solve this problem?
> > What's "MPC8250" ??
> >
> > Stef
> >
> > --
> >
> > stef.coene@xxxxxxxxx
> > "Using Linux as bandwidth manager"
> > http://www.docum.org/
> > #lartc @ irc.oftc.net
> _______________________________________________
> LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
