DPDK-dev Archive mirror
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: dev@dpdk.org, techboard@dpdk.org
Subject: Minutes of Technical Board meeting 17-April-2024
Date: Fri, 03 May 2024 09:54:26 -0400	[thread overview]
Message-ID: <f7to79nc86l.fsf@redhat.com> (raw)

Next Meeting will be May 15th, with Bruce as chair.

Attendees
---------
- Aaron (chair)
- Morten Brorup
- David Marchand
- Konstantin Ananyev
- Tyler Retzlaff
- Mykola Kostenok
- Paul Szczepanik
- Kevin Traynor
- Jerin Jacob Kollanukkaran
- Nathan Southern
- Patrick Robb
- Stephen Hemminger
- Bruce Richardson
- Honnappa Nagarahalli
- Nathan Southern
- Ben Thomas


Topics
------
 - MSVC VLAs
   - Tyler mentioned this is a blocking issue currently
     MSVC does not support VLAs and is not going to support VLAs
   - All supported compilers, including MSVC support using
     'alloca' as an alternative to VLAs, but there is resistance
     to using 'alloca'.
   - Asking for input on how to resolve the issue
   - Stephen advocates fixing the libraries not to use VLAs
     where drivers may be addressed later.
     - Tyler has been working on changing some of the
       libraries
   - Bruce, plan to replace the minimum set seems reasonable
   - Konstantin, alloca looks unavoidable in some cases and
     isn't in favor of just blanket replacing it via grep.
   - If there is an obvious replacement for the pattern being
     used, then use it, otherwise maybe look to use static arrays
     to synthesize an alloca, or other techniques.
   - Tyler to continue working and will put series forward

 - QUIC library to support HW Offload
   - Ask is from the Gov board, and don't have many details
   - Looking for an owner for this effort

 - TCP Optimization for ML/AI use cases
   - Linux kernel does have some kind of story here
   - Looking for an owner for this effort

 - Kernel header import
   - Maxime proposes to automate importing the Linux
     kernel uAPI headers
   - Background:
     - Current process need to redefine the same things which
       exist, or have a current kernel tree for the vduse
       drivers.
   - Concerns:
     - Headers for the uAPI have some kinds of licensing
       exceptions
     - Need clarification from Gov board about including the
       uAPI licensed headers.
     - There ends up being issues with maintainership, which
       versions of headers are included, whether there are
       kinds of issues with version compatibility.
     - QEMU currently does the same as Maxime has confirmed.
       QEMU seems to only copy the headers needed and updates
       them only when needed.
     - Alternative, can we have DPDK build to point to a
       different kernel header file location?
       This does introduce its own issues (who is responsible for
       compilation failures, etc).  Adding a fixed version in the
       tree avoids the problem of pointing to a tree.
     - Have a mechanism to download headers?
       Also has issues - what URL to use?  Kernel headers can't
       come directly from git, need to be sanitized via
       make headers-install
   - Open Questions:
     - Can we ask the gov board for clarification?
   - Agree to move to the mailing list for discussion

 - Coding Challenge
   - Ben ran a poll on social media, positive response to the
     idea of coding challenge.
   - Interest looks like rust integration was highest, then
     protocol integration, ai- integration, and others following
   - Rust seems to generate the most interest?
   - Questions:
     - When is it supposed to happen?
       - Next step is to present to Gov Board to get logistics
         resolved, so best guess is Q3
     - How long would it last?
       - Scope is quite large for 'rust integration', and it is
         not clear what the challenge and scope would be.
       - Trying to get it in time for Summit.
   - Stephen, wants to make sure each time gets attention,
     ownership, and movement.
   - Ben will present the details to the Gov Board

 - Next meeting date scheduled for 15-May
   - voted

 - Mykola has questions about submitting for a refactored PMD series
   - Answered some live, referred to the guides in the documentation
     as well.
   - Plan to send a simpler version of the PMD
     - Include any restrictions in docs
   - Trying to understand the deadlines as well for the PMD
     submissions
     - Drivers generally get merged in -RC2
     - Suggestion is to post patches early because reviews will take
       some time.

  - Update on the Gov Board events votes:
    - Approved Bangkok event in July
      - Will work on aggressively promoting because there isn't
        much time left to promote.
      - Webinar event was attended 1/2 by members of APAC, so
        it should be good.
    - Montreal event in fall will be covered with Gov Board again
      on April 30.
      - Date has been difficult, but looks to be 24-Sep


             reply	other threads:[~2024-05-03 13:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-03 13:54 Aaron Conole [this message]
2024-05-03 15:24 ` Minutes of Technical Board meeting 17-April-2024 Ferruh Yigit

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=f7to79nc86l.fsf@redhat.com \
    --to=aconole@redhat.com \
    --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 read-only IMAP folder(s) and NNTP newsgroup(s).