RFR 15 8243099: SO_INCOMING_NAPI_ID support

[Alan Bateman]

On 07/05/2020 19:51, Ivanov, Vladimir A wrote:
> In my case for 2 servers with RHEL8.1 the NapiId was non-zero for the DatagramSocket after the 'receive' call.
>
Thanks for checking. I tried the equivalent of RHEL7.6 and it 
consistently returns 0 for UDP sockets so they may be kernel differences 
that explain this.

I took the liberty of tweaking the javadoc to allow for a bit more 
flexibility as to reasons why the socket option value may be 0. This 
allows us to drop the distinction between connecting and listing 
sockets. If you are okay with this text then let's give it a day or two 
to see if there are other comments before Sandhya submits the CSR.

-Alan


     /**
      * Identifies the receive queue that the last incoming packet for 
the socket
      * was received on.
      *
      * <p> The value of this socket option is a positive {@code 
Integer} that
      * identifies a receive queue that the application can use to split the
      * incoming flows among threads based on the queue identifier. The 
value is
      * {@code 0} when the socket is not bound, a packet has not been 
received,
      * or more generally, when there is no receive queue to identify. 
The socket
      * option is supported by both stream-oriented and datagram-oriented
      * sockets.
      *
      * <p> The socket option is read-only and an attempt to set the 
socket option
      * will throw {@code SocketException}.
      *
      * @apiNote
      * Network devices may have multiple queues or channels to transmit 
and receive
      * network packets. The {@code SO_INCOMING_NAPI_ID} socket option 
provides a hint
      * to the application to indicate the receive queue on which an 
incoming socket
      * connection or packets for that connection are directed to. An 
application may
      * take advantage of this by handling all socket connections 
assigned to a
      * specific queue on one thread.
      *
      * @since 15
      */