[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1cfe74a1-092c-406b-9fe5-e1206aedb473@davidwei.uk>
Date: Fri, 21 Nov 2025 09:14:49 -0800
From: David Wei <dw@...idwei.uk>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH net-next v1 2/7] selftests/net: add MemPrvEnv env
On 2025-11-20 19:18, Jakub Kicinski wrote:
> On Wed, 19 Nov 2025 19:30:11 -0800 David Wei wrote:
>> Memory provider HW selftests (i.e. zcrx, devmem) require setting up a
>> netdev with e.g. flow steering rules. Add a new MemPrvEnv that sets up
>> the test env, restoring it to the original state prior to the test. This
>> also speeds up tests since each individual test case don't need to
>> repeat the setup/teardown.
>
> Hm, this feels a bit too specific to the particular use case.
> I think we have a gap in terms of the Env classes for setting up
> "a container" tests. Meaning - NetDrvEpEnv + an extra NetNs with
> a netkit / veth. init net gets set up to forward traffic to and
> from the netkit / veth with BPF or routing. And the container
> needs its own IP address from a new set of params.
>
> I think that's the extent of the setup provided by the env.
> We can then reuse the env for all "container+offload" cases.
> The rest belongs in each test module.
Got it. You'd like me to basically reverse the current env setup. Move
the netns, netkit/veth setup, bpf forwarding using the new LOCAL_PREFIX
env var etc into the env setup. Move the NIC queue stuff back out into
helpers and call it from the test module.
Powered by blists - more mailing lists