All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matttbe@kernel.org>
To: Geliang Tang <geliang@kernel.org>,
	MPTCP Upstream <mptcp@lists.linux.dev>
Subject: Re: [PATCH mptcp-next 02/10] mptcp: pm: in-kernel: refactor fill_local_addresses_vec
Date: Fri, 19 Sep 2025 10:25:12 +0200	[thread overview]
Message-ID: <98655217-febd-4744-9333-df441f6649a3@kernel.org> (raw)
In-Reply-To: <0c764cfdff33d8d903d78b90bd59a8406552dee2.camel@kernel.org>

Hi Geliang,

On 19/09/2025 08:51, Geliang Tang wrote:
> Hi Matt,
> 
> On Thu, 2025-09-18 at 19:42 +0200, Matthieu Baerts (NGI0) wrote:
>> Before this modification, this function was quite long with many
>> levels
>> of indentations.
>>
>> Each case can be split in a dedicated function: fullmesh, C flag,
>> any.
> 
> If "C flag" function is squash into patch 1, how about splitting this
> patch into two, one for 'fullmesh' and one for 'any'.

I would prefer not to. I don't think it is really needed to split that
in multiple patches.

(...)

>> +/* Fill all the local addresses into the array addrs[],
>> + * and return the array size.
>> + */
>> +static unsigned int
>> +fill_local_addresses_vec(struct mptcp_sock *msk, struct
>> mptcp_addr_info *remote,
>> +			 struct mptcp_pm_local *locals)
> 
> How about keeping this unchanged:
> 
> static unsigned int fill_local_addresses_vec(struct mptcp_sock *msk,
> 					     struct mptcp_addr_info
> *remote,
> 					     struct mptcp_pm_local
> *locals)
> 
> This can make the patch smaller.

I did these modifications because that's the style I used in the new
functions, plus I think it is better to avoid big indentations.

I don't think we really need to make this patch smaller, it is just a
"pure" refactoring.

