test suite reviews and discussions
 help / color / mirror / Atom feed
From: Owen Hilyard <ohilyard@iol.unh.edu>
To: dts@dpdk.org, "Tu, Lijuan" <lijuan.tu@intel.com>,
	"Ma, LihongX" <lihongx.ma@intel.com>,
	 Lincoln Lavoie <lylavoie@iol.unh.edu>,
	Sarah Hall <shall@iol.unh.edu>
Subject: [dts] Runtime code generation for RTE Flow
Date: Wed, 7 Oct 2020 16:13:57 -0400	[thread overview]
Message-ID: <CAHx6DYDw1H9BbmiQAw=DV5i=+zyk7K7Ab-g+PVKSaWwK_Jkmig@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

Hello all,

I've been working on tests for the flow API recently, and I've hit a point
where I think runtime code generation would be useful. For context, the way
the test suite is architected right now, I start up testpmd in the
set_up_all function, and then every single flow rule that is tested get
it's own test case. I did this so that we can have the benefits of only
starting testpmd once, but we can still have the granularity of knowing
exactly what failed. Currently, I have a script which generates all 54
pattern matching test cases and prints them out, this means that I can copy
and paste the generated test cases into the test suite. I am concerned
about someone who needs to maintain this test suite afterward not receiving
that important bit of information. The simple solution to this problem that
I see is to modify the test suite to add the test cases at runtime.

The reason I'm reaching out instead of just doing this and submitting this
is that I wanted to make sure that there no strong objections before
starting. Doing this would probably involve the use of exec to avoid
needing to hook parts of the interpreter to generate the symbol tree
directly. Performance isn't an issue since this takes roughly 3/1000 of a
second.

More details on the plan for the test suite can be found at
https://docs.google.com/document/d/1_jEciQFZ-Lj1ASF_mQbCnB3U5FefdW2Z84HP1y-GJek/edit?usp=sharing

I'd appreciate any concerns or suggestions on this.

Owen Hilyard
UNH InterOperability Laboratory

[-- Attachment #2: Type: text/html, Size: 1717 bytes --]

             reply	other threads:[~2020-10-07 20:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 20:13 Owen Hilyard [this message]
2020-10-09  6:16 ` Ma, LihongX

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='CAHx6DYDw1H9BbmiQAw=DV5i=+zyk7K7Ab-g+PVKSaWwK_Jkmig@mail.gmail.com' \
    --to=ohilyard@iol.unh.edu \
    --cc=dts@dpdk.org \
    --cc=lihongx.ma@intel.com \
    --cc=lijuan.tu@intel.com \
    --cc=lylavoie@iol.unh.edu \
    --cc=shall@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).