Most applications, for example web servers, kafka, Netty etc, have one master thread and multiple worker threads to service incoming connections. Master thread accept these connections and dispatch to one of the worker threads using some load balancing policies like round/robin,. With this new socket option all connections received on a single device queue will be dispatched to same worker thread in the application. Master thread accept the incoming connection and make a call to this socket option for child socket and assign the child socket to the thread associated with the queue. That way application worker threads can poll for more packets from the queue when it is ready to service the packets from network and the traffic on other queue/threads can be processed independently. Socket option is called on child socket giving the queue ID associated the new connection, not with this central dispatcher socket.
Thanks, Vladimir From: net-dev <net-dev-boun...@openjdk.java.net> On Behalf Of Bernd Eckenfels Sent: Wednesday, April 29, 2020 9:19 AM To: OpenJDK Network Dev list <net-dev@openjdk.java.net> Subject: Re: RFR 15 8243099: Adding ADQ support to JDK Hello, If you query the queue Id from a central dispatcher thread is there any benefit in knowing that ID as the context change already happens. So without being able to bind a thread for accepting to such a queue (which might not be so easy with emulated async NIO) this api feature seems to not be particular useful for a java app? (And with a bound thread you probably don't need to id either as you just go on and process it)? -- http://bernd.eckenfels.net ________________________________ Von: net-dev <net-dev-boun...@openjdk.java.net<mailto:net-dev-boun...@openjdk.java.net>> im Auftrag von Alan Bateman <alan.bate...@oracle.com<mailto:alan.bate...@oracle.com>> Gesendet: Wednesday, April 29, 2020 5:53:52 PM An: Ivanov, Vladimir A <vladimir.a.iva...@intel.com<mailto:vladimir.a.iva...@intel.com>>; OpenJDK Network Dev list <net-dev@openjdk.java.net<mailto:net-dev@openjdk.java.net>> Betreff: Re: RFR 15 8243099: Adding ADQ support to JDK 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.
