[EXTERNAL] [PATCH v7] examples: add Wycheproof validation app

[Ji, Kai]

I agree that a single validation framework would make cryptodev validation easier to discover, document, and maintain, and could eventually allow some common setup and reporting infrastructure to be shared.
That said, the overlap between the two applications is primarily at the cryptodev API level. Their core purposes are quite different. The FIPS validation application is focused on CAVP/ACVP workflows, including request/response processing and conformance testing, whereas Wycheproof is built around externally maintained JSON test suites with valid/invalid/acceptable result classifications and different requirements for asymmetric devices.
While there may be opportunities for code reuse in the future, merging them today would likely introduce additional dispatcher and lifecycle complexity with limited immediate benefit. It could also blur the distinction between Wycheproof robustness testing and FIPS conformance validation.
My preference would be to keep them as separate applications for now and revisit consolidation if we identify a meaningful amount of shared infrastructure.
Regards,

Kai


________________________________
From: Thomas Monjalon <thomas at monjalon.net>
Sent: Friday, September 25, 2026 17:32
To: Ji, Kai <kai.ji at intel.com>; Akhil Goyal <gakhil at marvell.com>
Cc: dev at dpdk.org <dev at dpdk.org>
Subject: Re: [EXTERNAL] [PATCH v7] examples: add Wycheproof validation app

24/09/2026 20:00, Akhil Goyal:
> > Wycheproof differs somewhat from the existing cryptodev test vectors in that it is
> > an externally maintained collection of JSON test suites covering a large number of
> > edge cases and negative tests. The intended usage model is to load the upstream
> > vector files at runtime rather than embedding them in the DPDK tree.
> > I think the existing examples/fips_validation application follows a similar
> > approach, consuming external CAVP/ACVP vector files rather than integrating
> > them into dpdk-test. This patch follows that precedent, with the goal of providing
> > file-driven conformance validation as a standalone example application.
> > I agree that the documentation can be improved. At minimum, the .rst should
> > describe where the Wycheproof vectors can be obtained and reference the
> > applicable upstream license, as the current example command may give the
> > impression that the vector files are included in the DPDK source tree when they
> > are not.
>
> Ok, so in that case did you consider integrating this app into fips_validation app..
> May be we could rename fips_validation to crypto_validation and internally have 2 modes -
> Fips and Wycheproof? Like what we have for examples/multi_process?

I like this proposal.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20260929/819c9e38/attachment-0001.htm>