Re: IRC snippet

[Geliang Tang <geliangtang@gmail.com>]

Hi Paolo,

Thanks for your information, it's very helpful. And I have two more
questions below.

Paolo Abeni <pabeni@redhat.com> 于2021年7月22日周四 下午7:23写道：
>
> Hello,
>
> moving here from IRC, to avoid disconnection issues...
> < geliang >   Yes, Netd has the similar thing
>   < geliang >   It can get the IP up/down event too
>   < geliang >   https://android.googlesource.com/platform/system/netd/
>   < geliang >   So I need to add a new flag full-mesh to netlink
>   < geliang >   and drop the notifiers
>   < geliang >   and add the addresses array in
> mptcp_pm_create_subflow_or_signal_addr
> < geliang >   I'll do these things, thanks Paolo
>
> Note that the array size should be limited by the
> current add_addr_signal_max (and thus should be max 8).
>
> Each array entry should be mptcp_addr_info, that is 24 bytes.
>
> 24*8 = 192
>
> The above *could* be a little too much for a stack-based local
> variable, anyhow the kernel should tell, if so, you will get a warning
> at run time alike 'x function is using y bytes of stack'.
>
> In case of such warn you could:
> - dynamically allocate such array (and fail if allocation fail)
> [or]
> - add such stiorage inside mptcp_pm_data
> [or]
> - something in between e.g. use a local variable to a very limited
> amount of addresses and then dynamically allocate a variable.

If the endpoint's flag is subflow,fullmesh, we need to get all the remote
addresses. So we need to record all the received ADD_ADDRs. Should these
two old patches work?

mptcp: rename mptcp_pm_add_entry to mptcp_pm_anno_entry
mptcp: add add_list in mptcp_pm_data
https://patchwork.kernel.org/project/mptcp/patch/ae0d32922128771f09b230e5718774472a088207.1621002341.git.geliangtang@gmail.com/
https://patchwork.kernel.org/project/mptcp/patch/850406b0f49fa0a76b4825b36c55426a0d033d52.1621002341.git.geliangtang@gmail.com/

If we use these two patches, then we can connect all the remote addresses
like this in mptcp_pm_create_subflow_or_signal_addr:

if (local->flags & MPTCP_PM_ADDR_FLAG_FULLMESH) {
        struct mptcp_pm_add_entry *entry;

        list_for_each_entry(entry, &msk->pm.add_list. list)
                __mptcp_subflow_connect(sk, &local->addr,
&entry->addr, local->flags, local->ifindex);
}

What do you think about this approach?

>
> I *think* the latter could be an interesting option.
>
> Finally note that similar changes will be required
> in mptcp_pm_nl_add_addr_received(), with the main difference
> that mptcp_pm_nl_add_addr_received will fill the array with all the
> known local addresses, while mptcp_pm_create_subflow_or_signal_addr()
> will fill it with remote addresses.

If the endpoint's flag is signal,fullmesh, we announce this address, send
this address with ADD_ADDR to the peer. The peer received the ADD_ADDR in
mptcp_pm_nl_add_addr_received. It's easy to get all the local addresses,
it's on the local_addr_list.

But how can we know whether the received address is a fullmesh one or not
in mptcp_pm_nl_add_addr_received? The endpoint's flag is set on the other
side. In mptcp_pm_nl_add_addr_received, we can't get this flag.

Do you have a good way to do this?

Thanks,
-Geliang

>
> Cheers,
>
> Paolo
>