The changes for ADq doc update that includes explanation for this technology: /** * ADQ (Application Device Queues) is an open technology to help address network traffic challenges by improving application * throughput and latency, and, most importantly, by enabling greater predictability in application response times by creating * application specific traffic queuing and steering. * * Modern Network Interface Card (NIC) devices have multiple queues or channels to transmit and receive Network packets. ADQ * lets each software application reserve subset of these device queues, so that all the traffic, and only the traffic, belonging to the * application is directed to those set of queues avoiding sharing or competing for network resources with other applications in the * system. * * System Administrator allocates Network resources to an application in a multi-application environment including set of device * queues (Number of Tx/RX queue pairs), dedicated for application traffic. In addition, QoS attributes can be applied to these * Application Queues such as Network bandwidth limits & Traffic priority. Device then assigns the incoming application connections * to these set of queues by defined policies such as round robin. ADQ provides hints to applications, by means of a new socket option * SO_INCOMING_NAPI_ID, to indicate the device queue from the set of assigned queues, to which an incoming socket connection and * packets for that connection are directed to. * * For a multi-threaded application to take advantage of these dedicated queues, application needs ability to query which queue a * connection is assigned to, so all socket connections from a specific device queue can be serviced by a single application thread. * Application then may utilize busy polling to receive and transmit the network packets, minimizing system interrupts and context * switches to better align overall system resources to applications. This helps in improved predictability, reduce latency and improve * throughput for ADQ enabled Application. * * The value of this SO_INCOMING_NAPI_ID socket option is an Integer, uniquely representing the network device queue on which the * last packet of the socket connection is received on. This option is available for both stream-oriented and datagram-oriented sockets * on both client and server sockets. The value returned for this socket option will be zero until the socket is connected and has received * a network packet, at which point it will be a non-zero integer value. This is a read only option. Attempting to set the socket option will * cause UOE to be thrown. */
Thanks, Vladimir -----Original Message----- From: Alan Bateman <alan.bate...@oracle.com> Sent: Friday, April 24, 2020 12:09 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 23/04/2020 20:11, Ivanov, Vladimir A wrote: > Thanks a lot to Chris and Alan for detailed comments. > The updated version of patch available at > http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.01/ > > Changes: > 1. in native code the common pattern was used for the 'getsockopt' call. > 2. condition to define SO_INCOMING_NAPI_ID was added. > 3. the DatagarmSocket was added to the ExtOptionTest 4. testing on my > side was extended to the subset 'test/jdk/java/net test/jdk/java/nio/channels > test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net'. > Results are same for the patched and non-patched builds on the RHEL7.7 OS. > Tests test/jdk/java/net/SocketOption/AfterClose.java and > test/jdk/java/nio/channels/etc/PrintSupportedOptions.java were updated to > support read only properties. > 5. description for the NAPI_ID was updated 6. the > UnsupportedOperationException was added to the 'setOption' call for the > 'SO_INCOMING_NAPI_ID'. > (Dropping core-libs-dev as net-dev is the more appropriate list for this area). Thanks for the update. The updated javadoc looks better but will need a few iterations. It would be good if it could start by explaining what the value of the socket option is, e.g. "The value of this socket option is an Integer representing the network device queue ...". I think it needs to be clearer on the types of sockets that support this option, does it support both stream-oriented and datagram-oriented sockets? Does it return a value when invoked on a ServerSocketChannel? Instead of @throws, the text will need to that attempting to set the socket option will cause UOE to be thrown. Once the javadoc is agreed then the CSR can be submitted and the code review can continue in parallel. The implementation changes mostly look okay although IncomingNapiIdSupported0 should probably be renamed to start with lower case "i". Also someone might need to check that you can create an IPv4 socket when a system is configured as an IPv6-only system. Tests. I think the the new tests in ExtOptionTest will need closer examination as I can't tell how reliable they are. It might be that it needs a completely new test. The update to the NIO PrintSupportedOptions test define READ_ONLY_OPTS as Set<String>. -Alan
