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 D4C3442ED1; Thu, 20 Jul 2023 19:18:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C2901427E9; Thu, 20 Jul 2023 19:18:57 +0200 (CEST) Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by mails.dpdk.org (Postfix) with ESMTP id 1560640685 for ; Thu, 20 Jul 2023 19:18:56 +0200 (CEST) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-56fff21c2ebso11338077b3.3 for ; Thu, 20 Jul 2023 10:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1689873535; x=1690478335; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=5sAq6mtZlk8B/ovCXlYwcfGVeXABpyxAbsaFNX0L14k=; b=eJ9QNKVtfoO9rriL+LZVlAKsrqcRkwLLpjC9JOYE0wbrGle/0WLNJm5idcSF5j2BKa PdviTHTuejbYFSCPBOwPCQ6HT2oXi7oRduViw/pmtpeaokYKA3zFKnVtfrUgtFVlfo7k SSywwKcIloqvTQmFjxAmFei8Ed22TCxT00u3w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689873535; x=1690478335; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5sAq6mtZlk8B/ovCXlYwcfGVeXABpyxAbsaFNX0L14k=; b=RfBGfZS7lnwA3dfiDcWB7qw2+V9kl+55Js63P3mrOZPPN6WxRMS5bWnZMyJ5xF9KxL atAuk5tgLfxddIzAYT/YmcECkxTRbawd0sKVj0OhXlJfvOWXUuMg/Q/0GGmSgb8Xpi0M id6/9t9nE3pH5Xhy0JDsAm1/sHA/ACXu7Z/bpoMen6fZFOzTgWaLS010fqXRAiJdt5iv XPnOcGiC7Ww66e8Wue5hr8fVXXR/prTDEMC/JE+oOEzUkNNa5BizYx29MLLYFjx6ovR7 sT2yufKaUMfYYsY3rjrw2PFkbZycAYg1fQRN8A11CWyIF68j83/Vyjn28gSm+MZGJXBx r7yQ== X-Gm-Message-State: ABy/qLaMgeWPwh5x7haIADZPfDNoDNbNxn+ZP+DTQd2/tWWK6d9slnt+ 3Q7umCqgQLLSqrTL7se1XaHbTNgyFhD70K6/uwpF7c0D6t7/8LiD5P+WDKE6 X-Google-Smtp-Source: APBJJlEOz/IVHtSZsY6TLZ0rUDA3DKFDl+prlVtE53QlGaEG13wwQWFJ5MJEsMrNSHO/W3Vww0wmcGGK1/hnzEc0NVo= X-Received: by 2002:a0d:c2c4:0:b0:57a:8de8:f3b3 with SMTP id e187-20020a0dc2c4000000b0057a8de8f3b3mr21766208ywd.48.1689873534995; Thu, 20 Jul 2023 10:18:54 -0700 (PDT) MIME-Version: 1.0 From: Patrick Robb Date: Thu, 20 Jul 2023 13:18:44 -0400 Message-ID: Subject: Community CI Meeting Minutes - July 20, 2023 To: ci@dpdk.org Cc: dts@dpdk.org, dev@dpdk.org Content-Type: multipart/alternative; boundary="000000000000c4e8430600ee5768" 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 --000000000000c4e8430600ee5768 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable July 20, 2023 ##################################################################### Attendees 1. Patrick Robb 2. Alex Agerholm 3. Christian Muf 4. Juraj Linke=C5=A1 5. Danylo Vodopianov 6. Jeremy Spewock 7. M Kostenok 8. Lincoln Lavoie 9. Manit Mahajan 10. Alex Kholodnyi 11. Aaron Conole 12. Thomas Monjalon 13. Ali Alnubani ##################################################################### 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 * Napatech is beginning the process of contributing their driver for DPDK, and intends to stand up a process for CI testing * 1. What is the preferable way for community to work with custom HW? According * to the documentation: send hardware to the DPDK Lab in the UNH-IOL is one possible way? Could we set own lab? Where CI should be located and which accesses should be provided? * Making use of the Community Lab is one way to accomplish CI testing without having to setup your own CI Testing infrastructure. But, setting up your own internal lab and reporting your results is also good. * Governing board approval might be required about bringing a new vendor into the community lab * Is a specific membership tier required for hardware inclusion in the lab? * Napatech is wondering about any regular fee (per month, per year= ) * [Aaron] For running an internal lab, scripts for polling patchwork and DPDK CI testing scripts can be found at https://github.com/ovsrobot/pw-ci and at https://git.dpdk.org/tools/dpdk-ci= / * For how long should an internal lab be available? * As long as possible - the DPDK project will continuously be changing, so if a driver is contributed, long term testing will be very helpful in verifying for the community that no functionality breaks months or years down the road. If testing results can be provided long term, the community can help keep the driver in a good state long term. * 2. Which DTS tests should be executed by NT team to prove that NT DPDK driver is okay to be upstreamed? * There are no specific DTS testsuite requirements for upstreaming, so it=E2=80=99s best to just extend use of DTS as much as possible accordin= g to the driver=E2=80=99s feature set * 3. we have implemented custom DTS tests which are covering the functionality of the NIC. May these tests be considered as enough for merge of driver? If so, should they be upstreamed as well? * If you are going to report (to patchwork) results from these custom testsuites, they should be upstreamed to DTS. Lijuan is the maintainer. https://git.dpdk.org/tools/dts/ * Ping Lijuan about schedule for development * Small-Medium changes are fine halfway through a release cycle, but the RFCs exist for a reason and major changes cannot come late in the process * 4. Is there documentation for setting up a CI Testing lab with DPDK Patchwork? * There is not much in terms of documentation, but for running an internal lab, scripts for polling patchwork and DPDK CI testing scripts can be found at https://github.com/ovsrobot/pw-ci and at https://git.dpdk.org/tools/dpdk-ci/ * 5. In which format should be this test report? * [Aaron] Test reports can be as simple as: https://mails.dpdk.org/archives/test-report/2023-July/420253.html - Note that we need the subject line, Test-Label, Test-Status, patch url, and _test text_ to all be present in the form in that email. * 6. Which access level to the setup we should to provide for the community? * [Aaron] If you run your own lab, the community generally doesn't need access - but you will need to support in the case your lab has issues. * 7. On which request and how often we have to execute tests and send report? * [Aaron] We run the tests on every patch that comes via patchwork. * Ideally, the report will include the necessary output showing the failure and help the developer start digging on how to fix their patch * Currently Napatech has run testing periodically, but not (per patch/ per series) * 8. Do test reports need to be saved locally? * Not a requirement, if enough information can be included in the test report * UNH does save some artifacts associated with the testrun, which can be downloaded from the dashboard. In some cases these logs are much more extensive than what is provided on the emailed test report. * The ideal is to hold these for at least a release cycle * Napatech has developed a PMD dpdk driver for their smartNIC, which they aim to upstream to DPDK * Has run their custom DTS tests internally * Looking for clarity on what is required for upstreaming * Is CI testing a requirement for submitting a driver? A: No, code review is sufficient, but CI which reports upstream will help both Napatech and the community to protect against and performance or functional regressions or breakage * Provide an RFC by Aug 12th, further review and development can come afterwards * What meetings should Napatech attend for submitting their driver? * It would be typical for a presentation to be made to the tech board meeting. But first, the driver should be submitted via the mailing list. After that, someone will be invited to the tech board. * Ideally someone will check in with the CI meeting periodically * If Napatech didn=E2=80=99t want to report per patch, could we key off of = RC-* releases and have them simply report for those releases? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 * Eal_misc_flags_autotest: As you may have noticed, the Community Lab CI is failing a fast-test unit test on all new patchseries. The cause is a bnxt driver commit ( https://git.dpdk.org/dpdk/commit/?id=3D97435d7906d7706e39e5c3dfefa5e09d7de7= f733) which introduces statics which are stored in the same address space as is requested by the misc_flags_autotest. * Ajit suggests simply changing the address space requested by the unit test - which is fine with me * Aaron has posted a patch making this change * This is simply changing from one random address to another random address, and hoping this issue never happens again. Is there a better solution? * How to handle in the short term? Modify meson fast-tests suite every time? * The most interested part of this in terms of CI Testing is, how did it get through CI Testing and into DPDK, if it fails in our CI? The answer is that when the patchseries hit patchwork, it was =E2=80=9Cmissing'' one of t= he patches, which was added to patchwork hours later/next day. Unfortunately, our process does not currently account for this possibility (which is admittedly quite rare), and we simply tried to apply the series, failed, because we were missing one of the patches, and didn=E2=80=99t run the patc= hseries through our CI. * From Patchwork=E2=80=99s API, each =E2=80=9Cseries=E2=80=9D object = has a =E2=80=9Crecieved_all=E2=80=9D field. We will modify our process to account for this field. If it is False, then skip and try again later, until it is true * Bnxt is going to avoid submitting huge patches in the future * They created some static globals which =E2=80=9Crandomly=E2=80=9D are = assigned to a specific memory area which overlaps with the unit test * Apply failures and sanity check build failures are both reporting to patchwork: * Apply failure: https://patchwork.dpdk.org/project/dpdk/patch/20230712173050.599482-1-sivap= rasad.tummala@amd.com/ * Sanity check build: https://patchwork.dpdk.org/project/dpdk/patch/20230713102659.230606-2-maxim= e.coquelin@redhat.com/ * Compression-Perf sample app * We have dry run this using the Zlib vdev for compression/decomression operations, which provides results on validity of the decompressed output (compared to input file) and also provides performance metrics * For the zlib vdev, our thinking is for the testcase we should pass/fail based on the validity of the output. We will report the performance results, but these should not determine pass/fail for the vdev * We may have the opportunity to run the compression-perf sample app using hardware accelerators in the future. In that context, it would be appropriate to condition pass/fail on a performance variance threshold. * Linux kmods dpdk compile test has been broken for a few weeks, due to a linux kernel API modification in v6.5. Ferruh submitted a patch fixing build behavior for v6.5: https://git.dpdk.org/dpdk/commit/?id=3Ddd33d53b9a032d7376aa04a28a1235338e1f= d78f * Seen in daily periodic testing of main: https://dpdkdashboard.iol.unh.edu/results/dashboard/tarballs/25540/ * NIC hardware refresh: * Marvell board has arrived - 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. * 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 * Intel QAT card for the arm server is ordered, but backordered right no= w * No news from Ericcson about the embedded snow board * Everything else is ordered --------------------------------------------------------------------- Intel Lab * Intel reps keep saying there is a risk of less testing in the near future * The lab may be decreasing its operations * What was done in Intel lab, which we can replicate * UNH should check the gaps between what testing they are doing and Intel has been doing, and see if/where coverage can be bridged --------------------------------------------------------------------- Loongarch Lab * None --------------------------------------------------------------------- Github Actions * No news * Will return to retesting framework stuff going forward =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 * Smoke tests: http://patches.dpdk.org/project/dpdk/patch/20230719201807.12708-3-jspewock@= iol.unh.edu/ * traffic generator abstractions: http://patches.dpdk.org/project/dpdk/list/?series=3D28973 * In future releases, changes will not be accepted this late in the release cycle * There is a slot for DTS in the DPDK Summit (at the end of the first day - 20 minutes) * Juraj will be presenting remotely, Patrick will be there in person to answer any questions * Docstrings patch should be split into multiple parts. Agreement is still needed on the format to be used for documentation. * Extending smoke tests is one possibility * Dynamically skipping and selecting testsuites according to system info is one possible QOL feature * It probably makes sense to record possible development in a spreadsheet and vote on priorities * Are we ready to start porting over some of the functional tests? This should be technically possible, so we should explore this. * Dockerfile patch for DTS will possibly be a part of 23.11 DTS roadmap - Thomas will try to review this in August * Can more DTS patches be merged =E2=80=9Cmid release=E2=80=9D to make the = DTS development process more dynamic? * This should be possible - make sure to utilize slack and CC Thomas * Thomas will be the one to merge patches for DTS in the near future * Can this responsibility be deferred to someone else? Thomas is going to discuss this with the tech board at Dublin. In general Thomas would like to recruit more subtree maintainers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 * PW will be upgraded by Ali Alnubani on the first sunday after the 23.07 release, which should be this Sunday * Next meeting is August 3, 2023 --000000000000c4e8430600ee5768 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
July 20, 2023

