On Mon, Jun 25, 2018 at 9:30 PM, Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx> wrote: > On Mon, Jun 25, 2018 at 10:06:46AM +0800, Xin Long wrote: >> This feature is actually already supported by sk->sk_reuse which can be >> set by socket level opt SO_REUSEADDR. But it's not working exactly as >> RFC6458 demands in section 8.1.27, like: >> >> - This option only supports one-to-one style SCTP sockets >> - This socket option must not be used after calling bind() >> or sctp_bindx(). >> >> Besides, SCTP_REUSE_PORT sockopt should be provided for user's programs. >> Otherwise, the programs with SCTP_REUSE_PORT from other systems will not >> work in linux. >> >> To separate it from the socket level version, this patch adds 'reuse' in >> sctp_sock and it works pretty much as sk->sk_reuse, but with some extra >> setup limitations that are needed when it is being enabled. >> >> "It should be noted that the behavior of the socket-level socket option >> to reuse ports and/or addresses for SCTP sockets is unspecified", so it >> leaves SO_REUSEADDR as is for the compatibility. >> >> Note that the name SCTP_REUSE_PORT is kind of confusing, it is identical >> to SO_REUSEADDR with some extra restriction, so here it uses 'reuse' in >> sctp_sock instead of 'reuseport'. As for sk->sk_reuseport support for >> SCTP, it will be added in another patch. > > To help changelog readers later, please update to something like: > > """\ > Note that the name SCTP_REUSE_PORT is somewhat confusing, as its > functionality is nearly identical to SO_REUSEADDR, but with some > extra restrictions. Here it uses 'reuse' in sctp_sock instead of > 'reuseport'. As for sk->sk_reuseport support for SCTP, it will be > added in another patch. > """ > > Makes sense, can you note the difference? Sure, will post v3. thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html