From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F09E442FC8; Thu, 3 Aug 2023 18:24:24 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C4A5240C35; Thu, 3 Aug 2023 18:24:24 +0200 (CEST) Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) by mails.dpdk.org (Postfix) with ESMTP id 186F940C35 for ; Thu, 3 Aug 2023 18:24:23 +0200 (CEST) Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-56cd753b31cso663292eaf.1 for ; Thu, 03 Aug 2023 09:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1691079862; x=1691684662; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9gnPSXByhyqIknF7R+AyWrIiKhvp8D4x/tzHLfCd7BA=; b=cPwRRDrX3RnwI/IvrLPhDHAsTJQyReMIqSMzILayXSD9u9xJglAC5K65AvAf4PvrtP 8vX7HOQg0sCqqpywYsCnAuLCJzfKrF8oN0jcng7IAt/xlG64YSHEyTbvwpixKP6+S6nb 2vVKMgjTwPub991rlgWms9etOZ6/BwgN1iED8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691079862; x=1691684662; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9gnPSXByhyqIknF7R+AyWrIiKhvp8D4x/tzHLfCd7BA=; b=jOofcwwzkVw6ps7e22Eag8FUD5H19HMpaxYa693LtJupxWnwPIjbchzYNZM3/LC9Aq hS9IG85fM7jGkR8PKsYC6jgXE56pU7s58fBhEYW6ruf8eI7pnJrFHZ3d72wRwheK9vBQ w2XR4TtKB1/Vp9jCYqaGVOeAcVydYzaZdNQYfEf+Ob3lJgOGMm/NIppLb3Yy1w8QtqbU cO+5LXWzwcQn5rT8f/oY8xK9t+iLCFk+kvyVjwnjE2tuGViw7K70hkP5LGtZqnUKo8Gp p/DwonMKG77TRmc6CCUkcceh06nn1cTrb6OBVfzYXTQDL469P2zY4Kntx231O7HXkitD 2Wag== X-Gm-Message-State: ABy/qLbAA9p1wHzccDVJPw9DKlAGKywGtOyEw/R6fzptrfDvat7XT8YD FYeAV09C3+/hDg8HepikxB3YoixZPYUAB0ec2f+uO82nZEWtm4lHHIYbkw== X-Google-Smtp-Source: APBJJlG+uaFA5paFFDILnIvXmqCumtBkbUv5oMLBfncCdb3Uiz4QL8Psvk0c0BsORBIN9uupxpP/ccy/CB6ODZ/D/SM= X-Received: by 2002:a4a:91ca:0:b0:56c:c061:a9a8 with SMTP id e10-20020a4a91ca000000b0056cc061a9a8mr9093553ooh.0.1691079861550; Thu, 03 Aug 2023 09:24:21 -0700 (PDT) MIME-Version: 1.0 From: Patrick Robb Date: Thu, 3 Aug 2023 12:24:10 -0400 Message-ID: Subject: Community CI Meeting Minutes - August 3, 2023 To: ci@dpdk.org Cc: dts@dpdk.org Content-Type: multipart/alternative; boundary="0000000000006f59d506020736fc" X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.29 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 --0000000000006f59d506020736fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable August 3, 2023 ##################################################################### Attendees 1. Patrick Robb 2. Juraj Linke=C5=A1 3. Ali Alnubani 4. Aaron Conole 5. Jeremy Spewock 6. Adam Hassick 7. Honnappa Nagarahalli 8. Adam Hassick ##################################################################### Agenda 1. General Announcements 2. CI Status 3. DTS Improvements & Test Development 4. Any other business ##################################################################### Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Announcements * DPDK 23.07 is released * RFC deadline for 23.11 is August 12th * Ali has upgraded patchwork to v3 * You can now see cover and patch comments at the /events endpoint, and use those to get comment content, which can be used for the proposed email based retesting framework * Napatech is preparing a patchseries to upstream their driver, and fixing errors/warnings reported by the checkpatches script =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CI Status --------------------------------------------------------------------- UNH-IOL Community Lab * Test coverage changes: * Testing on RHEL7 is now disabled for DPDK main and next-* branches, but left on for LTS and LTS-staging branches * This is because DPDK will require a C11 supporting compiler starting with 23.11: https://patchwork.dpdk.org/project/dpdk/patch/20230802123134.370199-1-bruce= .richardson@intel.com/ * Perf results re-enabled for Intel XL710 40G NIC on x86 * Maintenance: We are upgrading the Nvidia DTS DUT to Ubuntu 22.04 on Monday morning. This will be a clean OS install, so there may be some downtime for mlnx results. Testing for this patchseries will queue up while it=E2=80=99s offline, so no results will be missed, only delayed. * Intel 8970 QAT Accelerator card for crypto/compress functions has arrived, and is installed in the ARM Ampere test bed * compress suite: https://git.dpdk.org/tools/dts/tree/test_plans/compressdev_qat_pmd_test_pla= n.rst * crypto suite: https://git.dpdk.org/tools/dts/tree/test_plans/crypto_perf_cryptodev_perf_t= est_plan.rst * Supports asymmetrical crypto, symmetrical crypto, and compress PMDs, but requires the kernel QAT driver, which I don=E2=80=99t see loaded on the= system * There was a patch submitted to the kernel community which enables the qat kernel driver for ARM * This may or may not have made it to the mainline kernel * Looks like it got in 4 months ago * Have pinged ARM folks about this, and will facilitate their remote access to the server if they=E2=80=99re willing to take a look * Apparently you can download the QAT driver if it=E2=80=99s not avai= lable on your kernel version: https://www.intel.com/content/www/us/en/developer/topic-technology/open/qui= ck-assist-technology/overview.html * Kernel drivers are more generic and may be more appropriate for arm platforms, so this option is not desirable * Retesting framework: We took a look at some comments on patchwork - It is compatible with our parsing solution and idea for triggering retests on coverage subsets based on labels/contexts. We still need to write the Jenkins pipelines to automate this, and store the source of truth for context scope (in terms of our Jenkins pipelines) * NIC hardware refresh: * Marvell board has arrived - deprioritizing this compared to other hardware refresh items because we are blocked until SDK documentation and board user guide are shared with us. Still need details from them about chassis, other components to pair with the board, and guidelines for how they want to test DPDK on the hardware. They did share a l2fwd sample app setup specific to the marvell board, which we could setup and =E2=80=9Ctest= ,=E2=80=9D but presumably they will want to accomplish more on the board than this sample app run. * Aaron is going to write an email to UNH people, Rashid, etc. to see if we need to re-asses about standing up a dev board in the Lab - it may not be a very good use of our time for the community * E810 (traffic generator) to pair with this board has arrived * Need to acquire DAC cabling for this, this needs to be a specific breakout cable (from discussions with Marvell), so we need to ensure the correct breakout is ordered. * Request an exact part number and UNH can probably order it * 2 Intel E810s are in, DAC cabling has arrived, this NIC will be installed in the to be donated Intel server * Legal review continues for Intel=E2=80=99s server donation * 1 of the 2 mlnx cx6 cards are in, the other is backordered * DAC cables are here * 2 mlnx cx7 cards are still on backorder * DAC cables are here * QAT card has arrived and is available on the system - plan to bring this online is in place and can be acted on quickly, pending resolution of the QAT driver question * Everything else is ordered --------------------------------------------------------------------- Intel Lab * None --------------------------------------------------------------------- Loongarch Lab * None --------------------------------------------------------------------- Github Actions * I need to look at the ABI failure report from Akhil. I will also merge Adam's CI container template engine patch today * Also working on test label stuff =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DTS Improvements & Test Development * The DTS WG is collaborating on a slideshow presentation for the DPDK Summit * Block diagram is preferred over the ladder diagram in slide 4 * Presentation is on sept 12th at the end of the day - the last presentation of the day * Aim to have the slides ready by August 22th, and the slides need to be submitted in advance of the summit for review * Juraj and Jeremy both have vacation starting on the 14th * Please add any RFC ideas you have for DTS, and vote on the importance of these so we can prioritize them: https://docs.google.com/spreadsheets/d/19kkWLEudy-Q5V4j0hTR-fDY_3hlKBgA_Y8r= LtY89aU8/edit?usp=3Dsharing * Traffic gen abstraction patch * This was implemented with lots of =E2=80=9Csimplest assumptions pos= sible=E2=80=9D * Assumes there was only 1 nic with 2 ports * Going forward, this likely needs to be adapted to allow for any amount of nics * How to specify nic config in conf file? * Probably easier to specify just 1 nic per execution * The only benefit for relating multiple nics to 1 execution is removing redundancy, but this is only a small consideration * Are there instances where we need to specify multiple NON-nics for a single execution: No * Is there a distinction between DPDK supported NICs and DTS supported nics? * If DTS has existing testsuites which apply to the NIC in question, should that be the prereq for it being =E2=80=9Csupported by dts= =E2=80=9D * Or, is it simply nics supported by DPDK? * Do we want to verify the nic dts codename against a linux id to verify we are working with the correct nic? * Parallel testing * Will this save significant time? * Are there any noisy neighbor problem(s) to worry about which could be introduced by parallel testing? * We may be able to do 1 test per nic at a time, but have parallel testing on a system across multiple nics (provided the nics are isolated) * You can also just run multiple instances of DTS in a specific container * This would allow us to add more testsuites to CI, as testing capacity would be a reduced concern * The build may have to happen =E2=80=9Cearlier=E2=80=9D and be= passed into containers running dts, so that we build dpdk only 1 time and not 1 time per container * Currently supporting a 2 port topology - 2 ports on TG are connected to 2 ports on SUT. This is the same as =E2=80=9Cold dts.=E2=80=9D= Port 1 TG to port 1 SG then forwarded to port 2 on SG and then port 2 on TG * Are there any other topologies required for any =E2=80=9Cexot= ic=E2=80=9D testsuites? * We should have support for bidirectional traffic * Should driver binding be handled by the user, or by DTS? Currently it is handled by the user before running DTS. There may be some complications introduced by wrapping this into DTS, so we will avoid for now. * If port is bound to vfio-pci, you cannot get mac from kernel driver. Given this, it may be simpler to expect users to specify the mac address of the TG and SUT ports. This will be set in the conf.yaml. * Currently there is an assumption that the TG node is required, this can be made optional later for testsuites like QAT which require no traffic sent from TG to SUT * Should we be able to have multiple TGs on a TG node? We could specify a func traffic gen and perf traffic gen on the same TG node. * In nodes section we could specify that a tg supports both scapy and trex, for instance, and execution will use appropriate tg according to perf or func. These cannot happen in parallel due to driver binding. * Need to make sure that the results file accounts for this * We want to be able to do this, but there is no obvious solution right now. * Users can workaround this situation like they always did with old dts, by having separate dts runs for functional tests vs performance tests. * Do we want to allow multiple TGs of the same type on a TG node? (like 2 capturing TGs) * This would almost never be needed, and anyone operating a significantly complex setup which requires this, can just partition into different DTS runs. * Should we verify traffic coming in on the NIC or just assume that it is ours? * The only reason this would be an unsafe assumption to make is if there was other noise on the NIC but in our case this should be a fine thing to assume. * Expanding smoke tests idea for 23.11 * Do a simple non-perf l2/l3fwd and check that packets are sent and received * Does this have overlap with the UDP testcase? Would we want to port this over to use testpmd instead and include it in smoke tests? * This would make sense =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Any other business * Next meeting is August 17, 2023 --0000000000006f59d506020736fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
August 3, 2023

