> Subsequent acks will be quick acks, rather than delayed
> acks, as hoped. Or what am I missing here?
Clearing TCP_QUICKACKS you give to kernel hint that
bare ack can be delayed, because you are going to send some data soon
(for delack timeout).
If you break this contract or quick acking is required
by protocol, your advice is ignored being invalidated
by more strong and evident hints.
> (tp->write_pending || tp->defer_accept || !(tp->ack.pingpong))
> make more sense?
This does not make any sense at all. You propose to delay ACK _always_,
which will stall any connection except for http for delack timeout. :-)
> Is tp->ack.pingpong not intended to store the user choice
> of "dont/do quick ack"
It is not. It means the thing described above.