I was more interested from a server point of view. After looking into
the code some more i found that tcp_listen_start() is calling
tcp_delack_init() which is zeroing the tp->ack structure that includes
the pingpong field.
A workaround for this problem is to call TCP_QUICKACK setsockopt() after
the call to listen().
There may be some issues with the code that nivedita listed.
* tcp_incr_quickack() gets called twice.(tcp_enter_quickack_mode() also
calls this routine)
* we enter quickack mode and reset pingpong even when user has
disabled quickacks by setting pingpong to 1.
* Can this code be replaced with a simple call to tcp_ack_snd_check()?
Thanks
Sridhar
On Mon, 13 Aug 2001, Nivedita Singhvi wrote:
> > After the 3-way handshake is completed, i am interested in getting
> > the ack for the first request to be delayed so that it can be
> > piggybacked with the response.
> >
> > I expected that setsockopt() TCP_QUICKACK option with a value of
> > 0 will disable quickacks.
> > This should set tp->ack.pingpong to 1 and cause the ack to be delayed.
> > But looks like somehow pingpong value is reset to 0 and the ack is sent
> > immediately. What is the reason for this behaviour?
> >
> > I noticed a couple of places where pingpong can be reset to 0, for ex.
> > while sending a dupack or retransmission. But i am not sure why it is
> > being reset to 0 at such an early stage of the connection.
> >
> > Thanks
> > Sridhar
>
> In tcp_rcv_synsent_state_process(), we have the following code:
>
> if (tp->write_pending || tp->defer_accept || tp->ack.pingpong) {
> /* Save one ACK. Data will be ready after
> * several ticks, if write_pending is set.
> *
> * It may be deleted, but with this feature tcpdumps
> * look so _wonderfully_ clever, that I was not able
> * to stand against the temptation 8) --ANK
> */
> tcp_schedule_ack(tp);
> tp->ack.lrcvtime = tcp_time_stamp;
> tp->ack.ato = TCP_ATO_MIN;
> tcp_incr_quickack(tp);
> tcp_enter_quickack_mode(tp);
> tcp_reset_xmit_timer(sk,TCP_TIME_DACK, TCP_DELACK_MAX);
> discard:
> __kfree_skb(skb);
> return 0;
>
> 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?
>
> Does
> (tp->write_pending || tp->defer_accept || !(tp->ack.pingpong))
>
> make more sense? What was intended here?
>
> 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..
>
> 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?
>
> thanks,
> Nivedita
>
>
>
-
: 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
