Hi Alan, Yes, I will sponsor this. Thanks a lot for your feedback on Vladimir's patch.
Best Regards, Sandhya -----Original Message----- From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> On Behalf Of Alan Bateman Sent: Saturday, April 18, 2020 8:40 AM To: Ivanov, Vladimir A <vladimir.a.iva...@intel.com>; net-dev@openjdk.java.net Cc: core-libs-...@openjdk.java.net Subject: Re: RFR 15 8243099: Adding ADQ support to JDK On 18/04/2020 00:13, Ivanov, Vladimir A wrote: > Hello everyone, > I would like to add support for the Application Device Queue (ADQ) technology > to the JDK. > > The JBS entry and webrev were created for this improvement: > JBS: https://bugs.openjdk.java.net/browse/JDK-8243099 > Webrev: > http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.00/ > > Please let us know your feedback and comments for this enhancement. > Just to put more context on this. Vladimir brought this to nio-dev in March with some background and initial proposed it as a standard socket option [1]. A socket option that allows an application to split incoming flows based on their receive queue is very Linux specific so we suggested it should be in the JDK-specific ExtendedSocketOptions API with the other non-standard socket options. net-dev is the right mailing list to progress this and get a sponsor (maybe Sandhya Viswanathan will do it?). We can probably drop core-libs-dev from the this one. Just a few comments on the current webrev: The API docs in the webrev is a good start but will need to be fleshed out as it uses several terms such as "device queue", "last frame", "Rx queue" without any definition. One important point that we will need to be covered is that it's a read-only socket option so the docs will need to specify the exception that will be thrown when trying to set it. From a quick look at the implementation then it appears to fall through to InternalError so that might need to be fixed. It will also be important to document the socket types and where in their lifecycle (listening, connected) that the socket option can be used. Will SO_INCOMING_NAPI_ID be defined in a header file? It probably needs #ifndef to avoid the hardcoded value when building on distributions that define it. A passing comment is that native methods static methods so "unused" is a jclass. Tests. Read-only socket options might trip up on existing tests in the jdk_net or jdk_nio test groups that enumerate all socket options and exercise get and set on each one. The proposed test will probably go several iterations to get to something that is maintainable. It will also need to be extended to exercise SocketChannel, ServerSocketChannel and more. -Alan [1] https://mail.openjdk.java.net/pipermail/nio-dev/2020-March/007109.html
