[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1335891450475140@web23o.yandex.ru>
Date: Sat, 19 Dec 2015 00:45:40 +0300
From: Dmitrii Shcherbakov <fw.dmitrii@...dex.com>
To: Phil Sutter <phil@....cc>
Cc: Jesper Dangaard Brouer <brouer@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH][iproute2] tc/q_htb.c: Fix the MPU value output in 'tc -d class show dev <device_name> ' command
Phil,
18.12.2015, 19:55, "Phil Sutter" <phil@....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@...alhost ~]# tc -d class show dev eth0
[root@...alhost ~]# tc qdisc add dev eth0 root handle 1: htb default 12
[root@...alhost ~]# tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps mpu 256 overhead 64
[root@...alhost ~]# 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
--
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