On Sat, 19 Dec 2015 00:45:40 +0300
Dmitrii Shcherbakov <fw.dmit...@yandex.com> wrote:
> Phil,
>
> 18.12.2015, 19:55, "Phil Sutter" <p...@nwl.cc>:
> > On Fri, Dec 18, 2015 at 07:39:25PM +0300, Dmitrii Shcherbakov wrote:
> >> > Dmitrii, did iproute2 without your change even print the overhead as set
> >> > by you before? Looking at the code, I'd assume not.
> >>
> >> Tried building iproute2 (as of tag 4.2) and using the upstream linux
> >> kernel (also tag 4.2 - 64291f7db5bd8150a74ad2036f1037e6a0428df2):
> >
> > This is without your patch, right?
>
> Yes (ec4ef6aebd5a52ab1acf1f5be1749320b3188659).
>
> >
> >> ~/src/iproute2/tc$ sudo ./tc class add dev eth0 parent 1: classid 1:1 htb
> >> rate 100kbps ceil 100kbps mpu 256 overhead 64
> >
> > Setting an mpu of 256 is suitable to get 0 as output value, as the code
> > before your patch ANDs it with 0xff.
>
> True, but then I think I would get the 'old' (encoded) overhead output of
> '1b' then and the first 8 bits which are treated as mpu would be 0 anyway.
> And its 0 for both mpu and overhead ("mpu 0b overhead 0b") which is strange.
> I am going to have to take a look at the kernel state with gdb.
>
> What I would expect instead (notice 'overhead 1b'):
>
> [root@localhost ~]# tc -d class show dev eth0
> [root@localhost ~]# tc qdisc add dev eth0 root handle 1: htb default 12
> [root@localhost ~]# tc class add dev eth0 parent 1: classid 1:1 htb rate
> 100kbps ceil 100kbps mpu 256 overhead 64
> [root@localhost ~]# tc -d class show dev eth0
> class htb 1:1 root prio 0 quantum 10000 rate 800000bit overhead 64 ceil
> 800000bit burst 1600b/1 mpu 0b overhead 1b cburst 1600b/1 mpu 0b overhead 1b
> level 0
>
> >
> >> So it looks like the overhead is being set correctly, but the mpu is not,
> >> even though the respective kernel module is loaded judging by what I see.
> >
> > To really know what is being set, you would have to look at the kernel
> > variables not what iproute prints. This is nitpicking mostly, but
> > relevant in this case as your patches to fix iproute's output show.
> >
> > Cheers, Phil
>
> I am going to try and take a look at it. I have not delved into the kernel's
> network subsystem so it may take some time.
>
> Thanks,
> Dima
I am going to hold off on this, if it hasn't been urgent for years, there is no
requirement to do it right away. If you come to a conclusion let me know.
It might be possible to troll back through Internet to get more data on this...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
