The socket option SO_INCOMING_NAPI_ID returns the integer value that is associated with the hardware queue of the device the last packet is received on. This is true for UDP Datagram sockets as well. In case the socket is receiving the packets from multiple NIC Devices or the incoming packets of the socket are getting directed to different Hardware queues on same device, this return value will change as the queue for last packet will change.
Please note that the proposed change provides a method for application to query the queue id on which the last packet is received on. Not all applications need to use this option or need to change their existing behavior. It is expected that the applications that take advantage of this new option are getting the connections aligned to the particular HW queues. For example, for UDP application, a socket can be bound to an IP/Port and NIC can be configured to direct all packets for that IP/Port to a queue. In this case the value will remain constant and application can utilize this option. If UDP application is listening on all devices in the system, then it does not have to use this option and continue to function as it does today. Thanks, Vladimir -----Original Message----- From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Wednesday, May 6, 2020 2:37 AM To: Ivanov, Vladimir A <vladimir.a.iva...@intel.com>; Alan Bateman <alan.bate...@oracle.com>; OpenJDK Network Dev list <net-dev@openjdk.java.net> Subject: Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support Hi Vladimir, On 06/05/2020 00:36, Ivanov, Vladimir A wrote: > I was failed to get non-zero value for the ServerSocket and according to > clarification from the network experts: > " NAPI IDs is not marked on listening sockets. A listening socket can accept > multiple connections coming on different queues. So even if we do it, it can > keep changing and we don't see a use case for it. Once a connection is > accepted, accepted or the child socket will return a valid NAPI id." > > So seems the listener sockets will have this as zero. Thanks for this clarifications! Could you also clarify how this is supposed to work with UDP sockets? I mean - does the socket needs to be connected to make the best use of this feature? If not connected, will a listening UDP socket always be assigned to the same device queue regardless of the source of the datagrams it receives or might the device queue id change with each incoming packet depending on its source? I am especially intrigued by the case where a DatagramSocket is bound to the wildcard address and as such potentially able to receive datagrams comming through any active NIC. best regards, -- daniel
