Taking advantage of TCP Loopback fast path in Windows

[Kirk Shoop (MS OPEN TECH)]

SIO_LOOPBACK_FAST_PATH does not affect the addresses, local or remote. It just selects a shorter code path for transporting messages through the network stack.

My understanding is that it will only affect users of the loopback interface. So with this code change any existing java code would need to have used the loopback interface in both client and server and then would have to be run, both the client and the server, with the java setting to enable SIO_LOOPBACK_FAST_PATH.

Kirk

Software Design Engineer
Microsoft Open Technologies, Inc.

MS Open Tech is hiring (http://aka.ms/msopentechjobs)!
Ask me for details if anyone you know is interested.

From: Michael McMahon [mailto:michael.x.mcmahon at oracle.com]
Sent: Wednesday, September 24, 2014 2:55 AM
To: Alan Bateman; Martin Sawicki (MS OPEN TECH); net-dev at openjdk.java.net
Cc: Valery Kopylov (Akvelon); nio-dev; Kirk Shoop (MS OPEN TECH)
Subject: Re: Taking advantage of TCP Loopback fast path in Windows

On 24/09/14 10:43, Michael McMahon wrote:
On 24/09/14 08:50, Alan Bateman wrote:
On 24/09/2014 02:19, Martin Sawicki (MS OPEN TECH) wrote:
Hello
We're proposing an improvement to the OpenJDK which enables users to take advantage of the TCP loopback fast path mechanism in Windows for significantly higher performance of sockets whose both end points are on the same machine.  This is especially relevant in distributed server-side/cloud scenarios, such as Hadoop.

We have the code figured out and tested internally. I've uploaded our webrev package here (too big to send as an attachment):

https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20140918.zip

The crux of the change lies in enabling the SIO_LOOPBACK_FAST_PATH IOCTL flag on each socket creation call in Windows.

As for activating this optimization, we're proposing the conservative approach of keeping it off by default and adding a command line argument to activate it:
-Dwindows.enableFastLocalTcpLoopback=true | false

(IMHO though, it'd be great to eventually just have it on by default).

We'd appreciate a review and acceptance of this improvement.

And, as we are new in the OpenJDK community and this may as well be our first contribution to Java, I apologize for any steps in the submission process that I may have missed here and would appreciate guidance as needed.

Welcome, it's good to see Microsoft engineers on OpenJDK lists.

Yes, this looks like a useful contribution.


If I understand this ioctl correctly then it should only need to be set once on a SOCKET. I'm curious about the listener oriented channels (ServerSocketChannel etc.) where it is being set prior to each call to accept. Is this needed? If not then I assume that we can just set it when creating the SOCKET, sun.nio.ch.Net.socket0 of SocketChannel, ServerSocketChannel, etc. You'll see that it already goes some Windows specific setup and that might be the place to put it (and I think should eliminate the need for most of the changes to the NIO code).

Right. The technet article suggests that it only needs to be set on the listening socket (ie prior to calling accept()). So, the same
comment applies to the DualStackPlainSocketImpl change (could be moved to socketListen() from socketAccept()).
The DualStack/TwoStacks code is being reorganised at the moment. So, I think the patch will need to be rebased
against that work. But, the idea seems pretty reasonable to me.

- Michael

As a matter of interest. Is this effectively an enhancement for code that is already using the loopback
interface, or does it apply to all socket connections where both peers are on same system (and where the
option has been set by both peers)?

If the latter, does it alter the local or remote addresses reported by the socket, since the connection
is now effectively using the loopback interface, or does it pretend to be still using the original interfaces?

- Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140924/0c5106fc/attachment.html>