RFR 15 8243099: Adding ADQ support to JDK

[Alan Bateman]

On 28/04/2020 01:33, Ivanov, Vladimir A wrote:
> 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.
> *

What would you think about starting with something like"

"Identifies the receive queue that the last incoming packet for the 
socket was received on.

The value of this socket option is an Integer that identifies a receive 
queue that can application can use to split the incoming flows among 
threads based on the receive queue.

The socket option is read-only and any attempt to set the socket option 
will throw UnsupportedOperationException.
The socket option is supported by both stream and datagram oriented 
sockets. The value of the socket option is 0 when the socket is not 
bound or a packet has not been received."

We could add an additional note to explain further how it might work on 
Linux that would use some of the text that you have in your mail.

-Alan.