<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Yong, Thanks for your feedback. <o:p> </o:p> <o:p> </o:p> All-in-one configuration file just a thought that we could combine crb.cfg/port.cfg/pktgen.cfg/ixia.cfg configuration files. Generally, users have to change these configurations for a specific test bed. For making easy use, let users are able to change those information at one place. YAML is similar to current cfg format. Basically, it will not replace current configurations, just add an option for users.<o:p></o:p> <o:p> </o:p> “Global resource management”, yes we will consider all dependencies. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> /Zhaoyan<o:p></o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Liu, Yong Sent: Wednesday, July 24, 2019 11:17 AM To: Chen, Zhaoyan <zhaoyan.chen@intel.com>; dts@dpdk.org Cc: Chen, Zhaoyan <zhaoyan.chen@intel.com> Subject: RE: DTS Enhancement Plan<o:p></o:p> </div> </div> <o:p> </o:p> Hi Zhaoyan,<o:p></o:p> This is great overall idea. It will be nice to see the roadmap of DTS enhancement work, since all works can’t be done in one dayJ<o:p></o:p> <o:p> </o:p> One comment for “All-in-one configuration file”. It is nice at first glance, but configuration file may will be too huge for reading and modification after add things continuously. <o:p></o:p> And json format has been supported in DTS, is there any special reason for replacing it?<o:p></o:p> <o:p> </o:p> In my mind “Global resource management” will manage all the resources for test cases. We also need to add test binary into consideration, as it is also shared between suites.<o:p></o:p> <o:p> </o:p> Regards,<o:p></o:p> Marvin<o:p></o:p> <o:p> </o:p> <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <a name="_____replyseparator"></a>From: dts [<a href="mailto:dts-bounces@dpdk.org">mailto:dts-bounces@dpdk.org</a>] On Behalf Of Chen, Zhaoyan Sent: Wednesday, July 24, 2019 10:52 AM To: <a href="mailto:dts@dpdk.org">dts@dpdk.org</a> Cc: Chen, Zhaoyan <<a href="mailto:zhaoyan.chen@intel.com">zhaoyan.chen@intel.com</a>> Subject: [dts] DTS Enhancement Plan<o:p></o:p> </div> </div> <o:p> </o:p> Hi, DTS developers/users,<o:p></o:p> <o:p> </o:p> With DPDK development rapidly, more and more test suites were developed in DTS. (150+ test suites and 3k+ test cases in DTS). Meanwhile, paralleling execution tests for NICs/crypto/other device on same DUT become important for reducing execution time for covering all test cases. So we plan to enhance the DTS, for<o:p></o:p> <![if !supportLists]>· <![endif]>Improve test suite quality <o:p></o:p> <![if !supportLists]>· <![endif]>Unified test capability/function into framework<o:p></o:p> <![if !supportLists]>· <![endif]>Paralleling execution<o:p></o:p> <o:p> </o:p> So we draft a DTS development plan, and share with you. <o:p> </o:p> <o:p> </o:p> Looking forward to hear your thoughts, ideas and suggestions. <o:p></o:p> <o:p> </o:p> /Zhaoyan<o:p></o:p> <o:p> </o:p> DTS framework enhancement<o:p></o:p> =========================<o:p></o:p> <o:p> </o:p> Unified packet sending for functionality test<o:p></o:p> * Implement all packet sending features in Packet Class<o:p></o:p> * Remove others sending functions in DTS framework<o:p></o:p> * Sending packet from Tester only<o:p></o:p> <o:p> </o:p> Generic EAL options generator for DPDK based application<o:p></o:p> * Generate EAL options for DPDK app, and consider the assigned hardware resource for test, instead of whole DUT<o:p></o:p> * Test suite can overwrite the options, in restricted range<o:p></o:p> * Define hardware resource in crb.cfg, port.cfg and pktgen.cfg<o:p></o:p> <o:p> </o:p> Global resource management<o:p></o:p> * Global driver load or unload, vfio-pci, igb_uio, uio_pci_generic<o:p></o:p> * Define a parameter to decside if insmod/rmmod, if the module updated. otherwise, keep this module on host.<o:p></o:p> * External_memory setup<o:p></o:p> * Define DUT's cores mask in crb configuration<o:p></o:p> * Define DUT's ports mask<o:p></o:p> * Define physical ports in crb config<o:p></o:p> <o:p> </o:p> Clean up unused APIs, unused imported libraries, and unused APIs<o:p></o:p> * plotting.py, plotgraph.py, numpy, matplotlib<o:p></o:p> * e.g. self.tester.run_rfc2544, has been replaced by pktgen class<o:p></o:p> * Replace private texttable.py with public version<o:p></o:p> <o:p> </o:p> All-in-one configuration file<o:p></o:p> * Support configure all information in one configuration file for easy using<o:p></o:p> * yaml file is better<o:p></o:p> <o:p> </o:p> Prepare to move to Python 3, make code be compatible with py2 and py3<o:p></o:p> <o:p> </o:p> Generate auto-script for all DTS dependencies<o:p></o:p> * Update requirements.txt<o:p></o:p> * Generate script for binary dependencies for compilation python packages<o:p></o:p> <o:p> </o:p> Release DTS container version<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Test Suites cleanness<o:p></o:p> =================<o:p></o:p> <o:p> </o:p> Move to new packet sending API<o:p></o:p> * Update all tests, which generate packets and send packets<o:p></o:p> <o:p> </o:p> Move to generic EAL generator API<o:p></o:p> * Update all tests which use DPDK based application with new EAL string<o:p></o:p> <o:p> </o:p> Clean up "sleep"<o:p></o:p> * Replace "sleep" with a stable checking mechanism <o:p></o:p> <o:p> </o:p> Replace "pktgen app" with "testpmd app" for testing<o:p></o:p> * pktgen app needs be built for special DPDK version and too heavy for a simple function test, replace it in test case with testpmd app<o:p></o:p> <o:p> </o:p> Clean up absolute path<o:p></o:p> * Replace "/tmp" with "/tmp/<dts_pid_random>/", or relative path "tmp". <o:p></o:p> * Replace specific OS path in test case<o:p></o:p> <o:p> </o:p> Clean up test case dependencies, (files, libraries or tools)<o:p></o:p> * Check all test suites, and add dependencies into auto-script or requirements.txt<o:p></o:p> <o:p> </o:p> </div> </div> </body> </html>