All of lore.kernel.org
 help / color / mirror / Atom feed
* [MPTCP] Re: [RFC 06/14] sendmsg: block until mptcp sk is writeable
@ 2019-11-18 12:11 Florian Westphal
  0 siblings, 0 replies; 5+ messages in thread
From: Florian Westphal @ 2019-11-18 12:11 UTC (permalink / raw)
  To: mptcp

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

Paolo Abeni <pabeni(a)redhat.com> wrote:
> On Thu, 2019-11-14 at 18:32 +0100, Florian Westphal wrote:
> > This disables transmit of new data until the peer has acked
> > enough mptcp data to get below the wspace write threshold (more than
> > half of wspace upperlimit is available again).
> > 
> > Also have poll not report EPOLLOUT in this case, its not relevant if a
> > subflow is writeable.
> > 
> > The latter is a temporary workaround that is needed because mptcp_poll
> > walks the subflows and calls __tcp_poll on each of them.
> > Because subflow ssk is usually writable, we will have to undo-that
> > if the mptcp sndbuf is exhausted.  This won't be needed anymore once
> > __tcp_poll is removed, I am working on this.
> > 
> > Signed-off-by: Florian Westphal <fw(a)strlen.de>
> > ---
> >  net/mptcp/protocol.c | 18 ++++++++++++++++--
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> > index 2144e80b8704..83be407e1dd6 100644
> > --- a/net/mptcp/protocol.c
> > +++ b/net/mptcp/protocol.c
> > @@ -406,6 +406,18 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
> >  		return ret;
> >  	}
> >  
> > +	timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
> > +
> > +	mptcp_clean_una(sk);
> > +
> > +	while (!sk_stream_memory_free(sk)) {
> > +		ret = sk_stream_wait_memory(sk, &timeo);
> > +		if (ret)
> > +			goto out;
> > +
> > +		mptcp_clean_una(sk);
> > +	}
> > +
> 
> Can we move the above loop to the non fallback case only ? e.g. after
> the below !mptcp_subflow_get(msk) checks?
> 
> If so, we could have a single loop checking for:
> 
> !sk_stream_memory_free(sk) || !mptcp_subflow_get_send()
> 
> (together with the next patch)

