Testpmd usage in new DTS

Testpmd usage in new DTS

[Patrick Robb]

Hi Thomas,

Last November when we chatted in tech board about 2024 DTS goals, you
said testpmd should be the primary tool used to drive the testsuites,
and that if testpmd was missing some support for any DPDK features we
want to test in DTS, then the support should be added into testpmd.

So, we have recently been ramping up writing Ethernet API tests, and
have done it only with testpmd so far based on this understanding. It
seems like a good approach.

Today we discussed in the CI meeting whether we should port over the
l2fwd test, which is a test existing in the "old" DTS framework, based
on the l2fwd sample app. For bringing this test coverage to new DTS, I
think the correct approach is to write a testsuite which validates the
same l2 forwarding functions, but using testpmd app instead of l2fwd
app. I think this aligns with your expectation of driving testpmd
usage in new DTS, but let me know if I have the wrong idea. So does
this sound fine to you?

And a second thing I want to raise which is tangentially related is I
guess in the future we will have to determine what other apps can be
used for tests which can't run from testpmd. I.e. right now at UNH lab
we are running cryptodev tests on an Intel Quickassist 8970 card on
our ARM server, and that test runs from an old DTS testsuite based on
dpdk-test-cryptodev-perf. I'm guessing usage of such applications
which have extensive support not existing in testpmd will be permitted
at some point. It's fairly forward looking as we are really focused on
ethdev work currently, but I figured I'd bring it up now.

Re: Testpmd usage in new DTS

[Thomas Monjalon]

Hello

27/06/2024 22:42, Patrick Robb:
> Hi Thomas,
> 
> Last November when we chatted in tech board about 2024 DTS goals, you
> said testpmd should be the primary tool used to drive the testsuites,
> and that if testpmd was missing some support for any DPDK features we
> want to test in DTS, then the support should be added into testpmd.

Yes for networking features.

> So, we have recently been ramping up writing Ethernet API tests, and
> have done it only with testpmd so far based on this understanding. It
> seems like a good approach.

Good

> Today we discussed in the CI meeting whether we should port over the
> l2fwd test, which is a test existing in the "old" DTS framework, based
> on the l2fwd sample app. For bringing this test coverage to new DTS, I
> think the correct approach is to write a testsuite which validates the
> same l2 forwarding functions, but using testpmd app instead of l2fwd
> app. I think this aligns with your expectation of driving testpmd
> usage in new DTS, but let me know if I have the wrong idea. So does
> this sound fine to you?

l2fwd and l3fwd are code examples to show how to write code,
they are not supposed to be designed for CI testing.
What is the benefit of l2fwd compared to testpmd?
There are forward modes in testpmd which should be similar to l2fwd.
But here we are reaching a limit: testpmd is supposed to test driver features,
not a higher level forward logic like we could see in l3fwd.
Anyway testing higher level features from some libraries are not in 2024 scope I think.

> And a second thing I want to raise which is tangentially related is I
> guess in the future we will have to determine what other apps can be
> used for tests which can't run from testpmd. I.e. right now at UNH lab
> we are running cryptodev tests on an Intel Quickassist 8970 card on
> our ARM server, and that test runs from an old DTS testsuite based on
> dpdk-test-cryptodev-perf. I'm guessing usage of such applications
> which have extensive support not existing in testpmd will be permitted
> at some point. It's fairly forward looking as we are really focused on
> ethdev work currently, but I figured I'd bring it up now.

In general, DTS can use any app in the directory app/.
So yes that's fine to use the crypto-related apps for testing crypto features.