#####################################= ################################
Attendees
1. Patrick Robb
2. Alex= Agerholm
3. Christian Muf
4. Juraj Linke=C5=A1
5. Danylo Vodopian= ov
6. Jeremy Spewock
7. M Kostenok
8. Lincoln Lavoie
9. Manit M= ahajan
10. Alex Kholodnyi
11. Aaron Conole
12. Thomas Monjalon
= 13. Ali Alnubani

###################################################= ##################
Agenda
1. General Announcements
2. CI Status3. DTS Improvements & Test Development
4. Any other business
#####################################################################
M= inutes

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DGeneral Announcements
* Napatech is beginning the process of contributi= ng their driver for DPDK, and intends to stand up a process for CI testing<= br>=C2=A0 =C2=A0* 1. What is the preferable way for community to work with = custom HW? According
=C2=A0 =C2=A0* to the documentation: send hardware= to the DPDK Lab in the UNH-IOL is one possible way? Could we set own lab? = Where CI should be located and which accesses should be provided?
=C2=A0= =C2=A0 =C2=A0 * Making use of the Community Lab is one way to accomplish C= I testing without having to setup your own CI Testing infrastructure. But, = setting up your own internal lab and reporting your results is also good. <= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Governing board approval might be re= quired about bringing a new vendor into the community lab
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0* Is a specific membership tier required for hardware i= nclusion in the lab?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Napatech is won= dering about any regular fee (per month, per year)
=C2=A0 =C2=A0 =C2=A0 = * [Aaron] For running an internal lab, scripts for polling patchwork and DP= DK CI testing scripts can be found at https://github.com/ovsrobot/pw-ci and at https://git.dpdk.org/tools/dpdk-ci/
=C2= =A0 =C2=A0 =C2=A0 * For how long should an internal lab be available?
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* As long as possible - the DPDK project = will continuously be changing, so if a driver is contributed, long term tes= ting will be very helpful in verifying for the community that no functional= ity breaks months or years down the road. If testing results can be provide= d long term, the community can help keep the driver in a good state long te= rm.
=C2=A0 =C2=A0* 2. Which DTS tests should be executed by NT team to p= rove that NT DPDK driver is okay to be upstreamed?
=C2=A0 =C2=A0 =C2=A0 = * There are no specific DTS testsuite requirements for upstreaming, so it= =E2=80=99s best to just extend use of DTS as much as possible according to = the driver=E2=80=99s feature set
=C2=A0 =C2=A0* 3. we have implemented c= ustom DTS tests which are covering the functionality of the NIC. May these = tests be considered as enough for merge of driver? If so, should they be up= streamed as well?
=C2=A0 =C2=A0 =C2=A0 * If you are going to report (to = patchwork) results from these custom testsuites, they should be upstreamed = to DTS. Lijuan is the maintainer. https://git.dpdk.org/tools/dts/
=C2=A0 =C2=A0 =C2=A0 * Ping Liju= an about schedule for development
=C2=A0 =C2=A0 =C2=A0 * Small-Medium ch= anges are fine halfway through a release cycle, but the RFCs exist for a re= ason and major changes cannot come late in the process
=C2=A0 =C2=A0* 4.= Is there documentation for setting up a CI Testing lab with DPDK Patchwork= ?
=C2=A0 =C2=A0 =C2=A0 * There is not much in terms of documentation, bu= t for running an internal lab, scripts for polling patchwork and DPDK CI te= sting scripts can be found at https://github.com/ovsrobot/pw-ci and at https://git.dpdk.org/tools/dpdk-ci/
=C2=A0 =C2=A0= * 5.=C2=A0 In which format should be this test report?
=C2=A0 =C2=A0 =C2= =A0 * [Aaron] Test reports can be as simple as: https://mails.dpdk.org/a= rchives/test-report/2023-July/420253.html - Note that we need the subje= ct line, Test-Label, Test-Status, patch url, and _test text_ to all be pres= ent in the form in that email.
=C2=A0 =C2=A0* 6. Which access level to t= he setup we should to provide for the community?
=C2=A0 =C2=A0 =C2=A0 * = [Aaron] If you run your own lab, the community generally doesn't need a= ccess - but you will need to support in the case your lab has issues.
= =C2=A0 =C2=A0* 7. On which request and how often we have to execute tests a= nd send report?
=C2=A0 =C2=A0 =C2=A0 * [Aaron] We run the tests on every= patch that comes via patchwork.
=C2=A0 =C2=A0 =C2=A0 * Ideally, the rep= ort will include the necessary output showing the failure and help the deve= loper start digging on how to fix their patch
=C2=A0 =C2=A0 =C2=A0 * Cur= rently Napatech has run testing periodically, but not (per patch/ per serie= s)
=C2=A0 =C2=A0* 8. Do test reports need to be saved locally?
=C2=A0= =C2=A0 =C2=A0 * Not a requirement, if enough information can be included i= n the test report
=C2=A0 =C2=A0 =C2=A0 * UNH does save some artifacts as= sociated with the testrun, which can be downloaded from the dashboard. In s= ome cases these logs are much more extensive than what is provided on the e= mailed test report.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* The ideal is to = hold these for at least a release cycle
* Napatech has developed a PMD d= pdk driver for their smartNIC, which they aim to upstream to DPDK
=C2=A0= =C2=A0* Has run their custom DTS tests internally
=C2=A0 =C2=A0* Lookin= g for clarity on what is required for upstreaming
=C2=A0 =C2=A0 =C2=A0 = * Is CI testing a requirement for submitting a driver? A: No, code review i= s sufficient, but CI which reports upstream will help both Napatech and the= community to protect against and performance or functional regressions or = breakage
* Provide an RFC by Aug 12th, further review and development ca= n come afterwards
* What meetings should Napatech attend for submitting = their driver?
=C2=A0 =C2=A0* It would be typical for a presentation to b= e made to the tech board meeting. But first, the driver should be submitted= via the mailing list. After that, someone will be invited to the tech boar= d.
=C2=A0 =C2=A0* Ideally someone will check in with the CI meeting peri= odically
* If Napatech didn=E2=80=99t want to report per patch, could we= key off of RC-* releases and have them simply report for those releases?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Statu= s