###############################= ######################################
Attendees
1. Patrick Robb
2= . Juraj Linke=C5=A1
3. Ali Alnubani
4. Aaron Conole
5. Jeremy Spew= ock
6. Adam Hassick
7. Honnappa Nagarahalli
8. Adam Hassick
#####################################################################
A= genda
1. General Announcements
2. CI Status
3. DTS Improvements &a= mp; Test Development
4. Any other business

######################= ###############################################
Minutes

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
General Announcements* DPDK 23.07 is released
* RFC deadline for 23.11 is August 12th
* = Ali has upgraded patchwork to v3
=C2=A0 =C2=A0* You can now see cover an= d patch comments at the /events endpoint, and use those to get comment cont= ent, which can be used for the proposed email based retesting framework
= * Napatech is preparing a patchseries to upstream their driver, and fixing = errors/warnings reported by the checkpatches script

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CI Status

------------= ---------------------------------------------------------
UNH-IOL Commun= ity Lab
* Test coverage changes:
=C2=A0 =C2=A0* Testing on RHEL7 is n= ow disabled for DPDK main and next-* branches, but left on for LTS and LTS-= staging branches
=C2=A0 =C2=A0 =C2=A0 * This is because DPDK will requir= e a C11 supporting compiler starting with 23.11: https://patchwork.dpdk.org/project/dpdk/patch/20230802123134.37019= 9-1-bruce.richardson@intel.com/
=C2=A0 =C2=A0* Perf results re-enabl= ed for Intel XL710 40G NIC on x86
* Maintenance: We are upgrading the Nv= idia DTS DUT to Ubuntu 22.04 on Monday morning. This will be a clean OS ins= tall, so there may be some downtime for mlnx results. Testing for this patc= hseries will queue up while it=E2=80=99s offline, so no results will be mis= sed, only delayed.
* Intel 8970 QAT Accelerator card for crypto/compress= functions has arrived, and is installed in the ARM Ampere test bed
=C2= =A0 =C2=A0* compress suite: https://git.dpdk.org/tools/dt= s/tree/test_plans/compressdev_qat_pmd_test_plan.rst
=C2=A0 =C2=A0* c= rypto suite: https://git.dpdk.org/tools/dts/tree/t= est_plans/crypto_perf_cryptodev_perf_test_plan.rst
=C2=A0 =C2=A0* Su= pports asymmetrical crypto, symmetrical crypto, and compress PMDs, but requ= ires the kernel QAT driver, which I don=E2=80=99t see loaded on the system =
=C2=A0 =C2=A0 =C2=A0 * There was a patch submitted to the kernel commun= ity which enables the qat kernel driver for ARM
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0* This may or may not have made it to the mainline kernel
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Looks like it got in 4 months a= go
=C2=A0 =C2=A0 =C2=A0 * Have pinged ARM folks about this, and will fac= ilitate their remote access to the server if they=E2=80=99re willing to tak= e a look
=C2=A0 =C2=A0 =C2=A0 * Apparently you can download the QAT driv= er if it=E2=80=99s not available on your kernel version: https://www.intel.com/content/www/us/en/develo= per/topic-technology/open/quick-assist-technology/overview.html
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Kernel drivers are more generic and may be= more appropriate for arm platforms, so this option is not desirable
* = Retesting framework: We took a look at some comments on patchwork - It is c= ompatible with our parsing solution and idea for triggering retests on cove= rage subsets based on labels/contexts. We still need to write the Jenkins p= ipelines to automate this, and store the source of truth for context scope = (in terms of our Jenkins pipelines)
* NIC hardware refresh:
=C2=A0 = =C2=A0* Marvell board has arrived - deprioritizing this compared to other h= ardware refresh items because we are blocked until SDK documentation and bo= ard user guide are shared with us. Still need details from them about chass= is, other components to pair with the board, and guidelines for how they wa= nt to test DPDK on the hardware. They did share a l2fwd sample app setup sp= ecific to the marvell board, which we could setup and =E2=80=9Ctest,=E2=80= =9D but presumably they will want to accomplish more on the board than this= sample app run.
=C2=A0 =C2=A0 =C2=A0 * Aaron is going to write an email= to UNH people, Rashid, etc. to see if we need to re-asses about standing u= p a dev board in the Lab - it may not be a very good use of our time for th= e community
=C2=A0 =C2=A0 =C2=A0 * E810 (traffic generator) to pair with= this board has arrived
=C2=A0 =C2=A0 =C2=A0 * Need to acquire DAC cabli= ng for this, this needs to be a specific breakout cable (from discussions w= ith Marvell), so we need to ensure the correct breakout is ordered.
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Request an exact part number and UNH can p= robably order it
=C2=A0 =C2=A0* 2 Intel E810s are in, DAC cabling has ar= rived, this NIC will be installed in the to be donated Intel server
=C2= =A0 =C2=A0 =C2=A0 * Legal review continues for Intel=E2=80=99s server donat= ion
=C2=A0 =C2=A0* 1 of the 2 mlnx cx6 cards are in, the other is backor= dered
=C2=A0 =C2=A0 =C2=A0 * DAC cables are here
=C2=A0 =C2=A0* 2 mln= x cx7 cards are still on backorder
=C2=A0 =C2=A0 =C2=A0 * DAC cables are= here
=C2=A0 =C2=A0* QAT card has arrived and is available on the system= - plan to bring this online is in place and can be acted on quickly, pendi= ng resolution of the QAT driver question
=C2=A0 =C2=A0* Everything else = is ordered
=C2=A0 =C2=A0
=C2=A0 =C2=A0-------------------------------= --------------------------------------
Intel Lab
* None

