Thanks a lot. The updated webrev available as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.13/
Thanks, Vladimir -----Original Message----- From: Patrick Concannon <patrick.concan...@oracle.com> Sent: Wednesday, May 13, 2020 4:16 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 Great, thanks Valdimir Also, it might be worthwhile adding a check to ensure the NAPI ID remains consistent across multiple send/receives read/writes, and to test similar socket types e.g. AsynchronousSocketChannel For example: http://cr.openjdk.java.net/~pconcannon/8243099/webrevs/webrev.01/ Kind regards, Patrick On 12/05/2020 01:05, Ivanov, Vladimir A wrote: > Thanks a lot Patrick. Your tests looks better then proposed ones. > Updated webrev available as > http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.12 > > Thanks, Vladimir > > -----Original Message----- > From: Patrick Concannon <patrick.concan...@oracle.com> > Sent: Monday, May 11, 2020 11:11 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 Vladamir, > > Just a few observations with your test, ExtOptionNAPITest: I don't think the > static class TestThread is needed for what you're trying to check and I think > you can remove it. Also, I think using testNG assertions rather than throwing > RunTimeExceptions might be better here, for example: > > - if (ssId != 0) > - throw new RuntimeException("ServerSocket: incorrect > value for SO_INCOMING_NAPI_ID: " + ssId); > + assertEquals(ssID, 0, "Socket: Server"); > > Finally, it might be a nice idea to split the test in two: one for > DatagramSocket/DatagramChannel and the other for Sockets? -- for > example, > http://cr.openjdk.java.net/~pconcannon/8243099/webrevs/webrev.00/ > > > Kind regards, > > Patrick > > On 08/05/2020 20:02, Ivanov, Vladimir A wrote: >> Thanks a lot. Updated webrev uploaded as >> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.10/ >> If no other comments the CSR will be crated on the next week. >> >> Thanks, Vladimir >> >> -----Original Message----- >> From: Alan Bateman <alan.bate...@oracle.com> >> Sent: Friday, May 8, 2020 12:10 AM >> To: Ivanov, Vladimir A <vladimir.a.iva...@intel.com>; OpenJDK Network >> Dev list <net-dev@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 >> */
