All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matttbe@kernel.org>
To: Geliang Tang <geliang@kernel.org>, mptcp@lists.linux.dev
Cc: Geliang Tang <tanggeliang@kylinos.cn>
Subject: Re: [PATCH mptcp-next v5 2/9] mptcp: pm: add struct mptcp_pm_param
Date: Fri, 21 Feb 2025 18:23:24 +0100	[thread overview]
Message-ID: <9f7ee817-529f-4382-bc53-6a6d6e532e49@kernel.org> (raw)
In-Reply-To: <2f68d8851458f6f5acfd9a6ea549f3b73029d4bc.1740019794.git.tanggeliang@kylinos.cn>

Hi Geliang,

On 20/02/2025 03:57, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> Generally, in the path manager interfaces, the local address is defined
> as an mptcp_pm_addr_entry type address, while the remote address is
> defined as an mptcp_addr_info type one:
> 
>     (struct mptcp_pm_addr_entry *local, struct mptcp_addr_info *remote)
> 
> In order to make these interfaces more flexible and extensible, a struct
> mptcp_pm_param is defined here to pass parameters. "entry" can be used
> as the local address entry, and "addr" can be used as the remote address.

Mmh, it is not clear to me why you cannot use only the parameters that
are needed per interfaces, e.g. "local" and "remote". These parameters
are not even always needed, e.g. when an address has been announced,
"remote" doesn't make sense here. Same for get_local_id and
get_priority. Similarly, when an address has been removed, only the ID
is needed for the PM, etc.

I'm not convinced by the "flexible and extensible" reasons for the
future: "local" and "remote" will likely not change. If we want to add
more parameters, will we require them for all interfaces?

Also, if you use similar signatures as the ones being used, no need to
do many changes in the current in-kernel and userspace PM, e.g. no need
to introduce the new helpers in patches 5 and 6. Instead, these patches
could directly set the available helpers, and we can reduce the number
of patches, e.g. patches 8 and 9 (and more) could all come in one, no?

Plus, it feels strange to copy data from one structure to another just
to pass parameters, no?

Are you sure we need this patch? (and the next one?)

> Also add a new helper mptcp_pm_param_set_contexts() to set a struct
> mptcp_pm_param type parameter.
> 
> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> ---
>  include/net/mptcp.h  | 13 +++++++++++++
>  net/mptcp/pm.c       | 10 ++++++++++
>  net/mptcp/protocol.h | 11 +++--------
>  3 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/include/net/mptcp.h b/include/net/mptcp.h
> index 72d6e6597add..a41d6c74760f 100644
> --- a/include/net/mptcp.h
> +++ b/include/net/mptcp.h
> @@ -121,6 +121,19 @@ struct mptcp_sched_ops {
>  	void (*release)(struct mptcp_sock *msk);
>  } ____cacheline_aligned_in_smp;
>  
> +struct mptcp_pm_addr_entry {
> +	struct list_head	list;
> +	struct mptcp_addr_info	addr;
> +	u8			flags;
> +	int			ifindex;
> +	struct socket		*lsk;
> +};
> +
> +struct mptcp_pm_param {
> +	struct mptcp_pm_addr_entry	entry;
> +	struct mptcp_addr_info		addr;
If this structure is really needed, it seems clearer to use "local" and
"remote" instead of "entry" and "addr".

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


  reply	other threads:[~2025-02-21 17:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-20  2:57 [PATCH mptcp-next v5 0/9] BPF path manager, part 4 Geliang Tang
2025-02-20  2:57 ` [PATCH mptcp-next v5 1/9] mptcp: pm: use addr entry for get_local_id Geliang Tang
2025-02-21 17:23   ` Matthieu Baerts
2025-02-20  2:57 ` [PATCH mptcp-next v5 2/9] mptcp: pm: add struct mptcp_pm_param Geliang Tang
2025-02-21 17:23   ` Matthieu Baerts [this message]
2025-02-20  2:57 ` [PATCH mptcp-next v5 3/9] mptcp: pm: pass pm_param to get_local_id Geliang Tang
2025-02-20  2:57 ` [PATCH mptcp-next v5 4/9] mptcp: pm: define struct mptcp_pm_ops Geliang Tang
2025-02-21 17:23   ` Matthieu Baerts
2025-02-24  6:54     ` Geliang Tang
2025-02-24  8:26       ` Matthieu Baerts
2025-02-24  9:11         ` Geliang Tang
2025-02-24 10:24           ` Matthieu Baerts
2025-02-20  2:57 ` [PATCH mptcp-next v5 5/9] mptcp: pm: in-kernel: register mptcp_netlink_pm Geliang Tang
2025-02-20  2:57 ` [PATCH mptcp-next v5 6/9] mptcp: pm: userspace: register mptcp_userspace_pm Geliang Tang
2025-02-20  2:57 ` [PATCH mptcp-next v5 7/9] mptcp: pm: initialize and release mptcp_pm_ops Geliang Tang
2025-02-20  2:57 ` [PATCH mptcp-next v5 8/9] mptcp: pm: drop get_local_id helpers Geliang Tang
2025-02-21 17:23   ` Matthieu Baerts
2025-02-20  2:57 ` [PATCH mptcp-next v5 9/9] mptcp: pm: drop is_backup helpers Geliang Tang
2025-02-20  4:12 ` [PATCH mptcp-next v5 0/9] BPF path manager, part 4 MPTCP CI
2025-02-21 17:23 ` Matthieu Baerts

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=9f7ee817-529f-4382-bc53-6a6d6e532e49@kernel.org \
    --to=matttbe@kernel.org \
    --cc=geliang@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=tanggeliang@kylinos.cn \
    /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.