+CC: DTS mailing list. > From: David Marchand [mailto:david.march...@redhat.com] > Sent: Thursday, 6 October 2022 09.05 > > On Thu, Oct 6, 2022 at 8:53 AM Morten Brørup <m...@smartsharesystems.com> > wrote:
[...] > > Forgive me, if I am sidetracking a bit here... The issue discussed > seems to be related to some threads waiting for other threads, and my > question is not directly related to that. > > > > I have been wondering how accurate the tests really are. Where can I > see what is being done to ensure that the EAL worker threads are fully > isolated, and never interrupted by the O/S scheduler or similar? > > > > For reference, the max packet rate at 40 Gbit/s is 59.52 M pkt/s. If > a NIC is configured with 4096 Rx descriptors, packet loss will occur > after ca. 70 us (microseconds!) if not servicing the ingress queue when > receiving at max packet rate. > > > > I recently posted some code for monitoring the O/S noise in EAL > worker threads [1]. What should I do if I want to run that code in the > automated test environment? It would be for informational purposes > only, i.e. I would manually look at the test output to see the result. > > > > I would write a test application that simply starts the O/S noise > monitor thread as an isolated EAL worker thread, the main thread would > then wait for 10 minutes (or some other duration), dump the result to > the standard output, and exit the application. > > > > [1]: > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87352@smarts > erver.smartshare.dk/ > > Maybe we could do some hack, like finding a test in the current CI > that matches the test requirement: number of cores, ports, setup > params etc... (retrieving the output could be another challenge). > But if you think this is something we should have on the long run, I'd > suggest writing a new DTS test. It would be useful having in the long run - it could catch sudden anomalies in the test environment. Where can I find documentation on how to add a new test case to DTS? -Morten
