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.
