Hi Vladimir,
Latest changes looks good to me, but i am not 100% sure if we need to
distinguish between "read only socket option" and "socket option not
supported" as below
if (!incomingNapiIdOptSupported)+ throw new
UnsupportedOperationException("Attempt to set unsupported option " +
option);+ else+ throw new
SocketException("Attempt to set read only option " + option);
If developer wants to know the supported socket options he can use
"supportedOptions" to get the list of supported socket options.
Thanks,
Vyom
On Tue, May 12, 2020 at 5:35 AM Ivanov, Vladimir A <
vladimir.a.iva...@intel.com> 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
> > */
>
--
Thanks,
Vyom
