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