From: Jakub Sitnicki <jakub@cloudflare.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netdev@vger.kernel.org, Willem de Bruijn <willemb@google.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
kernel-team@cloudflare.com
Subject: Re: [PATCH net-next] selftests: udpgso: Pull up network setup into shell script
Date: Wed, 31 Jan 2024 18:47:16 +0100 [thread overview]
Message-ID: <87zfwlv0sx.fsf@cloudflare.com> (raw)
In-Reply-To: <65b95b8b3e4d0_ce3aa29444@willemb.c.googlers.com.notmuch>
On Tue, Jan 30, 2024 at 03:26 PM -05, Willem de Bruijn wrote:
> Jakub Sitnicki wrote:
>> udpgso regression test configures routing and device MTU directly through
>> uAPI (Netlink, ioctl) to do its job. While there is nothing wrong with it,
>> it takes more effort than doing it from shell.
>>
>> Looking forward, we would like to extend the udpgso regression tests to
>> cover the EIO corner case [1], once it gets addressed. That will require a
>> dummy device and device feature manipulation to set it up. Which means more
>> Netlink code.
>>
>> So, in preparation, pull out network configuration into the shell script
>> part of the test, so it is easily extendable in the future.
>>
>> Also, because it now easy to setup routing, add a second local IPv6
>> address. Because the second address is not managed by the kernel, we can
>> "replace" the corresponding local route with a reduced-MTU one. This
>> unblocks the disabled "ipv6 connected" test case. Add a similar setup for
>> IPv4 for symmetry.
>
> Nice!
>
> Just a few small nits.
>
Thanks for quick feedback. Will apply it and respin.
>>
>> [1] https://lore.kernel.org/netdev/87jzqsld6q.fsf@cloudflare.com/
>>
>> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
>> ---
>> tools/testing/selftests/net/udpgso.c | 134 ++------------------------
>> tools/testing/selftests/net/udpgso.sh | 50 ++++++++--
>> 2 files changed, 48 insertions(+), 136 deletions(-)
>>
>> diff --git a/tools/testing/selftests/net/udpgso.c b/tools/testing/selftests/net/udpgso.c
>> index 7badaf215de2..79fd3287ff60 100644
>> --- a/tools/testing/selftests/net/udpgso.c
>> +++ b/tools/testing/selftests/net/udpgso.c
>> @@ -56,7 +56,6 @@ static bool cfg_do_msgmore;
>> static bool cfg_do_setsockopt;
>> static int cfg_specific_test_id = -1;
>>
>> -static const char cfg_ifname[] = "lo";
>> static unsigned short cfg_port = 9000;
>>
>> static char buf[ETH_MAX_MTU];
>> @@ -69,8 +68,13 @@ struct testcase {
>> int r_len_last; /* recv(): size of last non-mss dgram, if any */
>> };
>>
>> -const struct in6_addr addr6 = IN6ADDR_LOOPBACK_INIT;
>> -const struct in_addr addr4 = { .s_addr = __constant_htonl(INADDR_LOOPBACK + 2) };
>> +const struct in6_addr addr6 = {
>> + { { 0x20, 0x01, 0x0d, 0xb8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x00, 0x01 } },
>> +};
>> +
>> +const struct in_addr addr4 = {
>> + __constant_htonl(0xc0000201), /* 192.0.2.1 */
>> +};
>
> Prefer an address from a private range?
No preference. I saw both in use across net selftests and went with one.
[...]
>> diff --git a/tools/testing/selftests/net/udpgso.sh b/tools/testing/selftests/net/udpgso.sh
>> index fec24f584fe9..d7fb71e132bb 100755
>> --- a/tools/testing/selftests/net/udpgso.sh
>> +++ b/tools/testing/selftests/net/udpgso.sh
>> @@ -3,27 +3,57 @@
>> #
>> # Run a series of udpgso regression tests
>>
>> +set -o errexit
>> +set -o nounset
>> +# set -o xtrace
>
> Leftover debug comment?
>
Left it on purpose for the next person debugging it. But can remove it.
>> +
>> +setup_loopback() {
>> + ip addr add dev lo 192.0.2.1/32
>> + ip addr add dev lo 2001:db8::1/128 nodad noprefixroute
>> +}
>> +
>> +test_dev_mtu() {
>> + setup_loopback
>> + # Reduce loopback MTU
>> + ip link set dev lo mtu 1500
>> +}
>> +
>> +test_route_mtu() {
>> + setup_loopback
>> + # Remove default local routes
>> + ip route del local 192.0.2.1/32 table local dev lo
>> + ip route del local 2001:db8::1/128 table local dev lo
>> + # Install local routes with reduced MTU
>> + ip route add local 192.0.2.1/32 table local dev lo mtu 1500
>> + ip route add local 2001:db8::1/128 table local dev lo mtu 1500
>
> ip route change?
>
I've tried it. Doesn't work as expected. Only del+add seems do to
it. You end up with two routes if you use `ip route replace`:
# ip route replace local 2001:db8::1/128 table local dev lo mtu 1500
# ip -6 route show table local
local ::1 dev lo proto kernel metric 0 pref medium
local 2001:db8::1 dev lo proto kernel metric 0 pref medium
local 2001:db8::1 dev lo metric 1024 mtu 1500 pref medium
#
I didn't dig into why, though.
[...]
prev parent reply other threads:[~2024-01-31 18:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 13:14 [PATCH net-next] selftests: udpgso: Pull up network setup into shell script Jakub Sitnicki
2024-01-30 20:26 ` Willem de Bruijn
2024-01-31 17:47 ` Jakub Sitnicki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zfwlv0sx.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).