From: Florian Westphal <f...@strlen.de> Date: Sat, 16 May 2020 10:46:16 +0200
> This series reworks mptcp_sendmsg logic to avoid blocking on the subflow > socket. > > It does so by removing the wait loop from mptcp_sendmsg_frag helper. > > In order to do that, it moves prerequisites that are currently > handled in mptcp_sendmsg_frag (and cause it to wait until they are > met, e.g. frag cache refill) into the callers. > > The worker can just reschedule in case no subflow socket is ready, > since it can't wait -- doing so would block other work items and > doesn't make sense anyway because we should not (re)send data > in case resources are already low. > > The sendmsg path can use the existing wait logic until memory > becomes available. > > Because large send requests can result in multiple mptcp_sendmsg_frag > calls from mptcp_sendmsg, we may need to restart the socket lookup in > case subflow can't accept more data or memory is low. > > Doing so blocks on the mptcp socket, and existing wait handling > releases the msk lock while blocking. > > Lastly, no need to use GFP_ATOMIC for extension allocation: > extend __skb_ext_alloc with gfp_t arg instead of hard-coded ATOMIC and > then relax the allocation constraints for mptcp case: those requests > occur in process context. Series applied, thanks Florian.
