[MPTCP] Re: [RFC 4/5] mptcp: update mptcp ack sequence from work queue

[Paolo Abeni <pabeni at redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

On Thu, 2020-02-13 at 11:27 +0100, Florian Westphal wrote:
> +static void __mptcp_move_skbs(struct mptcp_sock *msk)
> +{
> +	struct mptcp_steal_arg arg = {
> +		.msk = msk,
> +		.fin = false,
> +	};
> +	read_descriptor_t desc = {
> +		.arg.data = &arg,
> +	};
> +
> +	for (;;) {
> +		struct mptcp_subflow_context *subflow;
> +		bool more_data_avail;
> +
> +		arg.ssk = mptcp_subflow_recv_lookup(msk);
> +		if (!arg.ssk)
> +			break;
> +
> +		subflow = mptcp_subflow_ctx(arg.ssk);
> +
> +		lock_sock(arg.ssk);
> +
> +		do {
> +			u32 map_remaining;
> +			int bytes_read;
> +
> +			/* try to read as much data as available */
> +			map_remaining = subflow->map_data_len -
> +					mptcp_subflow_get_map_offset(subflow);
> +			desc.count = map_remaining;
> +
> +			bytes_read = tcp_read_sock(arg.ssk, &desc, mptcp_steal_actor);
> +			if (bytes_read <= 0) {
> +				release_sock(arg.ssk);
> +				return;
> +			}
> +
> +			if (arg.fin) {
> +				struct tcp_sock *tp = tcp_sk(arg.ssk);
> +				u32 seq = READ_ONCE(tp->copied_seq);
> +
> +				WRITE_ONCE(tp->copied_seq, seq + 1);
> +			}
> +
> +			more_data_avail = mptcp_subflow_data_available(arg.ssk);
> +		} while (more_data_avail);
> +
> +		release_sock(arg.ssk);
> +	}
> +}

Overall the above move the pending skbs to the msk receive queue,
increment ssk copied_seq and eventually let TCP send ack via
tcp_cleanup_rbuf().

I think we could avoid touching tcp_read_sock() in patch 2/5 moving the
skb directly from __mptcp_move_skbs() - no call to tcp_read_sock(),
just queue manipulation and copied_seq accounting.

Than __mptcp_move_skbs() will call directly, as needed - need to export
it.

We could additionally clean-up the code calling __mptcp_move_skbs()
from mptcp_recvmsg() before looking into the msk receive queue. Than no
need for the current recvmsg inner loop.

I fear we need some tweek to handle TCP fallback. If I read the RFC
correctly the msk can fallback to TCP even after receiving some DSS
data (e.g. msk receive queue contains some skbs and the msk fallback to
TCP. We can't call anymore sock_recvmsg())

WDYT?

Thanks,

Paolo