Problem setting shift value in tcindex filter on big endian
Subsystems (2)
Hi all,
I'm trying to get some DiffServ QoS shaping to work on an XScale machine, running big endian. I'm setting it up with tc. Using the tcindex filter I found that regardless what shift value I enter, only '0' is returned when I list the filters afterwards. The very same rules work fine on my (little endian) PC.
Looking at the code (iproute2-2.6.18-061002) I found that tc (in tc/f_tcindex.c, line 72 and after) sends the shift value to the kernel as an int. The kernel, however, expects it as a 'u16' (net/sched/cls_tcindex.c, around line 250 depending on the exact kernel version). I checked 2.6 kernel versions back until 2.6.11.
So... do we have a type mismatch here? As 'shift' is the last parameter in the buffer, this works still very well on a little endian machine, however on a big endian machine allways 0 is received in the kernel. To check that I changed the type of the shift value to unsigned short in tc, and that fixed it for me.
Someone interested in a patch?
Regards
Ole
_______________________________________________
LARTC mailing list
[email protected]
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem setting shift value in tcindex filter on big endian machine
Please send bugreports to [email protected].
Quoted 10 lines · Ole Reinartz
I'm trying to get some DiffServ QoS shaping to work on an XScale machine, running big endian. I'm setting it up with tc. Using the tcindex filter I found that regardless what shift value I enter, only '0' is returned when I list the filters afterwards. The very same rules work fine on my (little endian) PC.
Looking at the code (iproute2-2.6.18-061002) I found that tc (intc/f_tcindex.c, line 72 and after) sends the shift value to the kernel as an int. The kernel, however, expects it as a 'u16' (net/sched/cls_tcindex.c, around line 250 depending on the exact kernel version). I checked 2.6 kernel versions back until 2.6.11.
It appears this was broken during some ->change operation fixes in 2.6.11.
Quoted 6 lines
So... do we have a type mismatch here? As 'shift' is the last parameter in the buffer, this works still very well on a little endian machine, however on a big endian machine allways 0 is received in the kernel. To check that I changed the type of the shift value to unsigned short in tc, and that fixed it for me.
Someone interested in a patch?
Yes, but its the kernel that needs to be fixed to expect a u32.
_______________________________________________
LARTC mailing list
[email protected]
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc