From mboxrd@z Thu Jan 1 00:00:00 1970
From: =?ISO-8859-1?Q?P=E1draig_Brady?=
Subject: Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
Date: Thu, 23 Aug 2012 11:57:05 +0100
Message-ID: <50360C81.6000009@draigBrady.com>
References: <1344559958-29162-1-git-send-email-brutus@google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: "David S. Miller" ,
Eric Dumazet , netdev@vger.kernel.org
To: "Bruce \"Brutus\" Curtis"
Return-path:
Received: from mx1.redhat.com ([209.132.183.28]:14915 "EHLO mx1.redhat.com"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1030301Ab2HWK5L (ORCPT );
Thu, 23 Aug 2012 06:57:11 -0400
In-Reply-To: <1344559958-29162-1-git-send-email-brutus@google.com>
Sender: netdev-owner@vger.kernel.org
List-ID:
On 08/10/2012 01:52 AM, Bruce "Brutus" Curtis wrote:
> From: "Bruce \"Brutus\" Curtis"
>=20
> TCP/IP loopback socket pair stack bypass, based on an idea by, and
> rough upstream patch from, David Miller called
> "friends", the data structure modifcations and connection scheme are
> reused with extensive data-path changes.
>=20
> A new sysctl, net.ipv4.tcp_friends, is added:
> 0: disable friends and use the stock data path.
> 1: enable friends and bypass the stack data path, the default.
>=20
> Note, when friends is enabled any loopback interpose, e.g. tcpdump,
> will only see the TCP/IP packets during connection establishment and
> finish, all data bypasses the stack and instead is delivered to the
> destination socket directly.
>=20
> Testing done on a 4 socket 2.2GHz "Quad-Core AMD Opteron(tm) Processo=
r
> 8354 CPU" based system, netperf results for a single connection show
> increased TCP_STREAM throughput, increased TCP_RR and TCP_CRR transac=
tion
> rate for most message sizes vs baseline and comparable to AF_UNIX.
>=20
> Significant increase (up to 4.88x) in aggregate throughput for multip=
le
> netperf runs (STREAM 32KB I/O x N) is seen.
Nice!
Just to quantify the loopback testing compat issue.
I often do stuff like the following to test latency.
Will that be impacted?
tc qdisc add dev lo root handle 1:0 netem delay 20msec
As for the stated tcpdump change,
I don't suppose it would be possible to dynamically
disable this (for new connections at least)
while lo is being dumped?
cheers,
P=E1draig.