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