RFR 15 8243099: SO_INCOMING_NAPI_ID support

[Vyom Tiwari]

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.ivanov at 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.concannon at oracle.com>
> Sent: Monday, May 11, 2020 11:11 AM
> To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; 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
>
> 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.Bateman at oracle.com>
> > Sent: Friday, May 8, 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
> >        */
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200512/df79bc11/attachment-0001.htm>