From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 11578A04BA; Wed, 7 Oct 2020 22:14:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C8D6F1B673; Wed, 7 Oct 2020 22:14:39 +0200 (CEST) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by dpdk.org (Postfix) with ESMTP id C204F2BC7 for ; Wed, 7 Oct 2020 22:14:38 +0200 (CEST) Received: by mail-oi1-f171.google.com with SMTP id w141so3871762oia.2 for ; Wed, 07 Oct 2020 13:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:from:date:message-id:subject:to; bh=u7xJPJz7mR4xx7q0GZoYAFN7tT2JoO9/yWGi0bv7NeU=; b=Qqcq8ghaHhUmOkDjNVDBkAt3q8Q1QVgZs42jmkl46u1KYPkGPDu+3wRCCTMooK9Ggn VTpiC+51Ih9I6toABK/f9UIlBkgYcXciEtxSTMBASsy7uyJrSOGvYDFq1tnaxJdCDLxO syK+hKw/wjYIDM2yNoDlsY1ixG5wckftNp4yE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=u7xJPJz7mR4xx7q0GZoYAFN7tT2JoO9/yWGi0bv7NeU=; b=Ptgs+iZGSQJ7v1aL4595F9U8fOwA+NERsjShgtWfc361Sro2mY3lM/0zzfMJlUSaWO fiIWLOm3khVGyFJUefH3aOl8ubpioM8x22bR5oI7d3NrLPPxgRv2TppbktwcJSO+PYcZ Tyr4BZFH0jsPEh4+eulYgi+FgPFFidSfdjgijTwlWhthe9Q1T33mmTZBbZlbHFBlfT6e gQxZe1f09Tmz1qQ5bpicxGZE0ndh6phUhwcRa9xJhToDTbZZkuaTd14wBzkwLvDzANAm 6jinCYBlUWlpnQXt7NUEo6zyrgVMYK88ViwT7kz8XAS0Y22PHy25CAn6kbzXA7GnM2lX Qwew== X-Gm-Message-State: AOAM533vEAYKZ/8LCp093Wm3IwHvhdUNdXKcQIUBJvVuYOC97gD0hDRU TlJRSQGE9zD8y6nBkORa0kHim3FYfX5+GWiBGE+mm7Vk3cQw8w== X-Google-Smtp-Source: ABdhPJysbx28eEQF6UF0fe0JcRe0T2DS488z2+J9GqU98fl5VvJjrb3BVkR2TAMma5txUlFpDiiQd+JKtZAvDKr4Mn0= X-Received: by 2002:aca:54c3:: with SMTP id i186mr2840640oib.35.1602101676760; Wed, 07 Oct 2020 13:14:36 -0700 (PDT) MIME-Version: 1.0 From: Owen Hilyard Date: Wed, 7 Oct 2020 16:13:57 -0400 Message-ID: To: dts@dpdk.org, "Tu, Lijuan" , "Ma, LihongX" , Lincoln Lavoie , Sarah Hall Content-Type: multipart/alternative; boundary="000000000000567aa005b11a5d14" Subject: [dts] Runtime code generation for RTE Flow X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org Sender: "dts" --000000000000567aa005b11a5d14 Content-Type: text/plain; charset="UTF-8" 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 --000000000000567aa005b11a5d14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

I've been working on tests for the f= low API recently, and I've hit a point where I think runtime code gener= ation would be useful. For context, the way the test suite is architected r= ight now, I start up testpmd in the set_up_all function, and then every sin= gle 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 h= ave the granularity of knowing exactly what failed. Currently, I have a scr= ipt 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 tes= t suite. I am concerned about someone who needs to maintain this test suite= afterward not receiving that important bit of information. The simple solu= tion 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 us= e 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 roug= hly 3/1000 of a second.

More details on the plan for the test suite= can be found at=C2=A0https://docs.goog= le.com/document/d/1_jEciQFZ-Lj1ASF_mQbCnB3U5FefdW2Z84HP1y-GJek/edit?usp=3Ds= haring

I'd appreciate any concerns or suggestions on this.
Owen Hilyard
UNH InterOperability Laboratory
--000000000000567aa005b11a5d14--