From owner-freebsd-net@FreeBSD.ORG Mon Sep 13 12:00:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50A2310656C4 for ; Mon, 13 Sep 2010 12:00:32 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B82348FC26 for ; Mon, 13 Sep 2010 12:00:31 +0000 (UTC) Received: (qmail 49519 invoked from network); 13 Sep 2010 11:29:01 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Sep 2010 11:29:01 -0000 Message-ID: <4C8E0C1E.2020707@networx.ch> Date: Mon, 13 Sep 2010 13:33:50 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: TCP loopback socket fusing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 12:00:32 -0000 When a TCP connection via loopback back to localhost is made the whole send, segmentation and receive path (with larger packets though) is still executed. This has some considerable overhead. To short-circuit the send and receive sockets on localhost TCP connections I've made a proof-of-concept patch that directly places the data in the other side's socket buffer without doing any packetization and other protocol overhead (like UNIX domain sockets). The connections setup (SYN, SYN-ACK, ACK) and shutdown are still handled by normal TCP segments via loopback so that firewalling stills works. The actual payload data during the session won't be seen and the sequence numbers don't move other than for SYN and FIN. The sequence are remain valid though. Obviously tcpdump won't see any data transfers either if the connection has fused sockets. Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable operation and a rough doubling of the throughput on loopback connections. I've tested most socket teardown cases and it behaves fine. I'm not entirely sure I've got all possible path's but the way it is integrated should properly defuse the sockets in all situations. Testers and feedback wanted: http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff -- Andre