DPDK patches and discussions
 help / color / mirror / Atom feed
From: Patrick Robb <probb@iol.unh.edu>
To: dev <dev@dpdk.org>
Cc: ci@dpdk.org, dts@dpdk.org
Subject: DTS WG Meeting Minutes - July 18, 2024
Date: Tue, 23 Jul 2024 11:48:55 -0400	[thread overview]
Message-ID: <CAJvnSUD7uivFTiNb7KFEkg8dBwCiLyFObBrXpAee2i5uM6z4cQ@mail.gmail.com> (raw)

July 18, 2024

#####################################################################
Attendees
* Patrick Robb
* juraj.linkes@pantheon.tech
* paul.szczepanek@arm.com
* Jeremy Spewock
* Dean Marx
* Nicholas Pratte
* Alex Chapman

#####################################################################
Minutes

=====================================================================
General Announcements
* DPDK CFP deadline is 07/31
   * UNH is going to propose a 10 minute talk
* Going to improve the statistics.txt which DTS outputs. Should be
able to largely do the same thing as the json files which old DTS
outputs.
   * https://bugs.dpdk.org/show_bug.cgi?id=1363
   * Patrick Robbto comment with any suggestions
* UNH is starting to experiment with the flow API and writing
testsuite(s) for it.
   * Having some difficulty checking device capabilities. There is a
testpmd validate function which can be run for flow rules, but
behavior from NICs after applying flow rules seems unreliable - we
need to dig more and figure out whether our implementation is poor,
testpmd support for flow api is poor, driver flow rule validation is
lacking, or something else.

=====================================================================
Patch discussions
* Thomas has indicated he will look at the DTS patches which are
ready(docs gen, testpmd context manager, interactive shell output
gathering) this week for RC3
* Docs generation
   * Thomas is going to provide a review
   * The part where we link the DTS api docs with the Doxygen landing
page needs to be reviewed, so there is a link from DPDK docs to the
DTS docs.
* Testpmd context manager
   * Has been reviewed by everyone and is final
* Improve interactive shell output gathering
   * Ready
* Capabilities patch
   * Almost ready, but Juraj
      * needs to add support for getting capabilities from show port info
      * Show rxq info vs show rx_queue offload. Which is needed for
our testcase?
      * There was an email send in the Spring about checking for
scatter capability
      * Juraj is looking into the scatter capabilities more:
         * Jeremy: The first testcase should be based on what the port
natively supports (maybe show rxq info {port} {queue}), and the second
testcase should be based on whether the scatter capability can be
offloaded to the NIC (show port {port} rx_offload capabilities)
      * It should be possible to check capabilities for the flow API
too by using the testpmd flow rule validate command. Once we are
confident with the rte_flow testsuite, we can add this part
* Queue_Region testsuite:
   * Tests some comments in testpmd for the i40e driver
   * This uses a private API, and is exclusively for i40e
   * The driver feature is not supported in DPDK
   * It makes sense to avoid working on this testsuite for now, but we
can come back to it
* Blocklist:
   *  UNH needs to provide a tested-by tag and reviews tag once it’s
ran on our hardware
* Mac Filter:
   * Jeremy has provided a review, reviews from others requested
* Dual VLAN
   * Basically the same as the single VLAN testsuite which Dean has
submitted, but for 2 VLANs
   * There was a testcase for extended VLANs in old DTS. And a comment
that says that extended VLANs makes filtering “work normally” on
i40e... it’s not clear what this means, but the VLAN strip, insert,
and filter functions should work without extended VLAN range.
   * TPID support can come with a future version of this testsuite,
but would include implementation of a capability check
* Speed Capabilities:
   * Alex is looking at this testsuite, but it relies on defining a
testsuite config file, something not needed for all other testsuites
written so far
* Dynamic queue is out waiting for review
* Jumbo frames
   * Waiting on Ferruh to get back on the issue Nick was facing
      * Hoping that he will be able to expand more on what
–max-pkt-len is trying to do and why it doesn’t completely work.
         * The command seems to be shaving off certain number of bytes
from the MTU (seemingly in an attempt to account for different PMDs
supporting different ethernet overheads)

=====================================================================
Bugzilla discussions
* None

=====================================================================
Any other business
* Next meeting Aug 1, 2024

                 reply	other threads:[~2024-07-23 15:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJvnSUD7uivFTiNb7KFEkg8dBwCiLyFObBrXpAee2i5uM6z4cQ@mail.gmail.com \
    --to=probb@iol.unh.edu \
    --cc=ci@dpdk.org \
    --cc=dev@dpdk.org \
    --cc=dts@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).