[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACVXFVPksMd8CGZWEGBXBXB5NZCg3QOZreOLavkV-Z2pjE-M_A@mail.gmail.com>
Date: Thu, 5 Jul 2012 22:01:13 +0800
From: Ming Lei <tom.leiming@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Network Development <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>
Subject: Re: TCP transmit performance regression
On Thu, Jul 5, 2012 at 6:41 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Thu, 2012-07-05 at 18:32 +0800, Ming Lei wrote:
>
>> After testing on beagle-xm, the patch is good and network is OK, but
>> iperf performance is still no improvement, see below:
>>
>> [root@...t]#iperf -c 192.168.0.103 -w 131072 -t 10
>> ------------------------------------------------------------
>> Client connecting to 192.168.0.103, TCP port 5001
>> TCP window size: 256 KByte (WARNING: requested 128 KByte)
>> ------------------------------------------------------------
>> [ 3] local 192.168.0.119 port 46776 connected with 192.168.0.103 port 5001
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0-10.0 sec 41.4 MBytes 34.7 Mbits/sec
>>
>
> I fear there are copies in the tx path as well, in smsc95xx_tx_fixup()
Basically, copy path will be bypassed since hard_header_len
has included the 'overhead' already.
> (SLAB debug is going to cost a lot with big bufers)
At default SMSC95xx turbo mode is true, rx buffer will be very big
(17.5K). Or the large rx buffer size puts limit on concurrent URBs/SKBs
count. Both two may cause the problem.
Thanks,
--
Ming Lei
--
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