Re: [MPTCP] [PATCH] Revert tcp_skb_cb to it's original size and cleanup main TCP Rx code from MPTCP specific code.

Hi Christoph, On 06/27/2017 09:53 PM, Christoph Paasch wrote: > > There are several reasons why such a packet might not make it up to the > receive-queue. For example: > > * tcp_receive_window() returns 0 > * the sequence-number of the ack-packet is not the rcv_nxt. Then it goes > into the ofo-queue. Which is why we had to add tests for mptcp() in > tcp_data_queue_ofo() to handle DATA_FINs. > * tcp_try_rmem_schedule() returns false > > Such kind of conditions will make that the signal from the peer (DATA_ACK, > ADD_ADDR,...) does not reach the MPTCP-stack. But these signals should be > delivered to the stack as reliably as possible. > > > What if we rather use the error-queue for these signalling skbs? The > error-queue has already been "abused" for tx-timestamps,... so this might be > a good place to put this information. I think that would be cleaner. > > > Christoph > Thanks for elaborating. Now I understand. Your concern is not the zero length but the general constraints with queuing. Yes, the current implementation does not bypass those constraints. It treats pure ack as a zero length data packet. If this is an issue with MPTCP the fix is very straight forward, in fact I want to make that change, In tcp_data_queue() where we check if the packet is a pure ack and make decision to deliver it if the socket is an MPTCP we can just call sk_data_ready . An architecturally correct solution would be to have a another socket specific function to deal with non data packets and remove checks for mptcp.

The goal is to (When possible) not do any MPTCP parsing/processing till TCP processing is done and the packet is handed off to MPTCP. This makes the code look cleaner and less intrusive. Which is the biggest complain that the upstream folks have. They are not concerned what we do in the MPTCP code.