Re: [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits

On Mon, Jun 17, 2019 at 8:44 PM Eric Dumazet [off-list ref] wrote:

On 6/17/19 8:19 PM, Christoph Paasch wrote:

quoted

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.