> 
>> +{
>> +	bool c_flag_case = remote->id &&
>> mptcp_pm_add_addr_c_flag_case(msk);
>> +	int i;
>> +
>> +	/* If there is at least one MPTCP endpoint with a fullmesh
>> flag */
>> +	i = fill_local_addresses_vec_fullmesh(msk, remote, locals,
>> c_flag_case);
>> +	if (i)
>> +		return i;
>> +
>>  	/* Special case: peer sets the C flag, accept one ADD_ADDR
>> if default
>>  	 * limits are used -- accepting no ADD_ADDR -- and use
>> subflow endpoints
>>  	 */
>> -	if (!i && c_flag_case) {
>> -		unsigned int local_addr_max =
>> mptcp_pm_get_local_addr_max(msk);
>> +	if (c_flag_case)
>> +		return fill_local_addresses_vec_c_flag(msk, remote,
>> locals);
>>  
>> -		while (msk->pm.local_addr_used < local_addr_max &&
>> -		       msk->pm.subflows < subflows_max) {
>> -			struct mptcp_pm_local *local = &locals[i];
>> -
>> -			if (!select_local_address(pernet, msk,
>> local))
>> -				break;
>> -
>> -			__clear_bit(local->addr.id, msk-
>>> pm.id_avail_bitmap);
>> -
>> -			if (!mptcp_pm_addr_families_match(sk,
>> &local->addr,
>> -							  remote))
>> -				continue;
>> -
>> -			if (mptcp_addresses_equal(&local->addr,
>> &mpc_addr,
>> -						  local->addr.port))
>> -				continue;
>> -
>> -			msk->pm.local_addr_used++;
>> -			msk->pm.subflows++;
>> -			i++;
>> -		}
>> -
>> -		return i;
>> -	}
>> -
>> -	/* If the array is empty, fill in the single
>> -	 * 'IPADDRANY' local address
>> -	 */
>> -	if (!i) {
>> -		memset(&locals[i], 0, sizeof(locals[i]));
>> -		locals[i].addr.family =
>> -#if IS_ENABLED(CONFIG_MPTCP_IPV6)
>> -			       remote->family == AF_INET6 &&
>> -			       ipv6_addr_v4mapped(&remote->addr6) ?
>> AF_INET :
>> -#endif
>> -			       remote->family;
>> -
>> -		if (!mptcp_pm_addr_families_match(sk,
>> &locals[i].addr, remote))
>> -			return 0;
>> -
>> -		msk->pm.subflows++;
>> -		i++;
>> -	}
>> -
>> -	return i;
>> +	/* No special case: fill in the single 'IPADDRANY' local
>> address */
>> +	return fill_local_address_any(msk, remote, &locals[0]);
>>  }
>>  
>>  static void mptcp_pm_nl_add_addr_received(struct mptcp_sock *msk)
>> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
>> index
>> dd0662defd41c84474e44c559c571e3594b85d9e..0d6dae37c9daf4ec8990b9a8703
>> 6aa393add585c 100644
>> --- a/net/mptcp/protocol.h
>> +++ b/net/mptcp/protocol.h
>> @@ -1200,7 +1200,8 @@ static inline bool
>> mptcp_pm_add_addr_c_flag_case(struct mptcp_sock *msk)
>>  {
>>  	return READ_ONCE(msk->pm.remote_deny_join_id0) &&
>>  	       msk->pm.local_addr_used == 0 &&
>> -	       mptcp_pm_get_add_addr_accept_max(msk) == 0;
>> +	       mptcp_pm_get_add_addr_accept_max(msk) == 0 &&
>> +	       msk->pm.subflows < mptcp_pm_get_subflows_max(msk);
> 
> This needs to be squash to patch 1 too.

It is currently not needed, see this message in the commit message:

> To remove one level of indentation, msk->pm.subflows >= subflows_max is
> now checked upfront.
But I guess it doesn't hurt to move it there, just to be on the safe
side, and avoid this note.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.


  reply	other threads:[~2025-09-19  8:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18 17:42 [PATCH mptcp-next 00/10] mptcp: pm: a few cleanups Matthieu Baerts (NGI0)
2025-09-18 17:42 ` [PATCH mptcp-next 01/10] Squash to "mptcp: pm: in-kernel: usable client side with C-flag" Matthieu Baerts (NGI0)
2025-09-19  3:18   ` Geliang Tang
2025-09-19  8:19     ` Matthieu Baerts
2025-09-18 17:42 ` [PATCH mptcp-next 02/10] mptcp: pm: in-kernel: refactor fill_local_addresses_vec Matthieu Baerts (NGI0)
2025-09-19  6:51   ` Geliang Tang
2025-09-19  8:25     ` Matthieu Baerts [this message]
2025-09-18 17:42 ` [PATCH mptcp-next 03/10] mptcp: pm: in-kernel: refactor fill_remote_addresses_vec Matthieu Baerts (NGI0)
2025-09-19  6:52   ` Geliang Tang
2025-09-19  8:41     ` Matthieu Baerts
2025-09-18 17:42 ` [PATCH mptcp-next 04/10] mptcp: pm: rename 'subflows' to 'extra_subflows' Matthieu Baerts (NGI0)
2025-09-18 17:42 ` [PATCH mptcp-next 05/10] mptcp: pm: in-kernel: rename 'subflows_max' to 'limit_extra_subflows' Matthieu Baerts (NGI0)
2025-09-18 17:42 ` [PATCH mptcp-next 06/10] mptcp: pm: in-kernel: rename 'add_addr_signal_max' to 'endp_signal_max' Matthieu Baerts (NGI0)
2025-09-18 17:42 ` [PATCH mptcp-next 07/10] mptcp: pm: in-kernel: rename 'add_addr_accept_max' to 'limit_add_addr_accepted' Matthieu Baerts (NGI0)
2025-09-18 17:42 ` [PATCH mptcp-next 08/10] mptcp: pm: in-kernel: rename 'local_addr_max' to 'endp_subflow_max' Matthieu Baerts (NGI0)
2025-09-18 17:42 ` [PATCH mptcp-next 09/10] mptcp: pm: in-kernel: rename 'local_addr_list' to 'endp_list' Matthieu Baerts (NGI0)
2025-09-18 17:42 ` [PATCH mptcp-next 10/10] mptcp: pm: in-kernel: rename 'addrs' to 'endpoints' Matthieu Baerts (NGI0)
2025-09-18 19:29 ` [PATCH mptcp-next 00/10] mptcp: pm: a few cleanups MPTCP CI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98655217-febd-4744-9333-df441f6649a3@kernel.org \
    --to=matttbe@kernel.org \
    --cc=geliang@kernel.org \
    --cc=mptcp@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.