Re: [RFC net 0/1] Fix netdevim to correctly mark NAPI IDs

[Joe Damato]

On Tue, Apr 15, 2025 at 06:39:27PM -0700, Joe Damato wrote:
> On Tue, Apr 15, 2025 at 05:11:54PM -0700, Jakub Kicinski wrote:
> > On Tue, 15 Apr 2025 12:39:11 -0700 Joe Damato wrote:
> > > On Mon, Mar 31, 2025 at 04:39:17PM -0700, Jakub Kicinski wrote:
> > > > Up to you. The patch make me wonder how many other corner cases / bugs
> > > > we may be missing in drivers. And therefore if we shouldn't flesh out
> > > > more device-related tests. But exercising the core code makes sense
> > > > in itself so no strong feelings.  
> > > 
> > > Sorry to revive this old thread, but I have a bit of time to get
> > > this fixed now. I have a patch for netdevsim but am trying to figure
> > > out what the best way to write a test for this is.
> > > 
> > > Locally, I've hacked up a tools/testing/selftests/drivers/net/napi_id.py
> > > 
> > > I'm using NetDrvEpEnv, but am not sure: is there an easy way in
> > > Python to run stuff in a network namespace? Is there an example I
> > > can look at?
> > > 
> > > In my Python code, I was thinking that I'd call fork and have each
> > > python process (client and server) set their network namespace
> > > according to the NetDrvEpEnv cfg... but wasn't sure if there was a
> > > better/easier way ?
> > > 
> > > It looks like tools/testing/selftests/net/rds/test.py uses
> > > LoadLibrary to call setns before creating a socket.
> > > 
> > > Should I go in that direction too?
> > 
> > Why do you need a netns? The NetDrvEpEnv will create one for you
> > automatically and put one side of the netdevsim into it.
> > Do you mean that you need to adjust that other endpoint?
> > It's done the same way as if it was a remote machine:
> > 
> > 	cmd(..., host=cfg.remote)
> 
> Maybe I'm just thinking about it wrong and/or describing it poorly.
> 
> The idea was that napi_id.py test forks. One process does a
> listen()/accept() and the other does a connect(). The accept side
> checks that the napi ID is non-zero. For that to work, both
> processes need their netdevsims to be able to talk to each other.

In retrospect, it's probably easier to just have the connect() side
be socat or something run in the background, like the ncdevmem test.

Sorry for the noise, I'll mess around a bit more.