From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Florian Westphal <fw@strlen.de>
Cc: mptcp@lists.linux.dev, mptcp@lists.01.org
Subject: Re: [RFC PATCH mptcp-next v2 5/8] mptcp: setsockopt: add SO_MARK support
Date: Wed, 24 Mar 2021 18:22:52 -0700 (PDT) [thread overview]
Message-ID: <c4fbd91c-2873-956b-df8-7bba2da711f@linux.intel.com> (raw)
In-Reply-To: <20210324131546.13730-6-fw@strlen.de>
On Wed, 24 Mar 2021, Florian Westphal wrote:
> Value is synced to all subflows.
>
The use case I remember for SO_MARK with MPTCP was to designate different
interfaces for different subflows:
https://lore.kernel.org/mptcp/CAKD1Yr2sBCdUO48cp=rZQ6s4v13ytpPd9oPT+U=iYrdXtba5HA@mail.gmail.com/
Once we have a way to set individual subflow options, it could both be
useful to set sk_mark on all subflows, and also to not override individual
settings. The current sync mechanism would overwrite all supported options
when any single option changes.
There's no way for these options to diverge yet, so we could wait on
solving that problem. Do you think it's better to stick with the current
syncing method for now, or to do more detailed tracking of which options
need to be synced?
Mat
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> net/mptcp/sockopt.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index f33a9ee12544..cb29013d7d74 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
> @@ -66,6 +66,12 @@ static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optname, in
> ssk->sk_userlocks |= SOCK_RCVBUF_LOCK;
> WRITE_ONCE(ssk->sk_rcvbuf, sk->sk_rcvbuf);
> break;
> + case SO_MARK:
> + if (READ_ONCE(ssk->sk_mark) != sk->sk_mark) {
> + ssk->sk_mark = sk->sk_mark;
> + sk_dst_reset(ssk);
> + }
> + break;
> }
>
> subflow->setsockopt_seq = msk->setsockopt_seq;
> @@ -103,6 +109,7 @@ static int mptcp_setsockopt_sol_socket_int(struct mptcp_sock *msk, int optname,
> case SO_KEEPALIVE:
> mptcp_sol_socket_sync_intval(msk, optname, val);
> return 0;
> + case SO_MARK:
> case SO_PRIORITY:
> case SO_SNDBUF:
> case SO_SNDBUFFORCE:
> @@ -193,6 +200,7 @@ static int mptcp_setsockopt_sol_socket(struct mptcp_sock *msk, int optname,
> case SO_SNDBUFFORCE:
> case SO_RCVBUF:
> case SO_RCVBUFFORCE:
> + case SO_MARK:
> return mptcp_setsockopt_sol_socket_int(msk, optname, optval, optlen);
> case SO_LINGER:
> return mptcp_setsockopt_sol_socket_linger(msk, optval, optlen);
> @@ -521,6 +529,11 @@ static void sync_socket_options(struct mptcp_sock *msk, struct sock *ssk)
> } else {
> sock_reset_flag(ssk, SOCK_LINGER);
> }
> +
> + if (sk->sk_mark != ssk->sk_mark) {
> + ssk->sk_mark = sk->sk_mark;
> + sk_dst_reset(ssk);
> + }
> }
>
> void mptcp_sockopt_sync(struct mptcp_sock *msk, struct sock *ssk)
> --
> 2.26.3
>
>
>
--
Mat Martineau
Intel
next prev parent reply other threads:[~2021-03-25 1:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-24 13:15 [RFC PATCH mptcp-next v2 0/8] initial SOL_SOCKET support Florian Westphal
2021-03-24 13:15 ` [RFC PATCH mptcp-next v2 1/8] mptcp: add skeleton to sync msk socket options to subflows Florian Westphal
2021-03-24 17:38 ` [MPTCP] " Paolo Abeni
2021-03-24 20:01 ` Florian Westphal
2021-03-25 9:51 ` Paolo Abeni
2021-03-25 12:49 ` Florian Westphal
2021-03-25 13:12 ` Paolo Abeni
2021-03-25 14:06 ` Florian Westphal
2021-03-25 14:33 ` Paolo Abeni
2021-03-25 14:45 ` Florian Westphal
2021-03-26 9:59 ` Paolo Abeni
2021-03-24 13:15 ` [RFC PATCH mptcp-next v2 2/8] mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY Florian Westphal
2021-03-24 13:15 ` [RFC PATCH mptcp-next v2 3/8] mptcp: setsockopt: handle receive/send buffer and device bind Florian Westphal
2021-03-24 16:34 ` [MPTCP] " Paolo Abeni
2021-03-24 17:15 ` Florian Westphal
2021-03-24 13:15 ` [RFC PATCH mptcp-next v2 4/8] mptcp: setsockopt: support SO_LINGER Florian Westphal
2021-03-24 13:15 ` [RFC PATCH mptcp-next v2 5/8] mptcp: setsockopt: add SO_MARK support Florian Westphal
2021-03-25 1:22 ` Mat Martineau [this message]
2021-03-25 9:32 ` Florian Westphal
2021-03-26 0:14 ` Mat Martineau
2021-03-24 13:15 ` [RFC PATCH mptcp-next v2 6/8] mptcp: setsockopt: add SO_INCOMING_CPU Florian Westphal
2021-03-24 13:15 ` [RFC PATCH mptcp-next v2 7/8] mptcp: setsockopt: SO_DEBUG and no-op options Florian Westphal
2021-03-24 13:15 ` [RFC PATCH mptcp-next v2 8/8] mptcp: sockopt: add TCP_CONGESTION and TCP_INFO Florian Westphal
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=c4fbd91c-2873-956b-df8-7bba2da711f@linux.intel.com \
--to=mathew.j.martineau@linux.intel.com \
--cc=fw@strlen.de \
--cc=mptcp@lists.01.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.