Thanks for your comments. The patch with updated doc available as: http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.06/
Thanks, Vladimir -----Original Message----- From: Alan Bateman <alan.bate...@oracle.com> Sent: Friday, May 1, 2020 5:04 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 30/04/2020 22:20, Ivanov, Vladimir A 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 think this is getting better but it switches from "receive queue" to "device queue" and then mentions "busy polling" and minimizing context switches which might be a bit much. What would you think of this alternative: /** * Identifies the receive queue that the last incoming packet for the socket * was received on. * * <p> The value of this socket option is an {@code Integer} that identifies a * receive queue that the application can use to split the incoming flows among * threads based on the queue identifier. * * <p> The socket option is read-only and any attempt to set the socket option * will throw {@code UnsupportedOperationException}. * * <p> The socket option is supported by both stream and datagram oriented sockets. * The value of the socket option is {@code 0} when the socket is not bound or a * packet has not been received. * * @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 */
