From: Mat Martineau <mathew.j.martineau at linux.intel.com>
To: mptcp at lists.01.org
Subject: [MPTCP] Re: [PATCH net-next 2/6] mptcp: protect the rx path with the msk socket spinlock
Date: Tue, 10 Nov 2020 18:12:25 -0800 [thread overview]
Message-ID: <dbd6ea54-5369-95c7-4526-3ef2926e38a5@linux.intel.com> (raw)
In-Reply-To: d1779b7594d19cfcf84a64e11726f190f14bfa6c.1605006569.git.pabeni@redhat.com
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
On Tue, 10 Nov 2020, Paolo Abeni wrote:
> Such spinlock is currently used only to protect the 'owned'
> flag inside the socket lock itself. With this patch we extend
> it's scope to protect the whole msk receive path and
> sk_forward_memory.
>
Is it a problem that lock_sock()/release_sock() and the data path will be
competing for this spinlock? Just wondering if the choice to use this lock
is driven by not wanting to add a new lock (which is understandable!).
Given that the spinlock is only held for short times hopefully the data
path is not delaying the regular socket lock calls very much.
> Given the above we can always move data into the msk receive queue
> (and OoO queue) from the subflow.
>
> We leverage the previous commit, so that we need to acquire the
> spinlock in the tx path only when moving fwd memory
> to wfwd and vice versa.
>
> recvmsg() must now explicitly acquire the socket spinlock
> when moving skbs out of sk_receive_queue. We use a snd rx
> queue and splice the first into the latter to reduce the number locks
> required.
To see if I understood this (and the code) correctly:
For the msk, sk_receive_queue is protected only by the mptcp_data_lock()
and is where MPTCP-level data is reassembled in-order without holding the
msk socket lock.
msk->receive_queue is protected by the socket lock, and is where in-order
skbs are moved so they can be copied to userspace.
I still need to take a deeper look at the locking changes but the approach
looks ok.
--
Mat Martineau
Intel
next reply other threads:[~2020-11-11 2:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-11 2:12 Mat Martineau [this message]
2020-11-11 9:24 [MPTCP] Re: [PATCH net-next 2/6] mptcp: protect the rx path with the msk socket spinlock Paolo Abeni
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=dbd6ea54-5369-95c7-4526-3ef2926e38a5@linux.intel.com \
--to=unknown@example.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.