Re: [PATCH net-next RFC] selftests: net: add netpoll basic functionality test

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Breno Leitao wrote:
> Hello Willem,
> 
> On Thu, Jun 12, 2025 at 10:35:54PM -0400, Willem de Bruijn wrote:
> > Breno Leitao wrote:
> > > Add a basic selftest for the netpoll polling mechanism, specifically
> > > targeting the netpoll poll() side.
> > > 
> > > The test creates a scenario where network transmission is running at
> > > maximum sppend, and netpoll needs to poll the NIC. This is achieved by:
> > 
> > minor type: sppend/speed
> 
> Thanks! I will update.
> 
> > >   1. Configuring a single RX/TX queue to create contention
> > >   2. Generating background traffic to saturate the interface
> > >   3. Sending netconsole messages to trigger netpoll polling
> > >   4. Using dynamic netconsole targets via configfs
> > > 
> > > The test validates a critical netpoll code path by monitoring traffic
> > > flow and ensuring netpoll_poll_dev() is called when the normal TX path
> > > is blocked. Perf probing confirms this test successfully triggers
> > > netpoll_poll_dev() in typical test runs.
> > 
> > So the test needs profiling to make it a pass/fail regression test?
> > Then perhaps add it to TEST_FILES rather than TEST_PROGS. Unless
> > exercising the code on its own is valuable enough.
> 
> Sorry for not being clear. This test doesn't depend on any profiling
> data. Basically I just run `perf probe` to guarantee that
> netpoll_poll_dev() was being called (as that was the goal of the test).
> 
> This test is self contained and should run at `make run_test` targets.
> 
> > Or is there another way that the packets could be observed, e.g.,
> > counters.
> 
> Unfortunately netpoll doesn't expose any data, thus, it is hard to get
> it. 
> 
> I have plans to create a configfs for netpoll, so, we can check for
> these numbers (as also configure some pre-defined values today, such as
> USEC_PER_POLL, MAX_SKBS, ip6h->version = 6; ip6h->priority = 0, etc.
> 
> In fact, I've an private PoC for this, but, I am modernizing the code
> first, and creating some selftests to help me with those changes later
> (given we have very little test on netpoll, and I aim to improve this,
> given how critical it is for some datacenter designs).
> 
> > > +NETCONSOLE_CONFIGFS_PATH = "/sys/kernel/config/netconsole"
> > > +REMOTE_PORT = 6666
> > > +LOCAL_PORT = 1514
> > > +# Number of netcons messages to send. I usually see netpoll_poll_dev()
> > > +# being called at least once in 10 iterations.
> > > +ITERATIONS = 10
> > 
> > Is usually sufficient to avoid flakiness, or should this be cranked
> > up?
> 
> 10 was the minimum number I was able to trigger it on my dev
> environment, either with default configuration and a debug heavy
> configuration, but, the higher the number, more change to trigger it.
> I can crank up it a bit more. Maybe 20?
> 
> > > +def check_traffic_flowing(cfg: NetDrvEpEnv, netdevnl: NetdevFamily) -> int:
> > > +    """Check if traffic is flowing on the interface"""
> > > +    stat1 = get_stats(cfg, netdevnl)
> > > +    time.sleep(1)
> > 
> > Can the same be learned with sufficient precision when sleeping
> > for only 100 msec? As tests are added, it's worth trying to keep
> > their runtime short.
> 
> 100%. In fact, I don't need to wait for 1 seconds. In fact, we don't
> even need to check for traffic flowing after the traffic started. I've
> just added it to help me do develop the test.
> 
> We can either reduce it to 100ms or just remove it from the loop,
> without prejudice to the test itself. Maybe reducing it to 100 ms might
> help someone else that might debug this in the future, while just
> slowing down ITERATIONS * 0.1 seconds !?

That makes sense. Or only keep it in DEBUG mode?