lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 Apr 2016 20:36:56 -0400 (EDT) From: David Miller <davem@...emloft.net> To: edumazet@...gle.com Cc: netdev@...r.kernel.org, ncardwell@...gle.com, ycheng@...gle.com, eric.dumazet@...il.com Subject: Re: [PATCH net-next] tcp-tso: do not split TSO packets at retransmit time From: Eric Dumazet <edumazet@...gle.com> Date: Mon, 18 Apr 2016 13:56:12 -0700 > 1 % packet losses are common today, and at 100Gbit speeds, this > translates to ~80,000 losses per second. If we are unlucky and > first MSS of a 45-MSS TSO is lost, we are cooking 44 MSS segments > at rtx instead of a single 44-MSS TSO packet. I'm having trouble understanding this. If the first mss is lost, then we simply chop the 45 MSS TSO skb into two pieces. The first piece is a 1 MSS chunk for the retransmit, and the second piece is remaining 44 MSS TSO skb. I am pretty sure that is what the current stack does, and regardless it is certainly what I intended it to do all those years ago when I wrote this code. :-) The only case where I can see this patch helping is when we have to retransmit multi-mss chunks. And yes indeed, it might be a useful optimization to TSO those frames rather than sending them one MSS at a time.
Powered by blists - more mailing lists