[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aa0af451-5e7c-7d83-ef25-095a67cd23a1@gmail.com>
Date: Mon, 17 Jun 2019 20:44:30 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Christoph Paasch <christoph.paasch@...il.com>,
Eric Dumazet <eric.dumazet@...il.com>
Cc: Eric Dumazet <edumazet@...gle.com>,
"David S . Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jonathan Looney <jtl@...flix.com>,
Neal Cardwell <ncardwell@...gle.com>,
Tyler Hicks <tyhicks@...onical.com>,
Yuchung Cheng <ycheng@...gle.com>,
Bruce Curtis <brucec@...flix.com>,
Jonathan Lemon <jonathan.lemon@...il.com>,
Dustin Marquess <dmarquess@...le.com>
Subject: Re: [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory
limits
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.
Really TCP can not work well with tiny sndbuf limits.
There is really no point trying to be nice.
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.
Powered by blists - more mailing lists