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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cbf20bde-74f8-41d1-a259-37c5d29a194d@davidwei.uk>
Date: Fri, 21 Nov 2025 18:24:24 -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-21 17:41, Jakub Kicinski wrote:
> 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.

Okay, understood. I'll use helpers judiciously.