On Mon, Aug 13, 2001 at 11:55:31PM -0700, Nivedita Singhvi wrote: > If the client has disabled TCP_QUICKACKS via setsockopt() > on this socket (i.e. tp->ack.pingpong = 1), we'll fall > through to this code when completing the 3 way handshake > from TCP_SYN_SENT state. However, tcp_enter_quickack_mode(tp) > unconditionally resets tp->ack.pingpong to 0, of course. > Subsequent acks will be quick acks, rather than delayed > acks, as hoped. Or what am I missing here? The quickack should be only send on the next incoming packet, which is effectively the delayed ack needed. > Is tp->ack.pingpong not intended to store the user choice > of "dont/do quick ack" as set by TCP_QUICKACKS? We reset > it (pingpong) when we receive data that fills our > out of order queue, or receive out of order/window or retransmitted > data, so it doesnt seem to be the case.. I think TCP_QUICKACKS was an afterthought which never completely worked. The real purpose of pingpong is to safe the state of the pingping heuristic. Best would be probably to either remove TCP_QUICKACKS or make it a separate flag. > Any clarification here would be appreciated! > > On an unconnected note, why are there 2 mailing lists, linux-net > and netdev? Is one deprecated, or preferred? linux-net has been historically been more user support oriented and included non kernel things, while netdev is strictly aimed at kernel development stuff only. These days linux-net traffic is so low (it used to have much more "support" traffic) that it doesn't make much difference anymore; but it is probably still a good idea to e.g. send patches to netdev instead of linux-net. -Andi - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
