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]
Message-ID: <b30d1c3b0911040831y7aeac556raf7cae9106b5bc7b@mail.gmail.com>
Date:	Thu, 5 Nov 2009 01:31:11 +0900
From:	Ryousei Takano <ryousei@...il.com>
To:	Eric Dumazet <eric.dumazet@...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

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.

Best regards,
Ryousei
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