[MPTCP] Re: [RFC mptcp-next 2/3] mptcp: rework poll+nospace handling

[Florian Westphal <fw at strlen.de>]

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

Paolo Abeni <pabeni(a)redhat.com> wrote:
> On Sun, 2020-09-06 at 17:58 +0200, Paolo Abeni wrote:
> > On Sat, 2020-09-05 at 12:33 +0200, Florian Westphal wrote:
> > > +static __poll_t mptcp_check_writeable(struct mptcp_sock *msk)
> > > +{
> > > +	struct sock *sk = (struct sock *)msk;
> > > +	__poll_t ret = 0;
> > > +	bool slow;
> > > +
> > > +	if (sk->sk_shutdown & SEND_SHUTDOWN)
> > > +		return 0;
> > > +
> > > +	slow = lock_sock_fast(sk);
> > > +	if (__mptcp_check_writeable(msk))
> > > +		ret = EPOLLOUT | EPOLLWRNORM;
> > > +
> > > +	unlock_sock_fast(sk, slow);
> > 
> > It's a pity we need to acquire the lock in mptcp_poll()... perhaps we
> > could try to acquire it only if sk_stream_is_writeable(msk)?
> 
> I'm also wondering if checking sk_stream_is_writeable(msk) could be
> enough??? perhaps with a different sndbuf auto-tuning strategy. 

Not right now.  But perhaps this is worth exploring -- we would need
to change mptcp_sendmsg to append data to the rtx queue in case no ssk
can be found.

I'd give this a try unless you or anyone else has objections.

> e.g. if msk sndbuf <= max (ssk sndbuf), I *think*
> that sk_stream_is_writeable(msk) implies at least a ssk is writeable,
> too

You mean mptcp_is_writeable()?
[ Question above still stands though ]