adding rsockets support into JDK

Alan Bateman Alan.Bateman at oracle.com
Fri May 11 12:18:02 UTC 2018


On 04/05/2018 17:42, Lu, Yingqi wrote:
> Hi All,
>
> The version 3 of the patch is available now at http://cr.openjdk.java.net/~ylu/8195160.03/
>
> In this version, I have changed following items:
>
> 1. Added Sockets.openRdmaSelector() function
>
> 2. Replaced "changing system-wide SocketImplFactory" with returning Socket(impl). I did the similar change to ServerSocket too. I also moved RdmaSocketImplFactory from jdk.net to rdma.ch.
>
> 3. Reduced number the factory methods to 2, openRdmaSocket() and openRdmaServerSocket().
>
> 4. Removed the changes to InetAddress.
>
> 5. Removed the methods changed to public in Socket/ServerSocket
>
> Please let me know your feedback and comments.
>
I looked through the current version.

The API additions to jdk.net.Sockets API look good. The javadoc will 
need to be fleshed out of course.

Did you mean to include jdk.net.RdmaSocketImplFactory in the API? The 
factory methods can create the RdmaSocketImpl directly so it may not be 
needed.

jdk.net.RdmaSocketOptions looks right. It will of course need javadoc 
and some refactoring so that hardcoded values aren't in shared code.

There are a few changes to the java.net API that will need 
consideration. Having a protected constructor that takes a SocketImpl 
looks reasonable on first glance it is consistent with the protected 
constructor in Socket.

The addition of protected setters to SocketImpl may be okay too although 
not strictly needed as the fd and address fields are protected so they 
can be set by implementations already.

You've changed ServerSocket accept to support the RdmaSocketImpl but I 
don't think you need that. Instead, the ServerSocket returned by 
openServerSocket can override the accept method. I think this means you 
can drop the qualified export of jdk.net to java.base too.

I'm a bit uncomfortable with extending SocketChannelImpl and 
ServerSocketChannelImpl as proposed because it tightly ties the RMDA 
implementation in jdk.net. It means we can't change anything in say 
SocketChannelImpl without breaking the RDMA implementation. Given that 
the RMDA implementations override almost everything then maybe they 
should just extend SocketChannel directly and we'll need to the 
duplication as needed.

The extending of PollSelectorImpl is probably okay, just needs a comment 
to poll method to explain what it is protected.

libextnet also builds on Solaris so the updates to Lib-jdk.net.gmk will 
need a few adjustments to ensure that it continues to build (you'll need 
to add -lrdmacm to LIBS_linux rather than LIBS for example).

Are you planning to develop tests for this? We also have the issue how 
this is going to be tested and maintained over the long term.

-Alan


More information about the nio-dev mailing list