Compressdev Testing

[Thomas Monjalon]

I agree compressdev testing may be skipped.
If one day someone wants it, the legacy DTS files will be still there for inspiration.


06/08/2026 00:22, Patrick Robb:
> I recollect Thomas saying that there was very little current development on
> compressdev.
> 
> My suggestion is to immediately discontinue running compressdev testing if
> that allows you to completely discontinue usage of legacy DTS in UNH. Some
> related thoughts:
> 
> 1. I don't think there is a maintainer who is watching the compressdev test
> results. Maintainers please let me know if this is not true.
> 2. We should move away from "port over to new DTS" thinking and more
> towards "defining new testplans with the DPDK community." Porting is great
> for some tests (mainly very core functionality) where the old testplans are
> still valid, but for other testplans they may no longer be valid, or may be
> improved upon. Instead of porting over the old compressdev testsuite just
> because it exists and we were running it, better to just move on from it
> and define a new testplan with collaboration from compressdev maintainers
> and devs as needed (and it probably won't be needed). Yes it is extra work
> to conceptualize the new test plans and UNH cannot do all the work on their
> own. Maintainer collaboration is required for writing test plans where UNH
> students do not have expertise. Akhil helped answer a bunch of Andrew's
> questions for writing a compressdev testplan... we need to create more
> situations like that on the UNH side.
> 3. I suppose the main issue with the above is maintainers are busy and what
> is the incentive to help write testplans? I guess the benefits are
> non-immediate and maybe not very tangible. Everyone has to justify their
> time spent on FOSS contributions to their manager at the end of the day,
> hah. This is part of why I recommend UNH Community Lab produce some sort of
> test report using DTS on a per release basis (or even just LTS releases)
> which could be distributed direct out to participating companies (like 1
> report per gold member company who have hardware at UNH). Or, maybe
> something else, but I think we need to produce some sort of artifact that
> will drum up interest in the test results. We have a test framework ready
> for adding new suites, and are running tests across new patches as they
> come in. But, are the existing failures which DTS catches getting seen and
> addressed by engineering teams at participating companies? In many cases I
> think the answer is no.
> 
> 
> 
> On Thu, Jul 23, 2026 at 11:40 AM Lincoln Lavoie <lylavoie at iol.unh.edu>
> wrote:
> 
> > Hello All,
> >
> > WIth the 26.7 release, nearly all of the existing testing run through DTS
> > by the UNH-IOL Community Lab has been migrated over to the new DTS
> > framework that is included directly into the dpdk code base.  The full list
> > of test suites that have been migrated over to the new codebase is below.
> >
> > A last remaining test suite is the compressdev testing that is currently
> > running using the legacy DTS code base.
> >
> > The open question is, can the UNH-IOL community lab discontinue
> > running the compressdev testing, which would complete our migration away
> > from using the legacy DTS codebase?
> >
> > Of course, either the compressdev community maintainers or UNH could also
> > work to port the compressdev test suite to the new DTS framework, if the
> > community feels that migration is important.  At that time, the testing can
> > easily be re-enabled in the UNH community lab.
> >
> > Test Suite in the new DTS framework:
> > TestSuite_blocklist.py
> > TestSuite_buffer_scatter.py
> > TestSuite_checksum_offload.py
> > TestSuite_cryptodev_latency.py
> > TestSuite_cryptodev_throughput.py
> > TestSuite_dual_vlan.py
> > TestSuite_dynamic_config.py
> > TestSuite_dynamic_queue_conf.py
> > TestSuite_flow_offload.py
> > TestSuite_hello_world.py
> > TestSuite_l2fwd.py
> > TestSuite_mac_filter.py
> > TestSuite_mtu.py
> > TestSuite_packet_capture.py
> > TestSuite_port_control.py
> > TestSuite_port_restart_config_persistency.py
> > TestSuite_port_stats.py
> > TestSuite_promisc_support.py
> > TestSuite_qinq.py
> > TestSuite_queue_toggle.py
> > TestSuite_rss.py
> > TestSuite_rx_split.py
> > TestSuite_rx_tx_offload.py
> > TestSuite_single_core_forward_perf.py
> > TestSuite_smoke_tests.py
> > TestSuite_softnic.py
> > TestSuite_speed_capabilities.py
> > TestSuite_unified_packet.py
> > TestSuite_virtio_forward.py
> > TestSuite_vlan.py
> >
> > --
> > *Lincoln Lavoie*
> > Principal Engineer, Broadband Technologies
> > 21 Madbury Rd., Ste. 100, Durham, NH 03824
> > lylavoie at iol.unh.edu
> > https://www.iol.unh.edu
> > +1-603-674-2755 (m)
> >
> >
>