Compressdev Testing

[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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/ci/attachments/20260805/79620c72/attachment.htm>