netdev - Re: HTB accuracy on 10GbE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Nov 2009 18:03:07 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Ryousei Takano <ryousei@...il.com>
CC:	Stephen Hemminger <shemminger@...tta.com>,
	Patrick McHardy <kaber@...sh.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	takano-ryousei@...t.go.jp
Subject: Re: HTB accuracy on 10GbE

Ryousei Takano a écrit :
> Hi Eric,
> 
> Thanks for your suggestion.
> 
> On Wed, Nov 4, 2009 at 8:31 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>> Ryousei Takano a écrit :
>>
>>> I tried iperf with 60 seconds samples. I got the almost same result.
>>>
>>> Here is the result:
>>>       sender  receiver
>>> 1.000 1.00    1.00
>>> 2.000 2.01    2.01
>>> 3.000 3.03    3.02
>>> 4.000 4.07    4.07
>>> 5.000 5.05    5.05
>>> 6.000 6.16    6.16
>>> 7.000 7.22    7.22
>>> 8.000 8.15    8.15
>>> 9.000 9.23    9.23
>>> 9.900 9.69    9.69
>>>
>> One thing to consider is the estimation error in qdisc_l2t(), rate table has only 256 slots
>>
>> static inline u32 qdisc_l2t(struct qdisc_rate_table* rtab, unsigned int pktlen)
>> {
>>        int slot = pktlen + rtab->rate.cell_align + rtab->rate.overhead;
>>        if (slot < 0)
>>                slot = 0;
>>        slot >>= rtab->rate.cell_log;
>>        if (slot > 255)
>>                return (rtab->data[255]*(slot >> 8) + rtab->data[slot & 0xFF]);
>>        return rtab->data[slot];
>> }
>>
>>
>> Maybe you can try changing class mtu to 40000 instead of 9000, and quantum to 60000 too
>>
>> tc class add dev $DEV parent 1: classid 1:1 htb rate ${rate}mbit mtu 40000 quantum 60000
>>
>> (because your tcp stack sends large buffers ( ~ 60000 bytes) as your NIC can offload tcp segmentation)
>>
>>
> You are right!
> I am using TSO. The myri10ge driver is passing 64KB packets to the NIC.
> I changed the class mtu parameter to 64000 instead of 9000.
> 
> Here is the result:
> 1.000 1.00
> 2.000 2.01
> 3.000 2.99
> 4.000 4.01
> 5.000 5.01
> 6.000 6.04
> 7.000 7.06
> 8.000 8.09
> 9.000 9.11
> 9.900 9.64
> 
> It's not so bad!
> For more information, I updated the results on my page.
> 


In fact, I gave you 40000 because rtab will contain 256 elements from 0 to 65280

If you use 64000, you lose some precision (for small packets for example)


--
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