adding rsockets support into JDK

[Lu, Yingqi]

Hi Alan,

Thank you very much for your quick feedback. They are very helpful!

Now, I am thinking on

1. Remove RdmaSocket/RdmaServerSocket and use Socket/ServerSocket for both regular socket and RDMA Socket. With jdk.net.Sockets.openRdmaSocket call(s), I create an instance of RdmaSocketImpl and use that for all the socket operations (bind, listen, connect and etc.). Is it OK if I change Socket(SocketImpl impl) from protected to public so that I can call it from jdk.net? I will also move RdmaSocketImpl away from public API.

2. Similarly, for RdmaSocketChannel/RdmaServerSocketChannel, I will start with creating jdk.net.Sockets.openRdmaSocketChannel/jdk.net.Sockets.openRdmaServerSocketChannel. Later, if we feel it is better to separate them out to new jdk.nio package under jdk.net module, we can definitely do that too.

With above 1 and 2, I think the code duplications will be significantly reduced. However, please let me know if you think keeping non-public RdmaSocket/RdmaServerSocket is better than merging with regular Socket/ServerSocket.

3. The code base I use is http://hg.openjdk.java.net/jdk10/master/. Please let me know which repo I should rebase the patch to. I would rather do it sooner than later. This will make it easier for everyone to review the code :-)

4. Regarding to channel selector, I would love to get some help from you. Really appreciate!

Thanks,
Lucy 

>-----Original Message-----
>From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>Sent: Sunday, April 15, 2018 9:28 AM
>To: Lu, Yingqi <yingqi.lu at intel.com>; nio-dev at openjdk.java.net
>Subject: Re: adding rsockets support into JDK
>
>On 12/04/2018 20:44, Lu, Yingqi wrote:
>> Dear all,
>>
>> I have created a new version of the patch which is available at
>http://cr.openjdk.java.net/~ylu/8195160.01/. There are also two class diagrams
>available at http://cr.openjdk.java.net/~ylu/8195160-class-diagram.pdf which
>describe the high level interactions between RDMA Sockets and regular Sockets.
>>
>> In this version, I have added RDMA support to Socket, ServerSocket,
>SocketChannel and ServerSocketChannel. All the newly introduced classes are
>added into jdk.net module. Before I continue with the effort, I would like to get
>some feedback to see if this is a reasonable approach to enable the feature.
>>
>Good to see this moved to the jdk.net module. One initial concern is the API
>surface:
>
>jdk.net.RdmaSocket
>jdk.net.RdmaServerSocket
>jdk.net.RdmaSocketImpl
>jdk.net.RdmaSocketOptions
>jdk.net.RdmaSocketChannel
>jdk.net.RdmaServerSocketChannel
>jdk.net.RdmaNet ???
>
>RdmaSocketOptions aside, I don't think these classes need to be in the API.
>Instead I think it would be simpler to add factory to jdk.net.Sockes so you can do
>this:
>
>Socket s = jdk.net.Sockets.openRdmaSocket(); ServerSocket ss =
>jdk.net.Sockets.openRdmaServerSocket();
>
>These methods will be specified to throw UOE when not supported on the
>platform.
>
>jdk.net.RdmaSocketOptions looks right although some of the constants are
>probably not meant to be exposed in the API.
>
>The NIO channels will be similar, and just needs deciding if they should be created
>by factory methods on jdk.net.Sockets or whether to introduce a new factory
>class in the jdk.nio package.
>
>One thing that I can't immediately understand from the webrev is how to obtain a
>Selector that can be used with an RDMA selectable channel. In previous mails you
>mentioned that RDMA socket can only be multiplexed with rpoll. No issue
>introducing a epoll based Selector but it's not clear how to obtain this in the API
>as the method to create this Selector is in the non-exported rdma.ch package. If
>it helps, I'm happy to sketch out how this could work with a factory method to
>obtain a capable Selector.
>
>I see the current patch is based on JDK 10 and some of the code that you have
>cloned has changed significantly in the jdk/jdk repo. You will need to re-base at
>some point.
>
>Not important yet but I see you've changed the no-arg InetAdress constructor to
>be public. We can't do that so at some point we will need to explain how accept
>can work outside of the java.net package.
>
>That's all I have now, I'm happy to do a more detail pass when you are ready.
>
>-Alan