It would be easy to do if I remove

       if (!msg_data_left(msg)) {
	       pr_debug("empty send");
	       ret = sock_sendmsg(ssk->sk_socket, msg);

any idea why this is there in the first place?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [MPTCP] Re: [RFC 06/14] sendmsg: block until mptcp sk is writeable
@ 2019-11-18 18:39 Mat Martineau
  0 siblings, 0 replies; 5+ messages in thread
From: Mat Martineau @ 2019-11-18 18:39 UTC (permalink / raw)
  To: mptcp

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

On Mon, 18 Nov 2019, Paolo Abeni wrote:

> On Mon, 2019-11-18 at 13:11 +0100, Florian Westphal wrote:
>> Paolo Abeni <pabeni(a)redhat.com> wrote:
>>> On Thu, 2019-11-14 at 18:32 +0100, Florian Westphal wrote:
>>>> This disables transmit of new data until the peer has acked
>>>> enough mptcp data to get below the wspace write threshold (more than
>>>> half of wspace upperlimit is available again).
>>>>
>>>> Also have poll not report EPOLLOUT in this case, its not relevant if a
>>>> subflow is writeable.
>>>>
>>>> The latter is a temporary workaround that is needed because mptcp_poll
>>>> walks the subflows and calls __tcp_poll on each of them.
>>>> Because subflow ssk is usually writable, we will have to undo-that
>>>> if the mptcp sndbuf is exhausted.  This won't be needed anymore once
>>>> __tcp_poll is removed, I am working on this.
>>>>
>>>> Signed-off-by: Florian Westphal <fw(a)strlen.de>
>>>> ---
>>>>  net/mptcp/protocol.c | 18 ++++++++++++++++--
>>>>  1 file changed, 16 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
>>>> index 2144e80b8704..83be407e1dd6 100644
>>>> --- a/net/mptcp/protocol.c
>>>> +++ b/net/mptcp/protocol.c
>>>> @@ -406,6 +406,18 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
>>>>  		return ret;
>>>>  	}
>>>>
>>>> +	timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
>>>> +
>>>> +	mptcp_clean_una(sk);
>>>> +
>>>> +	while (!sk_stream_memory_free(sk)) {
>>>> +		ret = sk_stream_wait_memory(sk, &timeo);
>>>> +		if (ret)
>>>> +			goto out;
>>>> +
>>>> +		mptcp_clean_una(sk);
>>>> +	}
>>>> +
>>>
>>> Can we move the above loop to the non fallback case only ? e.g. after
>>> the below !mptcp_subflow_get(msk) checks?
>>>
>>> If so, we could have a single loop checking for:
>>>
>>> !sk_stream_memory_free(sk) || !mptcp_subflow_get_send()
>>>
>>> (together with the next patch)
>>
>> It would be easy to do if I remove
>>
>>        if (!msg_data_left(msg)) {
>> 	       pr_debug("empty send");
>> 	       ret = sock_sendmsg(ssk->sk_socket, msg);
>>
>> any idea why this is there in the first place?
>
> Uhmm... that looks like a left-over from the initial implementation ?!?
> possibly trying to deal with fastopen?!?
>
> I think it can be dropped. @Peter / @Mat do you know better?
>

Paolo's right, that's a leftover. You're welcome to drop it.

--
Mat Martineau
Intel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [MPTCP] Re: [RFC 06/14] sendmsg: block until mptcp sk is writeable
@ 2019-11-18 12:19 Paolo Abeni
  0 siblings, 0 replies; 5+ messages in thread
From: Paolo Abeni @ 2019-11-18 12:19 UTC (permalink / raw)
  To: mptcp

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

On Mon, 2019-11-18 at 13:11 +0100, Florian Westphal wrote:
> Paolo Abeni <pabeni(a)redhat.com> wrote:
> > On Thu, 2019-11-14 at 18:32 +0100, Florian Westphal wrote:
> > > This disables transmit of new data until the peer has acked
> > > enough mptcp data to get below the wspace write threshold (more than
> > > half of wspace upperlimit is available again).
> > > 
> > > Also have poll not report EPOLLOUT in this case, its not relevant if a
> > > subflow is writeable.
> > > 
> > > The latter is a temporary workaround that is needed because mptcp_poll
> > > walks the subflows and calls __tcp_poll on each of them.
> > > Because subflow ssk is usually writable, we will have to undo-that
> > > if the mptcp sndbuf is exhausted.  This won't be needed anymore once
> > > __tcp_poll is removed, I am working on this.
> > > 
> > > Signed-off-by: Florian Westphal <fw(a)strlen.de>
> > > ---
> > >  net/mptcp/protocol.c | 18 ++++++++++++++++--
> > >  1 file changed, 16 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> > > index 2144e80b8704..83be407e1dd6 100644
> > > --- a/net/mptcp/protocol.c
> > > +++ b/net/mptcp/protocol.c
> > > @@ -406,6 +406,18 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
> > >  		return ret;
> > >  	}
> > >  
> > > +	timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
> > > +
> > > +	mptcp_clean_una(sk);
> > > +
> > > +	while (!sk_stream_memory_free(sk)) {
> > > +		ret = sk_stream_wait_memory(sk, &timeo);
> > > +		if (ret)
> > > +			goto out;
> > > +
> > > +		mptcp_clean_una(sk);
> > > +	}
> > > +
> > 
> > Can we move the above loop to the non fallback case only ? e.g. after
> > the below !mptcp_subflow_get(msk) checks?
> > 
> > If so, we could have a single loop checking for:
> > 
> > !sk_stream_memory_free(sk) || !mptcp_subflow_get_send()
> > 
> > (together with the next patch)
> 
> It would be easy to do if I remove
> 
>        if (!msg_data_left(msg)) {
> 	       pr_debug("empty send");
> 	       ret = sock_sendmsg(ssk->sk_socket, msg);
> 
> any idea why this is there in the first place?

Uhmm... that looks like a left-over from the initial implementation ?!?
possibly trying to deal with fastopen?!? 

I think it can be dropped. @Peter / @Mat do you know better?

/P

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [MPTCP] Re: [RFC 06/14] sendmsg: block until mptcp sk is writeable
@ 2019-11-18 11:33 Paolo Abeni
  0 siblings, 0 replies; 5+ messages in thread
From: Paolo Abeni @ 2019-11-18 11:33 UTC (permalink / raw)
  To: mptcp

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

On Mon, 2019-11-18 at 12:29 +0100, Paolo Abeni wrote:
> Can we move the above loop to the non fallback case only ? e.g. after
> the below !mptcp_subflow_get(msk) checks?
> 
> If so, we could have a single loop checking for:
> 
> !sk_stream_memory_free(sk) || !mptcp_subflow_get_send()
> 
> (together with the next patch)

Dumb me! I meant "with patch 9/14" - where a similar loop is added.

/P

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [MPTCP] Re: [RFC 06/14] sendmsg: block until mptcp sk is writeable
@ 2019-11-18 11:29 Paolo Abeni
  0 siblings, 0 replies; 5+ messages in thread
From: Paolo Abeni @ 2019-11-18 11:29 UTC (permalink / raw)
  To: mptcp

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

On Thu, 2019-11-14 at 18:32 +0100, Florian Westphal wrote:
> This disables transmit of new data until the peer has acked
> enough mptcp data to get below the wspace write threshold (more than
> half of wspace upperlimit is available again).
> 
> Also have poll not report EPOLLOUT in this case, its not relevant if a
> subflow is writeable.
> 
> The latter is a temporary workaround that is needed because mptcp_poll
> walks the subflows and calls __tcp_poll on each of them.
> Because subflow ssk is usually writable, we will have to undo-that
> if the mptcp sndbuf is exhausted.  This won't be needed anymore once
> __tcp_poll is removed, I am working on this.
> 
> Signed-off-by: Florian Westphal <fw(a)strlen.de>
> ---
>  net/mptcp/protocol.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 2144e80b8704..83be407e1dd6 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -406,6 +406,18 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
>  		return ret;
>  	}
>  
> +	timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
> +
> +	mptcp_clean_una(sk);
> +
> +	while (!sk_stream_memory_free(sk)) {
> +		ret = sk_stream_wait_memory(sk, &timeo);
> +		if (ret)
> +			goto out;
> +
> +		mptcp_clean_una(sk);
> +	}
> +

Can we move the above loop to the non fallback case only ? e.g. after
the below !mptcp_subflow_get(msk) checks?

If so, we could have a single loop checking for:

!sk_stream_memory_free(sk) || !mptcp_subflow_get_send()

(together with the next patch)

Cheers,

Paolo

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-11-18 18:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-18 12:11 [MPTCP] Re: [RFC 06/14] sendmsg: block until mptcp sk is writeable Florian Westphal
  -- strict thread matches above, loose matches on Subject: below --
2019-11-18 18:39 Mat Martineau
2019-11-18 12:19 Paolo Abeni
2019-11-18 11:33 Paolo Abeni
2019-11-18 11:29 Paolo Abeni

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.