Subject: Re: [PATCH net-next v1 2/7] selftests/net: add MemPrvEnv env

From: Jakub Kicinski <[email-masked]>
Date: Fri, 21 Nov 2025 17:41:22 -0800

On Fri, 21 Nov 2025 09:14:49 -0800 David Wei wrote:
> 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.

🤔️ not sure

> Move the netns, netkit/veth setup, bpf forwarding using the new
> LOCAL_PREFIX env var etc into the env setup.

Yes to that, I think.

> Move the NIC queue stuff back out into helpers and call it from the
> test module.

Don't go too hard on the helpers, tho. "code reuse" is explicitly 
an anti-goal for selftests. I really don't want net/lib/py
to become a framework folks must learn to understand or debug tests.