summaryrefslogtreecommitdiff
path: root/net/rds/info.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2020-05-17 12:35:35 -0700
committerDavid S. Miller <davem@davemloft.net>2020-05-17 12:35:35 -0700
commit9740a7ae6d5208897bf3ef49e8595dc4cfd323ee (patch)
tree11c8520bff5181c4954df61a7082f12f441f0867 /net/rds/info.c
parenteb682677f59e809d8e06c218b565aeb9723a4ad3 (diff)
parent4930f4831b1547b52c5968e9307fe3d840d7fba0 (diff)
Merge branch 'mptcp-do-not-block-on-subflow-socket'
Florian Westphal says: ==================== mptcp: do not block on subflow socket 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. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/rds/info.c')
0 files changed, 0 insertions, 0 deletions