From: Eric Dumazet <eric.dumazet@gmail.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: jeffrey.t.kirsher@intel.com, "Skidmore,
Donald C" <donald.c.skidmore@intel.com>,
Greg Rose <gregory.v.rose@intel.com>,
John Fastabend <john.r.fastabend@intel.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
netdev <netdev@vger.kernel.org>
Subject: TSO not 10G friendly if peer is close enough
Date: Tue, 17 Apr 2012 23:38:42 +0200 [thread overview]
Message-ID: <1334698722.2472.71.camel@edumazet-glaptop> (raw)
In-Reply-To: <1334681204.2472.41.camel@edumazet-glaptop>
After further analysis, I found we hit badly page refcounts games,
because when we transmit full size skb (64 KB), we can receive ACK for
the first MSS of the frame while skb was not completely sent by NIC.
(Needs 52 us to send a full TSO frame at 10Gb, and maybe NIC delays
interrupt to trigger TX completion ?)
In this case, tcp_trim_head() has to call pskb_expand_head(), because
skb clone is still alive in TX ring buffer.
pskb_expand_head() is really expensive, it has to make about 32 atomic
operations on page refcounts.
Hmm... maybe tcp_trim_head should not trim but only update an offset in
skb... With some luck, offset can reach skb->len when all data is
ACKnowledged...
Only in case of retransmit we would need to really trim the skb, and by
this time, clone would had been freed to : No more pskb_expand_head()
calls.
next prev parent reply other threads:[~2012-04-17 21:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 9:06 [BUG] ixgbe: something wrong with queue selection ? Eric Dumazet
2012-04-17 9:16 ` Jeff Kirsher
2012-04-17 16:01 ` Alexander Duyck
2012-04-17 16:38 ` John Fastabend
2012-04-17 17:07 ` Ben Hutchings
2012-04-17 16:46 ` Eric Dumazet
2012-04-17 21:38 ` Eric Dumazet [this message]
2012-04-17 21:47 ` TSO not 10G friendly if peer is close enough David Miller
2012-04-18 3:00 ` Eric Dumazet
2012-04-18 15:49 ` [PATCH net-next] tcp: avoid expensive pskb_expand_head() calls Eric Dumazet
[not found] ` <4F8EF317.10504@hp.com>
2012-04-18 17:16 ` Eric Dumazet
2012-04-18 17:30 ` Rick Jones
2012-04-18 17:40 ` Eric Dumazet
2012-04-18 18:40 ` Neal Cardwell
2012-04-18 19:18 ` Eric Dumazet
2012-04-18 19:51 ` [PATCH v2 " Eric Dumazet
2012-04-19 11:10 ` Ilpo Järvinen
2012-04-19 11:30 ` Eric Dumazet
2012-04-19 11:40 ` Eric Dumazet
2012-04-19 11:57 ` Ilpo Järvinen
2012-04-19 12:44 ` Eric Dumazet
2012-04-20 12:27 ` Ilpo Järvinen
2012-04-19 13:18 ` Eric Dumazet
2012-04-19 13:52 ` Eric Dumazet
2012-04-19 14:10 ` Eric Dumazet
2012-04-19 17:20 ` Rick Jones
2012-04-19 17:25 ` Eric Dumazet
2012-04-19 17:48 ` Rick Jones
2012-04-19 18:00 ` Eric Dumazet
2012-04-19 18:05 ` Rick Jones
2012-04-18 19:41 ` [PATCH " Vijay Subramanian
2012-04-18 19:49 ` 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=1334698722.2472.71.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=donald.c.skidmore@intel.com \
--cc=gregory.v.rose@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
/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