On 07/05/2020 03:39, Ivanov, Vladimir A wrote:
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.
I did a bit of testing on a system that supports SO_INCOMING_NAPI_ID a
few days ago. It correctly returned the ID for a connected streams
socket once data had been received but the value was always 0 for a
datagram socket. I checked, even when bound to a specific address. Are
you seeing a non-0 value in your environment? If there a variance (maybe
kernel or configuration) then we might have to tweak the javadoc to set
expectations.
-Alan