------------------------------------------------------------------= ---
UNH-IOL Community Lab
* Eal_misc_flags_autotest: As you may have = noticed, the Community Lab CI is failing a fast-test unit test on all new p= atchseries. The cause is a bnxt driver commit (https://git= .dpdk.org/dpdk/commit/?id=3D97435d7906d7706e39e5c3dfefa5e09d7de7f733) w= hich introduces statics which are stored in the same address space as is re= quested by the misc_flags_autotest.
=C2=A0 =C2=A0* Ajit suggests simply = changing the address space requested by the unit test - which is fine with = me
=C2=A0 =C2=A0 =C2=A0 * Aaron has posted a patch making this change=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* This is simply changing from one rando= m address to another random address, and hoping this issue never happens ag= ain. Is there a better solution?
=C2=A0 =C2=A0* How to handle in the sho= rt term? Modify meson fast-tests suite every time?
=C2=A0 =C2=A0* The m= ost interested part of this in terms of CI Testing is, how did it get throu= gh CI Testing and into DPDK, if it fails in our CI? The answer is that when= the patchseries hit patchwork, it was =E2=80=9Cmissing'' one of th= e patches, which was added to patchwork hours later/next day. Unfortunately= , our process does not currently account for this possibility (which is adm= ittedly quite rare), and we simply tried to apply the series, failed, becau= se we were missing one of the patches, and didn=E2=80=99t run the patchseri= es through our CI.
=C2=A0 =C2=A0 =C2=A0 * From Patchwork=E2=80=99s API,= each =E2=80=9Cseries=E2=80=9D object has a =E2=80=9Crecieved_all=E2=80=9D = field. We will modify our process to account for this field. If it is False= , then skip and try again later, until it is true
=C2=A0 =C2=A0 =C2=A0 *= Bnxt is going to avoid submitting huge patches in the future
=C2=A0 =C2= =A0* They created some static globals which =E2=80=9Crandomly=E2=80=9D are = assigned to a specific memory area which overlaps with the unit test
* A= pply failures and sanity check build failures are both reporting to patchwo= rk:
=C2=A0 =C2=A0* Apply failure: htt= ps://patchwork.dpdk.org/project/dpdk/patch/20230712173050.599482-1-sivapras= ad.tummala@amd.com/
=C2=A0 =C2=A0* Sanity check build: https://patchwork.dpdk.org/project/dpdk/patch/2023071= 3102659.230606-2-maxime.coquelin@redhat.com/
* Compression-Perf samp= le app
=C2=A0 =C2=A0* We have dry run this using the Zlib vdev for compr= ession/decomression operations, which provides results on validity of the d= ecompressed output (compared to input file) and also provides performance m= etrics
=C2=A0 =C2=A0 =C2=A0 * For the zlib vdev, our thinking is for the= testcase we should pass/fail based on the validity of the output. We will = report the performance results, but these should not determine pass/fail fo= r the vdev
=C2=A0 =C2=A0 =C2=A0 * We may have the opportunity to run the= compression-perf sample app using hardware accelerators in the future. In = that context, it would be appropriate to condition pass/fail on a performan= ce variance threshold.
* Linux kmods dpdk compile test has been broken = for a few weeks, due to a linux kernel API modification in v6.5. Ferruh sub= mitted a patch fixing build behavior for v6.5: https://git= .dpdk.org/dpdk/commit/?id=3Ddd33d53b9a032d7376aa04a28a1235338e1fd78f=C2=A0 =C2=A0* Seen in daily periodic testing of main: https://dpdkda= shboard.iol.unh.edu/results/dashboard/tarballs/25540/
* NIC hardware= refresh:
=C2=A0 =C2=A0* Marvell board has arrived - still need details = from them about chassis, other components to pair with the board, and guide= lines for how they want to test DPDK on the hardware. They did share a l2fw= d 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.
=C2=A0 =C2=A0 =C2=A0 * E810 (traffi= c generator) to pair with this board has arrived
=C2=A0 =C2=A0 =C2=A0 * = 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 bre= akout is ordered.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Request an exact = part number and UNH can probably order it
=C2=A0 =C2=A0* 2 Intel E810s a= re in, DAC cabling has arrived, this NIC will be installed in the to be don= ated Intel server
=C2=A0 =C2=A0 =C2=A0 * Legal review continues for Inte= l=E2=80=99s server donation
=C2=A0 =C2=A0* 1 of the 2 mlnx cx6 cards are= in, the other is backordered
=C2=A0 =C2=A0 =C2=A0 * DAC cables are here=
=C2=A0 =C2=A0* 2 mlnx cx7 cards are still on backorder
=C2=A0 =C2=A0= =C2=A0 * DAC cables are here
=C2=A0 =C2=A0* Intel QAT card for the arm = server is ordered, but backordered right now
=C2=A0 =C2=A0* No news from= Ericcson about the embedded snow board
=C2=A0 =C2=A0* Everything else i= s ordered
=C2=A0 =C2=A0
---------------------------------------------= ------------------------
Intel Lab
* Intel reps keep saying there is = a risk of less testing in the near future
=C2=A0 =C2=A0* The lab may be = decreasing its operations
=C2=A0 =C2=A0* What was done in Intel lab, whi= ch we can replicate
=C2=A0 =C2=A0 =C2=A0 * UNH should check the gaps bet= ween what testing they are doing and Intel has been doing, and see if/where= coverage can be bridged

-------------------------------------------= --------------------------
Loongarch Lab
* None

--------------= -------------------------------------------------------
Github Actions* No news
* Will return to retesting framework stuff going forward
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Impr= ovements & Test Development
* Smoke tests: = http://patches.dpdk.org/project/dpdk/patch/20230719201807.12708-3-jspewock@= iol.unh.edu/
* traffic generator abstractions: http://patches.dpdk.org/pr= oject/dpdk/list/?series=3D28973
* In future releases, changes will n= ot be accepted this late in the release cycle
* There is a slot for DTS = in the DPDK Summit (at the end of the first day - 20 minutes)
=C2=A0 =C2= =A0* Juraj will be presenting remotely, Patrick will be there in person to = answer any questions
* Docstrings patch should be split into multiple pa= rts. Agreement is still needed on the format to be used for documentation. =
* Extending smoke tests is one possibility
* Dynamically skipping an= d selecting testsuites according to system info is one possible QOL feature=
* It probably makes sense to record possible development in a spreadshe= et and vote on priorities
* Are we ready to start porting over some of t= he functional tests? This should be technically possible, so we should expl= ore this.
* Dockerfile patch for DTS will possibly be a part of 23.11 DT= S roadmap - Thomas will try to review this in August
* Can more DTS patc= hes be merged =E2=80=9Cmid release=E2=80=9D to make the DTS development pro= cess more dynamic?
=C2=A0 =C2=A0* This should be possible - make sure to= utilize slack and CC Thomas
=C2=A0 =C2=A0* Thomas will be the one to me= rge patches for DTS in the near future
=C2=A0 =C2=A0 =C2=A0 * Can this r= esponsibility be deferred to someone else? Thomas is going to discuss this = with the tech board at Dublin. In general Thomas would like to recruit more= subtree maintainers.
=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
* PW will be upg= raded by Ali Alnubani on the first sunday after the 23.07 release, which sh= ould be this Sunday
* Next meeting is August 3, 2023
--000000000000c4e8430600ee5768--