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?
