<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="text-align: left; text-indent: 0px; line-height: 20px; margin: 1em 0px; font-family: "IntelOne Text"; font-size: 10pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="line-height: 20px; margin-top: 1em; margin-bottom: 1em; font-family: "IntelOne Text"; font-size: 10pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="line-height: 20px; margin-top: 1em; margin-bottom: 1em; font-family: "IntelOne Text"; font-size: 10pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="line-height: 20px; margin-top: 1em; margin-bottom: 1em; font-family: "IntelOne Text"; font-size: 10pt; color: rgb(0, 0, 0);">
My preference would be to keep them as separate applications for now and revisit consolidation if we identify a meaningful amount of shared infrastructure.</div>
<div class="elementToProof" style="line-height: 20px; margin-top: 1em; margin-bottom: 1em; font-family: "IntelOne Text"; font-size: 10pt; color: rgb(0, 0, 0);">
Regards,</div>
<div class="elementToProof" style="line-height: 20px; margin-top: 1em; margin-bottom: 1em; font-family: "IntelOne Text"; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
Kai</div>
<div class="elementToProof" style="text-align: left; text-indent: 0px; margin: 0px 0px 16px; font-family: "IntelOne Text"; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>From:</b> Thomas Monjalon <thomas@monjalon.net><br>
<b>Sent:</b> Friday, September 25, 2026 17:32<br>
<b>To:</b> Ji, Kai <kai.ji@intel.com>; Akhil Goyal <gakhil@marvell.com><br>
<b>Cc:</b> dev@dpdk.org <dev@dpdk.org><br>
<b>Subject:</b> Re: [EXTERNAL] [PATCH v7] examples: add Wycheproof validation app
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-size: 11pt;">24/09/2026 20:00, Akhil Goyal:<br>
> > Wycheproof differs somewhat from the existing cryptodev test vectors in that it is<br>
> > an externally maintained collection of JSON test suites covering a large number of<br>
> > edge cases and negative tests. The intended usage model is to load the upstream<br>
> > vector files at runtime rather than embedding them in the DPDK tree.<br>
> > I think the existing examples/fips_validation application follows a similar<br>
> > approach, consuming external CAVP/ACVP vector files rather than integrating<br>
> > them into dpdk-test. This patch follows that precedent, with the goal of providing<br>
> > file-driven conformance validation as a standalone example application.<br>
> > I agree that the documentation can be improved. At minimum, the .rst should<br>
> > describe where the Wycheproof vectors can be obtained and reference the<br>
> > applicable upstream license, as the current example command may give the<br>
> > impression that the vector files are included in the DPDK source tree when they<br>
> > are not.<br>
><br>
> Ok, so in that case did you consider integrating this app into fips_validation app..<br>
> May be we could rename fips_validation to crypto_validation and internally have 2 modes -<br>
> Fips and Wycheproof? Like what we have for examples/multi_process?<br>
<br>
I like this proposal.<br>
<br>
<br>
<br>
</div>
</body>
</html>