From: Rick Jones <rick.jones2@hp.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, therbert@google.com,
ncardwell@google.com, maze@google.com, ycheng@google.com,
ilpo.jarvinen@helsinki.fi
Subject: Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
Date: Mon, 23 Apr 2012 13:57:17 -0700 [thread overview]
Message-ID: <4F95C22D.3010908@hp.com> (raw)
In-Reply-To: <1335213446.5205.65.camel@edumazet-glaptop>
On 04/23/2012 01:37 PM, Eric Dumazet wrote:
> In my 10Gbit tests (standard netperf using 16K buffers), I've seen
> backlogs of 300 ACK packets...
Probably better to call that something other than 16K buffers - the send
size was probably 16K, which reflected SO_SNDBUF at the time the data
socket was created, but clearly SO_SNDBUF grew in that timeframe.
And those values are "standard" for netperf only in the context of
(default) Linux - on other platforms the defaults in the stack and so in
netperf are probably different.
The classic/migrated classic tests report only the initial socket buffer
sizes, not what they become by the end of the test:
raj@tardy:~/netperf2_trunk/src$ ./netperf -H 192.168.1.3
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.3 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 941.06
To see what they are at the end of the test requires more direct use of
the omni path. Either by way of test type:
raj@tardy:~/netperf2_trunk/src$ ./netperf -H 192.168.1.3 -t omni
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.3 ()
port 0 AF_INET
Local Remote Local Elapsed Throughput Throughput
Send Socket Recv Socket Send Time Units
Size Size Size (sec)
Final Final
266640 87380 16384 10.00 940.92 10^6bits/s
or omni output selection:
raj@tardy:~/netperf2_trunk/src$ ./netperf -H 192.168.1.3 -- -k
lss_size_req,lss_size,lss_size_end,rsr_size_req,rsr_size,rsr_size_end
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.3 () port 0 AF_INET
LSS_SIZE_REQ=-1
LSS_SIZE=16384
LSS_SIZE_END=266640
RSR_SIZE_REQ=-1
RSR_SIZE=87380
RSR_SIZE_END=87380
BTW, does it make sense that the SO_SNDBUF size on the netperf side
(lss_size_end - 2.6.38-14-generic kernel) grew larger than the SO_RCVBUF
on the netserver side? (3.2.0-rc4+)
rick jones
PS - here is data flowing the other way:
raj@tardy:~/netperf2_trunk/src$ ./netperf -H 192.168.1.3 -t TCP_MAERTS
-- -k lsr_size_req,lsr_size,lsr_size_end,rss_size_req,rss_size,rss_size_end
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.3 () port 0 AF_INET
LSR_SIZE_REQ=-1
LSR_SIZE=87380
LSR_SIZE_END=4194304
RSS_SIZE_REQ=-1
RSS_SIZE=16384
RSS_SIZE_END=65536
next prev parent reply other threads:[~2012-04-23 20:57 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 9:38 [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP Eric Dumazet
2012-04-23 17:14 ` Rick Jones
2012-04-23 17:23 ` Eric Dumazet
2012-04-23 20:01 ` David Miller
2012-04-23 20:37 ` Eric Dumazet
2012-04-23 20:57 ` Rick Jones [this message]
2012-04-23 21:30 ` Eric Dumazet
2012-04-23 21:51 ` Rick Jones
2012-04-23 21:56 ` Rick Jones
2012-04-23 22:05 ` Eric Dumazet
2012-04-23 22:16 ` Rick Jones
2012-04-24 15:25 ` Christoph Lameter
2012-04-23 21:01 ` David Miller
2012-04-23 21:38 ` Eric Dumazet
2012-04-24 2:20 ` Eric Dumazet
2012-04-24 2:27 ` David Miller
2012-04-24 8:01 ` Ilpo Järvinen
2012-04-24 8:10 ` David Miller
2012-04-24 8:21 ` Ilpo Järvinen
2012-04-24 8:25 ` David Miller
2012-04-24 8:40 ` Ilpo Järvinen
2012-04-24 8:48 ` David Miller
2012-04-24 10:32 ` Ilpo Järvinen
2012-04-24 8:56 ` Eric Dumazet
2012-04-26 8:10 ` [RFC] allow skb->head to point/alias to first skb frag Eric Dumazet
2012-04-26 8:36 ` David Miller
2012-04-26 9:10 ` Eric Dumazet
2012-04-26 9:18 ` David Miller
2012-04-26 9:22 ` Eric Dumazet
2012-04-26 10:09 ` Maciej Żenczykowski
2012-04-26 12:32 ` Eric Dumazet
2012-04-26 13:50 ` Eric Dumazet
2012-04-26 20:12 ` David Miller
2012-04-26 20:18 ` Eric Dumazet
2012-04-24 8:49 ` [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP Eric Dumazet
2012-04-24 8:44 ` David Laight
2012-04-24 8:53 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F95C22D.3010908@hp.com \
--to=rick.jones2@hp.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=maze@google.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
--cc=ycheng@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).