test suite reviews and discussions
 help / color / mirror / Atom feed
From: "Ma, LihongX" <lihongx.ma@intel.com>
To: "Chen, Zhaoyan" <zhaoyan.chen@intel.com>,
	"Peng, Yuan" <yuan.peng@intel.com>
Cc: Owen Hilyard <ohilyard@iol.unh.edu>,
	"dts@dpdk.org" <dts@dpdk.org>, "Tu, Lijuan" <lijuan.tu@intel.com>,
	Lincoln Lavoie <lylavoie@iol.unh.edu>,
	"Sarah Hall" <shall@iol.unh.edu>
Subject: Re: [dts] Runtime code generation for RTE Flow
Date: Fri, 9 Oct 2020 06:16:44 +0000	[thread overview]
Message-ID: <BN8PR11MB3715AAF0C66929A231DF47F49E080@BN8PR11MB3715.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAHx6DYDw1H9BbmiQAw=DV5i=+zyk7K7Ab-g+PVKSaWwK_Jkmig@mail.gmail.com>

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

+ zhaoyan and yuan

How do you think of this?

Regards,
Ma,lihong

From: Owen Hilyard <ohilyard@iol.unh.edu>
Sent: Thursday, October 8, 2020 4:14 AM
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: Runtime code generation for RTE Flow

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: 4735 bytes --]

      reply	other threads:[~2020-10-09  6:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 20:13 Owen Hilyard
2020-10-09  6:16 ` Ma, LihongX [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=BN8PR11MB3715AAF0C66929A231DF47F49E080@BN8PR11MB3715.namprd11.prod.outlook.com \
    --to=lihongx.ma@intel.com \
    --cc=dts@dpdk.org \
    --cc=lijuan.tu@intel.com \
    --cc=lylavoie@iol.unh.edu \
    --cc=ohilyard@iol.unh.edu \
    --cc=shall@iol.unh.edu \
    --cc=yuan.peng@intel.com \
    --cc=zhaoyan.chen@intel.com \
    /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).