test suite reviews and discussions
 help / color / Atom feed
* [dts] Runtime code generation for RTE Flow
@ 2020-10-07 20:13 Owen Hilyard
  2020-10-09  6:16 ` Ma, LihongX
  0 siblings, 1 reply; 2+ messages in thread
From: Owen Hilyard @ 2020-10-07 20:13 UTC (permalink / raw)
  To: dts, Tu, Lijuan, Ma, LihongX, Lincoln Lavoie, Sarah Hall

[-- 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 --]

<div dir="ltr">Hello all,<br><br>I&#39;ve been working on tests for the flow API recently, and I&#39;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&#39;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. <br><br>The reason I&#39;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&#39;t an issue since this takes roughly 3/1000 of a second. <br><br>More details on the plan for the test suite can be found at <a href="https://docs.google.com/document/d/1_jEciQFZ-Lj1ASF_mQbCnB3U5FefdW2Z84HP1y-GJek/edit?usp=sharing">https://docs.google.com/document/d/1_jEciQFZ-Lj1ASF_mQbCnB3U5FefdW2Z84HP1y-GJek/edit?usp=sharing</a><br><br>I&#39;d appreciate any concerns or suggestions on this.<div><br></div><div>Owen Hilyard<br>UNH InterOperability Laboratory</div></div>

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [dts] Runtime code generation for RTE Flow
  2020-10-07 20:13 [dts] Runtime code generation for RTE Flow Owen Hilyard
@ 2020-10-09  6:16 ` Ma, LihongX
  0 siblings, 0 replies; 2+ messages in thread
From: Ma, LihongX @ 2020-10-09  6:16 UTC (permalink / raw)
  To: Chen, Zhaoyan, Peng, Yuan
  Cc: Owen Hilyard, dts, Tu, Lijuan, Lincoln Lavoie, Sarah Hall

[-- 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 --]

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D">+ zhaoyan and yuan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D">How do you think of this?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D">Ma,lihong</span><span style="font-size:12.0pt;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Owen Hilyard &lt;ohilyard@iol.unh.edu&gt; <br>
<b>Sent:</b> Thursday, October 8, 2020 4:14 AM<br>
<b>To:</b> dts@dpdk.org; Tu, Lijuan &lt;lijuan.tu@intel.com&gt;; Ma, LihongX &lt;lihongx.ma@intel.com&gt;; Lincoln Lavoie &lt;lylavoie@iol.unh.edu&gt;; Sarah Hall &lt;shall@iol.unh.edu&gt;<br>
<b>Subject:</b> Runtime code generation for RTE Flow<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">Hello all,<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
More details on the plan for the test suite can be found at&nbsp;<a href="https://docs.google.com/document/d/1_jEciQFZ-Lj1ASF_mQbCnB3U5FefdW2Z84HP1y-GJek/edit?usp=sharing">https://docs.google.com/document/d/1_jEciQFZ-Lj1ASF_mQbCnB3U5FefdW2Z84HP1y-GJek/edit?usp=sharing</a><br>
<br>
I'd appreciate any concerns or suggestions on this.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">Owen Hilyard<br>
UNH InterOperability Laboratory<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-07 20:13 [dts] Runtime code generation for RTE Flow Owen Hilyard
2020-10-09  6:16 ` Ma, LihongX

test suite reviews and discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/dts/0 dts/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dts dts/ http://inbox.dpdk.org/dts \
		dts@dpdk.org
	public-inbox-index dts


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dts


AGPL code for this site: git clone https://public-inbox.org/ public-inbox