MIME-Version: 1.0
References: <6400bd699f568_20743e2082b@willemb.c.googlers.com.notmuch> <202303031900454292466@zte.com.cn>
In-Reply-To: <202303031900454292466@zte.com.cn>
From:   Eric Dumazet <edumazet@google.com>
Date:   Fri, 3 Mar 2023 12:27:26 +0100
Message-ID: <CANn89iK3frwxddhSbbi5cvmuSjr2TqPbD_mTgBa3k4ESDQnrHA@mail.gmail.com>
Subject: Re: [PATCH linux-next v2] selftests: net: udpgso_bench_tx: Add test
 for IP fragmentation of UDP packets
To:     yang.yang29@zte.com.cn
Cc:     willemdebruijn.kernel@gmail.com, davem@davemloft.net,
        kuba@kernel.org, pabeni@redhat.com, shuah@kernel.org,
        netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
        linux-kernel@vger.kernel.org, zhang.yunkai@zte.com.cn,
        xu.xin16@zte.com.cn, jiang.xuexin@zte.com.cn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Mar 3, 2023 at 12:03=E2=80=AFPM <yang.yang29@zte.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.