Community CI Meeting Minutes - August 3, 2023

Community CI Meeting Minutes - August 3, 2023

[Patrick Robb]

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

August 3, 2023

#####################################################################
Attendees
1. Patrick Robb
2. Juraj Linkeš
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

=====================================================================
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

=====================================================================
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’s 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_plan.rst
   * crypto suite:
https://git.dpdk.org/tools/dts/tree/test_plans/crypto_perf_cryptodev_perf_test_plan.rst
   * Supports asymmetrical crypto, symmetrical crypto, and compress PMDs,
but requires the kernel QAT driver, which I don’t 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’re willing to take a look
      * Apparently you can download the QAT driver if it’s not available on
your kernel version:
https://www.intel.com/content/www/us/en/developer/topic-technology/open/quick-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 “test,” 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’s 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

=====================================================================
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_Y8rLtY89aU8/edit?usp=sharing
   * Traffic gen abstraction patch
      * This was implemented with lots of “simplest assumptions possible”
         * 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 “supported by dts”
            * 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 “earlier” 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 “old dts.” 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 “exotic”
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

=====================================================================
Any other business
* Next meeting is August 17, 2023

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