------= ---------------------------------------------------------------
Loongarc= h Lab
* None

----------------------------------------------------= -----------------
Github Actions
* I need to look at the ABI failure = report from Akhil. I will also merge Adam's CI container template engin= e patch today
* Also working on test label stuff

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DTS Improvements & Test D= evelopment
* The DTS WG is collaborating on a slideshow presentation for= the DPDK Summit
=C2=A0 =C2=A0* Block diagram is preferred over the ladd= er diagram in slide 4
=C2=A0 =C2=A0* Presentation is on sept 12th at the= end of the day - the last presentation of the day
=C2=A0 =C2=A0* Aim to= have the slides ready by August 22th, and the slides need to be submitted = in advance of the summit for review
=C2=A0 =C2=A0 =C2=A0 * Juraj and Jer= emy both have vacation starting on the 14th
* Please add any RFC ideas y= ou have for DTS, and vote on the importance of these so we can prioritize t= hem: https://docs.google.com/spread= sheets/d/19kkWLEudy-Q5V4j0hTR-fDY_3hlKBgA_Y8rLtY89aU8/edit?usp=3Dsharing
=C2=A0 =C2=A0* Traffic gen abstraction patch
=C2=A0 =C2=A0 =C2=A0 *= This was implemented with lots of =E2=80=9Csimplest assumptions possible= =E2=80=9D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Assumes there was only 1 n= ic with 2 ports
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Going forward, this = likely needs to be adapted to allow for any amount of nics
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0* How to specify nic config in conf file?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Probably easier to specify just 1 nic= per execution
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * The only bene= fit for relating multiple nics to 1 execution is removing redundancy, but t= his is only a small consideration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 * Are there instances where we need to specify multiple NON-nics for a = single execution: No
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Is there a dist= inction between DPDK supported NICs and DTS supported nics?
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * If DTS has existing testsuites which appl= y to the NIC in question, should that be the prereq for it being =E2=80=9Cs= upported by dts=E2=80=9D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Or,= is it simply nics supported by DPDK?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 * Do we want to verify the nic dts codename against a linux id to v= erify we are working with the correct nic?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0* Parallel testing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Wil= l this save significant time?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= * Are there any noisy neighbor problem(s) to worry about which could be in= troduced by parallel testing?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0* We may be able to do 1 test per nic at a time, but have para= llel testing on a system across multiple nics (provided the nics are isolat= ed)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* You can als= o just run multiple instances of DTS in a specific container
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * This would allow us to add more testsuite= s to CI, as testing capacity would be a reduced concern
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 * The build may have to happen =E2=80=9Cearlier= =E2=80=9D and be passed into containers running dts, so that we build dpdk = only 1 time and not 1 time per container
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0* Currently supporting a 2 port topology - 2 ports on TG are connected t= o 2 ports on SUT. This is the same as =E2=80=9Cold dts.=E2=80=9D Port 1 TG = to port 1 SG then forwarded to port 2 on SG and then port 2 on TG
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Are there any other topologies requir= ed for any =E2=80=9Cexotic=E2=80=9D testsuites?
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 * We should have support for bidirectional traffic
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Should driver binding be handled by the us= er, or by DTS? Currently it is handled by the user before running DTS. Ther= e may be some complications introduced by wrapping this into DTS, so we wil= l avoid for now.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If port is bound t= o vfio-pci, you cannot get mac from kernel driver. Given this, it may be si= mpler to expect users to specify the mac address of the TG and SUT ports. T= his will be set in the conf.yaml.
=C2=A0 =C2=A0 =C2=A0 * Currently there= is an assumption that the TG node is required, this can be made optional l= ater for testsuites like QAT which require no traffic sent from TG to SUT=C2=A0 =C2=A0 =C2=A0 * Should we be able to have multiple TGs on a TG nod= e? We could specify a func traffic gen and perf traffic gen on the same TG = node.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* In nodes section we could spe= cify that a tg supports both scapy and trex, for instance, and execution wi= ll use appropriate tg according to perf or func. These cannot happen in par= allel due to driver binding.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Need to= make sure that the results file accounts for this
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0* We want to be able to do this, but there is no obvious solut= ion right now.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Users can workaround= this situation like they always did with old dts, by having separate dts r= uns for functional tests vs performance tests.
=C2=A0 =C2=A0 =C2=A0 * Do= we want to allow multiple TGs of the same type on a TG node? (like 2 captu= ring TGs)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* This would almost never be= needed, and anyone operating a significantly complex setup which requires = this, can just partition into different DTS runs.
=C2=A0 =C2=A0 =C2=A0 = * Should we verify traffic coming in on the NIC or just assume that it is o= urs?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* The only reason this would be a= n unsafe assumption to make is if there was other noise on the NIC but in o= ur case this should be a fine thing to assume.
=C2=A0 =C2=A0* Expanding = smoke tests idea for 23.11
=C2=A0 =C2=A0 =C2=A0 * Do a simple non-perf l= 2/l3fwd and check that packets are sent and received
=C2=A0 =C2=A0 =C2= =A0 * Does this have overlap with the UDP testcase? Would we want to port t= his over to use testpmd instead and include it in smoke tests?
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0* This would make sense
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Any other business
* Next meeting is August 17, 2023
--0000000000006f59d506020736fc--