test suite reviews and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Patrick Robb <probb@iol.unh.edu>
Cc: dts@dpdk.org, dev <dev@dpdk.org>,
	"Luca Vizzarro" <Luca.Vizzarro@arm.com>,
	"Paul Szczepanek" <Paul.Szczepanek@arm.com>,
	"Jeremy Spewock" <jspewock@iol.unh.edu>,
	"Dean Marx" <dmarx@iol.unh.edu>,
	"Nicholas Pratte" <npratte@iol.unh.edu>,
	"Juraj Linkeš" <juraj.linkes@pantheon.tech>,
	"David Marchand" <david.marchand@redhat.com>
Subject: Re: Testpmd usage in new DTS
Date: Fri, 28 Jun 2024 14:00:27 +0200	[thread overview]
Message-ID: <1871615.h9gRbJKcGU@thomas> (raw)
In-Reply-To: <CAJvnSUBj8UkRUOfOkaNW-9==sr2bu4EU9mfPGPqunhb0mw5ibQ@mail.gmail.com>

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.




      reply	other threads:[~2024-06-28 12:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 20:42 Patrick Robb
2024-06-28 12:00 ` Thomas Monjalon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1871615.h9gRbJKcGU@thomas \
    --to=thomas@monjalon.net \
    --cc=Luca.Vizzarro@arm.com \
    --cc=Paul.Szczepanek@arm.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dmarx@iol.unh.edu \
    --cc=dts@dpdk.org \
    --cc=jspewock@iol.unh.edu \
    --cc=juraj.linkes@pantheon.tech \
    --cc=npratte@iol.unh.edu \
    --cc=probb@iol.unh.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).