Thanks for your comments. The Javadoc was updated to fix comments and have '@apiNote' section based on previous description. Tests PrintSupportedOptions and AfterClose updated to have minimal changes. Updated webrev available as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.04
The main issue with testing for the NAPI_ID that it always zero for the loopback. The test ExtOptionNAPITest.java now check only ServerSocket/Socket/DatagramSocket but for regular runs all values for NapiId are zero. To have non-zero values I need manual run of the ExtOptionNAPITest on the 2-server configuration with RHEL8 (kernel for the RHEL7.7 does not support this functionality). I can add test cases for channels but I failed to find correct testing scenario for it. Seems, it have no big value to have a lot of test cases that return zero. Thanks, Vladimir -----Original Message----- From: Alan Bateman <alan.bate...@oracle.com> Sent: Thursday, April 30, 2020 12:37 AM To: Ivanov, Vladimir A <vladimir.a.iva...@intel.com>; OpenJDK Network Dev list <net-dev@openjdk.java.net> Subject: Re: RFR 15 8243099: Adding ADQ support to JDK On 29/04/2020 19:11, Ivanov, Vladimir A wrote: > Updated version of the webrev available as > http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/ > > The tests run results for the " test/jdk/java/net test/jdk/java/nio/channels > test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net" same as for non-patched > version. > > Changes: > 1. comment was updated > 2. names were adjusted with convention (IncomingNapiIdOptSupported => > incomingNapiIdOptSupported, IncomingNapiIdSupported => > IncomingNapiIdSupported); > Thanks for the update. For the javadoc, I wonder if it might be simpler to drop "Incoming Napi Id" so that the first line is "Identifies the receive queue ...". That avoids needing to use "Napi" in the javadoc as it would need to be defined. Your previous mail had some good text that could be massaged into an @apiNote to give the reader some idea how this socket option might be used. I'm in two minds on that because it is very Linux specific. Does SO_INCOMING_NAPI_ID return a non-0 value for connections through the loopback? Just checking as that will influence the tests that can be created. SO_INCOMING_NAPI_ID is supported by all socket types so I think we will need tests to properly exercise it on the network channels defined in java.nio.channels. AfterClose test. The legacy Socket APIs validate parameters after they have checked the socket state so I assume most of the changes to this test aren't really needed. That is, I assume SocketException is thrown always. SocketChannel and friends are different in that they validate the parameters/input before checking the channel state. PrintSupportedOptions. That can be simplified to use Set.of("SO_INCOMING_NAPI_ID"). -Alan.
