Re: [PATCH v2 mptcp-next 3/4] mptcp: add SIOCINQ, OUTQ and OUTQNSD ioctls

[Florian Westphal <fw@strlen.de>]

Mat Martineau <mathew.j.martineau@linux.intel.com> wrote:
> > +		lock_sock(sk);
> > +		if (skb_queue_empty(&msk->receive_queue))
> 
> I'm guessing that the idea here is that answering with a nonzero value is
> enough to get the userspace program to do another read, rather than always
> imposing overhead to dig through the subflow rx buffers and
> sk->sk_receive_queue? That does seem like a good way to go, at least with
> regard to calling __mptcp_move_skbs().
> 
> Would it be useful to check sk->sk_receive_queue and splice if non-empty
> (which is relatively cheap) to get a slightly more accurate inq number? To
> maybe answer this question for myself - the socket lock was just acquired so
> it's unlikely for skbs to have been added to sk_receive_queue, and the extra
> complexity may not be worth it.

The idea was to avoid a bogus '0' answer; msk rx queue might be empty
but sk_rx q might have new data.

I can make the __mptcp_move_skbs() unconditional, as you said we already
acquired the msk socket lock so might as well splice pending subflows
and so on.