Eric Dumazet wrote:
> On Fri, Mar 3, 2023 at 12:03 PM <yang.yang29@xxxxxxxxxx> 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.
My points was not to compare IP_PMTUDISC_OMIT to .._DONT but to .._DO,
which is what the existing UDP GSO test is setting.
USO should generate segments that meet MTU rules. The test forces
the DF bit (IP_PMTUDISC_DO).
UFO instead requires local fragmentation, must enter the path for this
in ip_output.c. It should fail if IP_PMTUDISC_DO is set:
/* Unless user demanded real pmtu discovery (IP_PMTUDISC_DO), we allow
* to fragment the frame generated here. No matter, what transforms
* how transforms change size of the packet, it will come out.
*/
skb->ignore_df = ip_sk_ignore_df(sk);
/* DF bit is set when we want to see DF on outgoing frames.
* If ignore_df is set too, we still allow to fragment this frame
* locally. */
if (inet->pmtudisc == IP_PMTUDISC_DO ||
inet->pmtudisc == IP_PMTUDISC_PROBE ||
(skb->len <= dst_mtu(&rt->dst) &&
ip_dont_fragment(sk, &rt->dst)))
df = htons(IP_DF);
> >
> > 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,
Are you saying no process will use UDP_SEGMENT?
The local protocol stack removed UFO in series d9d30adf5677.
USO can be offloaded to hardware by quite a few devices (NETIF_F_GSO_UDP_L4).
> > 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.
