Re: [PATCH v3 mptcp-next 2/6] mptcp: introduce MPTCP_FULL_INFO getsockopt

[Florian Westphal <fw@strlen.de>]

Matthieu Baerts <matthieu.baerts@tessares.net> wrote:
> > I added the "num_subflows_copied" for ease-of-use on userspace
> > side but I agree that its not required and userspace has
> > enough info to figure out which upper cap to use.
> 
> If I understand properly, it means that num_subflows_user and _kern will
> only be used to know the size of the arrays:
> 
> - num_subflows_user: size of the arrays in the buffer
> - num_subflows_kern: what has been written by the kernel, max _user

This is why I had the '_copied' in my proposal :-)

With only _user and _kern:

_user: size of the arrays in the buffer
_kern: subflow count of the kernel, i.e. can be larger than _user.

> I think it is still important to have somewhere a num_subflows field to
> know how many subflows are attached to an MPTCP connection (also for the
> userspace to know if it missed some info because it gave a too small
> buffer).

Yes, userspace must be able to infer that it only got partial
information due to lack of space.

E.g. if userspace expects a maximum amount of 16 subflows but connection
has 240 subflows then num_subflows_kern is 240 and _user is 16.

Userspace can only access up to 16 (since thats what it
provided/allocated).

The _copied proposal would have made this easier on userspace side
(_user is the allocated space, _kern what the kernel would like (real
count), and _copied what was written out).

But as Paolo said userspace can infer the valid count by checking
if _kern > _user, so it does:

bool truncated = kern > user;
subflows_copied = truncated ? user : kern;