I think the main difference between the two CPU is the "endianess".
The U32 classifier apply in a bit based way, so it could be miss the right
bit on a PPC platform.
The TC_H_MAJ macro, for instance, applies a mask that is not correct for
big endian arch.
Am I wrong?
-----Messaggio originale-----
Da: soyoung@taonetworks.com [mailto:soyoung@taonetworks.com]
Inviato: lunedi 28 aprile 2003 2.53
A: Andreani Luca
Cc: Stef Coene; lartc@mailman.ds9a.nl
Oggetto: Re: R: [LARTC] [Q]About Using TC in MPC8250
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@taonetworks.com [mailto:soyoung@taonetworks.com]
> Inviato: mercoled? 23 aprile 2003 8.05
> A: Stef Coene
> Cc: lartc@mailman.ds9a.nl
> 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@taonetworks.com 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@docum.org
> > "Using Linux as bandwidth manager"
> > http://www.docum.org/
> > #lartc @ irc.oftc.net
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/