Date: Tue, 14 Sep 2010 18:08:34 +0200 From: Fabien Thomas <fabien.thomas@netasq.com> To: Andre Oppermann <oppermann@networx.ch> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing Message-ID: <89E74A8F-4FF9-482B-83D0-3D076F0E41E4@netasq.com> In-Reply-To: <4C8F978F.1030707@networx.ch> References: <4C8E0C1E.2020707@networx.ch> <A9862681-6A4D-43A3-9A26-C71A54CF86F0@netasq.com> <4C8F978F.1030707@networx.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 sept. 2010, at 17:41, Andre Oppermann wrote: > On 14.09.2010 11:18, Fabien Thomas wrote: >> Great, >>=20 >> This will maybe kill the long time debate about "my loopback is slow = vs linux" >> To have the best of both world what about a socket option to = enable/disable fusing: >> can be useful when you need to see some connection "packetized". >=20 > A sysctl to that effect is already in the patch. yes, i'm just wondering on a per connection setting. >=20 > --=20 > Andre >=20 >> Fabien >>=20 >> On 13 sept. 2010, at 13:33, Andre Oppermann wrote: >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Testers and feedback wanted: >>>=20 >>> http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff >>>=20 >>> -- >>> Andre >>>=20 >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 >>=20 >>=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89E74A8F-4FF9-482B-83D0-3D076F0E41E4>