adding rsockets support into JDK

[Lu, Yingqi]

Hi Alan,

I checked on librdmacm availability on different Linux distros. It is at least available in Ubuntu, Arch Linux, Fedora/Centos/Red Hat, openSUSE and Gentoo. 

Thanks,
Lucy

>-----Original Message-----
>From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Lu,
>Yingqi
>Sent: Thursday, June 7, 2018 11:11 AM
>To: Alan Bateman <Alan.Bateman at oracle.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
>
>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.
>>