On 6/17/19 8:53 PM, Christoph Paasch wrote:
> 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.
Also I want to point that normal skb split for not-yet transmitted skbs
does not use tcp_fragment(), with one exception (the one you hit)
Only the first skb in write queue can possibly have payload in skb->head
and might go through tcp_fragment()
Other splits will use tso_fragment() which does not enforce sk_wmem_queued
limits (yet)
So things like TLP should work.
