RFR 15 8243099: SO_INCOMING_NAPI_ID support

Viswanathan, Sandhya sandhya.viswanathan at intel.com
Wed May 20 17:01:11 UTC 2020


The CSR is approved now.  JDK submit tests all passed. I will plan to push this on behalf of Vladimir Ivanov and Dinesh Kumar later today.
Thank you very much for all the guidance through this patch.

Best Regards,
Sandhya


-----Original Message-----
From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Viswanathan, Sandhya
Sent: Friday, May 15, 2020 10:07 AM
To: Alan Bateman <Alan.Bateman at oracle.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: RE: RFR 15 8243099: SO_INCOMING_NAPI_ID support

 
The CSR has been reviewed by Joe Darcy and is now marked as Provisional with the following comment:

  https://bugs.openjdk.java.net/browse/JDK-8244858

----
Re: SO_INCOMING_NAPI_ID support 
Moving to Provisional.
Please have one or more networking engineers review the request before finalizing it for the second round of CSR review.
----

Best Regards,
Sandhya

-----Original Message-----
From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Viswanathan, Sandhya
Sent: Tuesday, May 12, 2020 3:14 PM
To: Alan Bateman <Alan.Bateman at oracle.com>; Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: RE: RFR 15 8243099: SO_INCOMING_NAPI_ID support


I have created the following draft CSR:
  https://bugs.openjdk.java.net/browse/JDK-8244858

Please review and let me know if I can move it to proposed.

Best Regards,
Sandhya

-----Original Message-----
From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Alan Bateman
Sent: Friday, May 08, 2020 12:10 AM
To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

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
      */


More information about the net-dev mailing list