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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.