RFR 15 8243099: SO_INCOMING_NAPI_ID support

[Ivanov, Vladimir A]

Thanks for your comments and questions.

> In terms of retrieval, is `0` a valid value for this option? if so then uninitialized versus initialized states are indistinguishable.
> Maybe not be a problem, I dunno yet without further investigation.
The zero possible for sockets that not received messages yet i.e. not initialized. The queue id on HW level should be greater than zero.

> Also, when a non-0 value is read, is it guaranteed to remain constant thereafter, or does an application need to periodically
> check the socket option value.
During socket connection lifetime it should be constant.

Thanks, Vladimir

-----Original Message-----
From: Chris Hegarty <chris.hegarty at oracle.com> 
Sent: Friday, May 1, 2020 6:19 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 30 Apr 2020, at 22:20, Ivanov, Vladimir A <vladimir.a.ivanov at intel.com> wrote:
> 
> One more update at 
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.05/
> The @apiNote section was updated a little bit to concentrate on SO_INCOMING_NAPI_ID.

I have not seen much discussion relating to possible approaches to this new (first-time in the JDK?) read-only socket option.

The current semantic, that an option returned from `supportedOptions` will not result in an UnsupportedOperationException when passed to `getOption` or `setOption`, is quite nice - this current proposal will change that.

The `getOption` and `setOption` methods specify that UOE is thrown "If the socket option is not supported by this channel" - but with the current proposal this is not the case - UOE will be thrown for this new option even though the channel supports the option (`supportedOptions` contains the new option).

Has any consideration been given to restricting the set of allowable integer values that may be set for this option - say, to none? Which would then lead to an IllegalArgumentException if `setOption` is invoked in an attempt to set this socket option - since no given value is allowable.

---

In terms of retrieval, is `0` a valid value for this option? if so then uninitialized versus initialized states are indistinguishable. Maybe not be a problem, I dunno yet without further investigation.

Also, when a non-0 value is read, is it guaranteed to remain constant thereafter, or does an application need to periodically check the socket option value.

-Chris.