DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: dev@dpdk.org
Cc: techboard@dpdk.org
Subject: [dpdk-dev] DPDK techboard minutes of February 26
Date: Thu, 05 Mar 2020 09:53:24 +0100	[thread overview]
Message-ID: <2059150.ZfL8zNpBrT@xps> (raw)

Minutes of Technical Board meeting, 2020-02-26

Members Attending: 9/11
  - Ferruh Yigit
  - Hemant Agrawal
  - Honnappa Nagarahalli
  - Jerin Jacob
  - Kevin Traynor
  - Konstantin Ananyev
  - Olivier Matz
  - Stephen Hemminger
  - Thomas Monjalon (Chair)

NOTE: Technical Board meetings happen every second Wednesday
on IRC channel #dpdk-board, at 3pm UTC.
Meetings are public and DPDK community members are welcome to attend.


1/ Technical Board status for the Governing Board meeting

  - ABI compatibility and tooling
  - SPDX conversion almost complete
  - Stepping away from Linux out-of-tree modules - new dpdk-kmods repo
  - Project scope discussion
  - PMDT project - new acceptance guidelines
  - Tooling trend (tracing, dumps, metrics, telemetry, monitoring)
  - ICC support: warning is not fatal
  - Windows port is progressing
  - new device classes: vDPA and regex
  - IPsec integration is difficult and progressing
  - Security pre-release list is not growing a lot
  - not tried any mentoring program this year


2/ Doc maintenance

Not much activity on documentation:
  - no content improvement
  - hard to get good reviews

Volunteers are welcome.

Maintenance of the documentation becomes a recurring techboard topic.


3/ Community lab goals

The Governing Board is evaluating how to progress with DPDK CI.
The Technical Board had to provide status and goals.

The first CI priority was already agreed in previous meeting:
basic ethdev functional testing on real NICs.

Coverity is doing static analysis regularly.
Travis is testing (requires integration for per-patch report):
  - compilation
  - ABI
  - libraries (without traffic)
OBS could be integrated for per-patch compilation testing.
The community lab is testing (for each patch):
  - compilation on more OSes
  - libraries (without traffic)
  - micro-benchmark with traffic on real HW
  - downstream projects (OVS, SPDK)

Key benefits of the community lab are:
  - real HW
  - vendor neutrality
  - confidence

The ideal lab should meet these requirements:
  - reliable
  - neutral
  - transparent visibility
  - coverage summary
  - trending graphs
  - easy to add/run a test
  - easy to reproduce a test locally
  - email reports
  - per-patch testing integrated with patchwork
  - per-commit testing (after merge in master or next-*)
  - per-release (including -rc) testing
and should run these tests:
  - compilation
  - functional
  - performance
  - interoperability
  - portability
  - downstream projects

Three roles are identified.
  1) Lab management: hosting, physical setup, monitoring.
  2) Framework/Infrastructure (can be remote):
     test integration, database, logs, reports, graphs, web pages.
  3) development of test cases:
     writing and/or evaluating test code for existing features.
     Future features could be gated by test requirement.

The third role require community involvement and volunteering.


4/ rte_graph + DPDK scope

The new library rte_graph is accepted to be part of dpdk.org.

During the next meeting, it will be discussed whether
adding rte_graph and similar libraries in the main repository,
or splitting in different git repositories.
The question of possibly dead/unused code in some libraries
should be debated as well.



                 reply	other threads:[~2020-03-05  8:53 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=2059150.ZfL8zNpBrT@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=techboard@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).