Re: [PATCH net-next v3 0/2] Add IP_LOCAL_PORT_RANGE socket option

[Jakub Sitnicki <jakub@cloudflare.com>]

On Fri, Jan 20, 2023 at 11:44 AM -05, Neal Cardwell wrote:
> )On Fri, Jan 20, 2023 at 6:53 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>>
>> This patch set is a follow up to the "How to share IPv4 addresses by
>> partitioning the port space" talk given at LPC 2022 [1].
>>
>> Please see patch #1 for the motivation & the use case description.
>> Patch #2 adds tests exercising the new option in various scenarios.
>>
>> Documentation
>> -------------
>>
>> Proposed update to the ip(7) man-page:
>>
>>        IP_LOCAL_PORT_RANGE (since Linux X.Y)
>>               Set or get the per-socket default local port range. This
>>               option  can  be used to clamp down the global local port
>>               range, defined by the ip_local_port_range  /proc  inter‐
>>               face described below, for a given socket.
>>
>>               The option takes an uint32_t value with the high 16 bits
>>               set to the upper range bound, and the low 16 bits set to
>>               the lower range bound. Range bounds are inclusive.
>
> IMHO it would be nice for this text to document whether the port
> numbers are in host order or network order, and perhaps whether "high"
> and "low" here refer to host or network order. Key parts of the
> sockets API express port numbers in network order, but this new API
> seems to express port numbers in host order, so it seem worth (a)
> deciding carefully, and (b) documenting explicitly in the man page
> text (here in the cover letter) and commit message for the patch
> (patch #1).

Good point. Thanks for feedback.

I will expand the description for the man page and the patch #1.

Personally I don't see any upside to using the network byte order here.
With host byte order, users don't need to do anything else but pack the
two u16 values.