DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: dev@dpdk.org
Subject: Minutes of Technical Board Meeting, 2021-11-17
Date: Wed, 24 Nov 2021 14:00:03 +0100	[thread overview]
Message-ID: <YZ43U36bFWHYClAi@platinum> (raw)

Members Attending
-----------------

- Aaron
- Bruce
- Ferruh
- Honnappa
- Jerin
- Kevin
- Konstantin
- Maxime
- Olivier (Chair)
- Stephen
- Thomas

NOTE: The technical board meetings every second Wednesday at
https://meet.jit.si/DPDK at 3 pm UTC.
Meetings are public, and DPDK community members are welcome to attend.

NOTE: Next meeting will be on Wednesday 2021-12-01 @3pm UTC, and will
be chaired by Stephen.

1. Switch to 3 releases per year instead of 4
=============================================

Reference: http://inbox.dpdk.org/dev/5786413.XMpytKYiJR@thomas

Only good feedback on the mailing list up to now.

This proposal is therefore accepted - so DPDK will only have 3 releases
in 2022 - unless there is strong opposition, with suitable
justification, raised on the DPDK Dev mailing list ahead of the final
DPDK 21.11 release.

2. Raise the maximum number of lcores
=====================================

References:

- https://inbox.dpdk.org/dev/1902057.C4l9sbjloW@thomas/
- https://inbox.dpdk.org/dev/CAJFAV8z-5amvEnr3mazkTqH-7SZX_C6EqCua6UdMXXHgrcmT6g@mail.gmail.com/

Modifying this value is an ABI change and has an impact on memory
consumption. There is no identified use-case where a single
application requires more than 128 lcores.

- Ideally, this configuration should be dynamic at runtime, but it would
  require a lot of changes
- It is possible with the --lcores EAL option to bind up to 128 lcores to
  any lcore id (even higher than 128). If "-l 129" is passed to EAL, a
  message giving the alternative syntax ("--lcores 0@129") is
  displayed. An option to rebind automatically could help for usability.
- If a case a use-case exists for a single application that uses
  more than 128 lcores, the TB is ok to update the default config value.
  Note that it is already possible to change the value at compilation
  time with -Dmax_lcores in meson.

3. New threading API
====================

References:

- https://patches.dpdk.org/project/dpdk/list/?series=20472&state=*
- https://inbox.dpdk.org/dev/1636594425-9692-1-git-send-email-navasile@linux.microsoft.com/

The DPDK relies on the pthread interface for eal threads, which is not
supported in windows. Windows DPDK code currently emulates pthread. A
patchset has been proposed which, among others:

- makes the eal thread API rely on OS-specific
- removes direct call to pthread in dpdk

This patchset (not for 21.11) needs more reviews. People from TB should
take a look at it.

The TB provided some guidelines:
- the EAL thread API level should be similar to pthread API
  (it would mostly be a namespace change for posix)
- the API/ABI should remain compatible. It is possible to make use of
  rte_function_versioning.h for that

4. DTS Co-maintenance
=====================

Owen Hilyard from UNH proposes himself to be the co-maintainer for DTS.
This would for instance help to ensure that the interface between CI
and DTS remains stable.

The TB welcomes this proposition, as long as there is no opposition from
current DTS maintainer and DTS community.

By the way, the TB asks for volunteers to help to make the transition to
DPDK repository.

5. Spell checking in the CI infrastructure and patchwork
========================================================

The spell checking was done with aspell on documentation. The problem is
that check is done on everything including code or acronyms, resulting
on constant failures.

The TB recommends to focus on per-patch basis checks, on rst files
first. A tool should be provided in dpdk/devtools, so it can also be
used by developpers.

Spelling errors should be considered as warning given code or acronyms
may trigger false-positives.

                 reply	other threads:[~2021-11-24 13:00 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=YZ43U36bFWHYClAi@platinum \
    --to=olivier.matz@6wind.com \
    --cc=dev@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).