adding rsockets support into JDK

[Lu, Yingqi]

Hi Alan,

Thank you very much for your guidance on the tests. This is very helpful.

I will look into SDP test cases and use them as a reference. 

In addition, I tested rsocket client and server on the same machine for both sockets and socket channels. InetAddress.getLocalHost() is used as the address for both server and client. The tests pass. Using sar[1], I see CPU cores are busy, but network does not show traffic. I think it might due to how rsocket handles local traffic (rsocket does not use loopback device). I also tested the same programs on two different machines and I saw network traffic shown on the RDMA network card.  

Thanks,
Lucy

[1] https://linux.die.net/man/1/sar


>-----Original Message-----
>From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>Sent: Thursday, June 7, 2018 1:15 AM
>To: Lu, Yingqi <yingqi.lu at intel.com>; nio-dev at openjdk.java.net
>Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Aundhe, Shirish
><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com>
>Subject: Re: adding rsockets support into JDK
>
>On 05/06/2018 07:17, Lu, Yingqi wrote:
>> Hi All,
>>
>> Here is the version #4 of the patch
>> http://cr.openjdk.java.net/~ylu/8195160.04/
>>
>> In this version, I have changed:
>>
>> 1. Remove jdk.net.RdmaSocketImplFactory.
>> 2. Remove the inheritance from SocketChannelImpl/ServerSocketChannelImpl,
>replace it with SocketChannel/ServerSocketChannel.
>> 3. Remove unnecessary setters from SocketImpl.
>> 4. Override accept method to the ServerSocket returned by
>jdk.net.openServerSocket.
>> 5. Add a small comment to PollSelectorImpl.poll method 6. Clean up a
>> little in Lib-jdk.net.gmk
>>
>> I am still working on creating all the test cases. Do we need to replicate all the
>tests from both Socket/ServerSocket and SocketChannel/ServerSocketChannel,
>or we only need to pick up a subset of the cases?
>>
>> Please review the patch and let me know your feedback and comments.
>>
>For tests then I think we should have a basic set of tests that exercise each of the
>elements in the API. For each socket and channel type then each of the methods
>in the API should be exercised. There are several new socket options so they
>should be exercised too. So a good start is a maintainable set of unit tests. I don't
>think you should be concerned with duplicating all the existing tests as many of
>those tests are regression tests or stress specific areas where there were bugs in
>the past.
>
>In general, I think testing is going to be a challenge for this feature as it needs
>commitment to maintain the infrastructure needed to test this feature and then
>running the tests at each release. When we added the SDP support, it required
>maintaining a set of machines with Infiniband HCAs and running the tests on a
>regular basis. I assume something similar will be needed here.
>
>When developing the jtreg tests then it's important that don't fail on systems
>without RDMA hardware. For SDP, the tests checked for /proc/net/sdp and would
>pass silently when not present. I hope there is something easy to check for
>rsockets.
>
>One thing that isn't clear to me is whether communication between using sockets
>on the same machine, using an address plumbed to an RDMA interface, will use
>the network or not. I guess I'm asking if you are thinking about functional testing
>with two or more machines, I assume you will at least be doing some of that
>when getting performance data and comparing it to TCP or SDP connections.
>
>On the build changes, then one thing that would be useful to know is whether
>librdmacm is included in all distributions. If someone is building on say Ubuntu will
>they need to install an additional package installed. I bring this as we may need to
>do a bit more on the build to probe for the library. In other areas, at least in the
>past, we've had to resort to dynamic linking (dlopen/dlsym). I'm sure we should
>do that here, instead I'm just wondering whether the rsocket support will be
>compiled in when there it is not present on the build machine.
>
>I skimmed quickly through the webrev and I think it's looking quite good.
>RdmaNet defines only static methods so I don't think it needs to extends Net.
>There is more to do on the javadoc for the new methods, also
>RdmaSocketOptions. I can help out on that when the time comes.
>
>-Alan.
>