On Tue, Jan 2, 2018 at 2:43 AM, Steve Ibanez <siba...@stanford.edu> wrote: > Hi Neal, > > Apologies for the delay, and happy new year! > > To answer your question, data is only transferred in one direction > (from the client to the server). The SeqNo in the pkts from the server > to the client is not incremented. So I don't think that a data pkt is > attempted to be sent in the tcp_data_snd_check() call clearing the > ICSK_ACK_SCHED bit. Although I think it would be helpful to include > your new debugging field in the tcp_sock (tp->processing_cwr) so that > I can check this field in the tcp_transmit_skb() and tcp_send_ack() > functions. I added the new field and tried to set it at the top of the > tcp_rcv_established(), but then when I try to check the field in the > tcp_send_ack() function it never appears to be set. Below I'm showing > how I set the tp->processing_cwr field in the tcp_rcv_established > function and how I check it in the tcp_send_ack function. Is this how > you were imagining the processing_cwr field to be used?
Happy new year to you as well, and thank you, Steve, for running this experiment! Yes, this is basically the kind of thing I had in mind. The connection will run the "fast path" tcp_rcv_established() code if the connection is in the ESTABLISHED state. From the symptoms it sounds like what's happening is that in this test the connection is not in the ESTABLISHED state when the CWR arrives, so it's probably running the more general tcp_rcv_state_process() function. I would suggest adding your tp->processing_cwr instrumentation at the top of tcp_rcv_state_process() as well, and then re-running the test. (In tcp_v4_do_rcv() and tcp_v6_do_rcv(), for each incoming skb one of those two functions is called). It is interesting that the connection does not seem to be in the ESTABLISHED state. Maybe that is an ingredient of the unexpected behavior in this case... Thanks! neal
