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