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: Fri, 3 Mar 2023 12:27:26 +0100 From: Eric Dumazet <edumazet@...gle.com> To: yang.yang29@....com.cn Cc: willemdebruijn.kernel@...il.com, davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, shuah@...nel.org, netdev@...r.kernel.org, linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org, zhang.yunkai@....com.cn, xu.xin16@....com.cn, jiang.xuexin@....com.cn Subject: Re: [PATCH linux-next v2] selftests: net: udpgso_bench_tx: Add test for IP fragmentation of UDP packets On Fri, Mar 3, 2023 at 12:03 PM <yang.yang29@....com.cn> wrote: > > > Did you actually observe a difference in behavior with this change? > > The test of UDP only cares about sending, and does not much need to > consider the problem of PMTU, we configure it to IP_PMTUDISC_DONT. > IP_PMTUDISC_DONT: turn off pmtu detection. > IP_PMTUDISC_OMIT: the same as DONT, but in some scenarios, DF will > be ignored. I did not construct such a scene, presumably when forwarding. > Any way, in this test, is the same as DONT. > > We have a question, what is the point of this test if it is not compared to > UDP GSO and IP fragmentation. No user or tool will segment in user mode, > UDP GSO should compare performance with IP fragmentation. I think it is misleading to think the cost of IP fragmentation matters at the sender side. Major issue is the receiving side, with many implications of memory and cpu costs, not counting amplifications of potential packet losses. So your patch would make sense if you also change tools/testing/selftests/net/udpgso_bench_rx.c accordingly. If you send UDP packets to a receiver, then you should not receive ICMP errors, unless a reassembly error occured. About ICMP packets being disruptive, you can always ignore errors at sendmsg() time and retry the syscall.
Powered by blists - more mailing lists