On Mon, Jun 17, 2019 at 8:44 PM Eric Dumazet <eric.duma...@gmail.com> wrote: > > > > On 6/17/19 8:19 PM, Christoph Paasch wrote: > > > > Yes, this does the trick for my packetdrill-test. > > > > I wonder, is there a way we could end up in a situation where we can't > > retransmit anymore? > > For example, sk_wmem_queued has grown so much that the new test fails. > > Then, if we legitimately need to fragment in __tcp_retransmit_skb() we > > won't be able to do so. So we will never retransmit. And if no ACK > > comes back in to make some room we are stuck, no? > > Well, RTO will eventually fire.
But even the RTO would have to go through __tcp_retransmit_skb(), and let's say the MTU of the interface changed and thus we need to fragment. tcp_fragment() would keep on failing then, no? Sure, eventually we will ETIMEOUT but that's a long way to go. > Really TCP can not work well with tiny sndbuf limits. > > There is really no point trying to be nice. Sure, fair enough :-) Christoph > > There is precedent in TCP stack where we always allow one packet in RX or TX > queue > even with tiny rcv/sndbuf limits (or global memory pressure) > > We only need to make sure to allow having at least one packet in rtx queue as > well.
