All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Paolo Abeni <pabeni@redhat.com>
Cc: Florian Westphal <fw@strlen.de>,
	mptcp@lists.linux.dev, mptcp@lists.01.org
Subject: Re: [MPTCP] [RFC PATCH mptcp-next v2 1/8] mptcp: add skeleton to sync msk socket options to subflows
Date: Wed, 24 Mar 2021 21:01:48 +0100	[thread overview]
Message-ID: <20210324200148.GL22603@breakpoint.cc> (raw)
In-Reply-To: <85febbb1c0b4dc7b73861fabdc846194f468f127.camel@redhat.com>

Paolo Abeni <pabeni@redhat.com> wrote:
> On Wed, 2021-03-24 at 14:15 +0100, Florian Westphal wrote:
> > Handle following cases:
> > 1. setsockopt is called with multiple subflows.
> >    Change might have to be mirrored to all of them.
> >    This is done directly in process context/setsockopt call.
> > 2. Outgoing subflow is created after one or several setsockopt()
> >    calls have been made.  Old setsockopt changes should be
> >    synced to the new socket.
> > 3. Incoming subflow, after setsockopt call(s).
> > 
> > Cases 2 and 3 are handled right after the join list is spliced to the
> > conn list.
> > 
> > Because splicing is sometimes done from non-preemptible context, the
> > sync action can be deferred to the work queue.
> > 
> > Add sequence numbers to subflow context and mptcp socket so
> > synchronization functions know which subflow is already updated
> > and which are not.
> > 
> > seqno is re-set to 1 in mptcp_sockopt_sync_all(), at this point
> > the list of subflows is up to date.
> > 
> > A setsockopt sequence count of 0 means that no setsockopt call
> > was made so no synchronization is needed.
> > 
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> 
> If I read correctly, each incoming subflow always get setsockopt_seq =
> 0 at accept time, while outgoing subflow are always synced at creation
> time.

Yes, outgoing are synced at creation time.

> It looks like we have 2 semantically different 'msk->setsockopt_seq'
> values:
> * 0 -> no sync required
> * any value greater than 0 -> sync required for incoming subflows.
> 
> If so, setsockopt could always set msk->setsockopt_seq to 1 and no need
> to reset after sync_all.

In the outgoing case, the subflow isn't linked to the conn_list yet.

It syncs current msk settings, but user could setsockopt() before
the connect finishes, in that case another sync is needed after
connection completes.  No idea how to handle this with single toggle
bit.

I could make it so that it always re-syncs after connect/join finishes.

> socket()
> sesockopt()
> listen()
> // msks is accepted, msk->setsockopt_seq != 0
> // mpj subflow is accepted, ssk->setsockopt_seq == 0, the mpj ssk
> inherited from the listener socket the same sockoptions of the msk/mpc
> subflow

I'm not sure all options have this 'inherited from listener' behaviour.

  reply	other threads:[~2021-03-24 20:01 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 [this message]
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
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=20210324200148.GL22603@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=mptcp@lists.01.org \
    --cc=mptcp@lists.linux.dev \
    --cc=pabeni@redhat.com \
    /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.