Christoph Paasch <christoph.paa...@gmail.com> wrote: > tcp_rcv_space_adjust is called even when the app is not yet reading, > thus wouldn't this mean that we still end up with an ever-growing > window?
Window is based on available mptcp sk recvbuf. When data is moved from ssk to the mptcp sk, the skb truesize is charged to the mptcp rmem. > E.g., imagine an app that does not read at all at the beginning. The > call to tcp_rcv_space_adjust in patch 1/2 will make the subflow's > window grow. Now, the app comes and reads one byte. Then, the window > at MPTCP-level will jump regardless of how much the app actually read. Yes, the rcvbufsz value will jump, regardless homw much the app actually read. > I think what is needed is to size the MPTCP-level window to 2 x the > amount of data read by the application within an RTT (maximum RTT > among all the active subflows). That way if an app reads 1 byte a > second, the window will remain low. While for a bulk-transfer it will > allow all subflows to receive at full speed [1]. Sounds like the idea to move skbs to msk was bad one? Sorry, I don't see how I can make this work. Even deferring tcp_rcv_space_adjust() until recv() time won't work, given data has been pulled to the mptcp socket already. NOT calling tcp_rcv_space_adjust() at all might work, but that would require something else entirely. We would still have to adjust the subflow rcvbufsz in this case, else we may announce a window that is larger than the memory limit of the ssk (and we will end up dropping data at tcp level if the worker can't move the skbs fast enough). > Or do you think that kind of tuning can be done in a follow-up patch? This sounds completely different so I don't think that makes sense.
