Tech Board Meeting Minutes - 2024-Oct-16

[Bruce Richardson <bruce.richardson@intel.com>]

Members Attending
-----------------
Bruce Richardson
Jerin Jacob
Kevin Traynor
Konstantin Ananyev
Maxime Coquelin
Morten Brørup
Stephen Hemminger
Thomas Monjalon

NOTE: The technical board meetings are on every second Wednesday at 3pm
UTC.  Meetings are public, and DPDK community members are welcome to
attend.  Agenda and minutes can be found at
http://core.dpdk.org/techboard/minutes

Next meeting will be on Wednesday 2024-Oct-30 @ 3pm UTC, and will be
chaired by Hemant

Agenda Items
============

- UNH DPDK Lab retrospective for 2024.
  - Patrick Robb from lab gave a readout on the lab activities for 2024
  - Report:
    https://drive.google.com/file/d/1tBrQwXNDDNKRB5lQmkUU75Hh9JdgKFXa/view?usp=sharing
  - NOTE: items highlighted are items still in progress as of this week.

- UNH DPDK Lab plans for 2025
  - The community lab Statement of Work (SOW) needs to be drafted before
    end of October
  - Patrick will work with Aaron and Technical board in drafting this in
    the coming days and weeks.

- Next-net maintainership
  - Due to other commitments, Ferruh has stepped aside as maintainer of
    the next-net tree for at least the 25.03 DPDK release
  - Techboard thanks Ferruh for his great work maintaining this tree
    over the years!
  - Stephen H. has volunteered to take over the tree for the 25.03
    release, as an interim maintainer
  - Community needs to identify at least 1, though ideally 2, new
    maintainers for the next-net tree

- Discussion on proposal to move flow-configuration parts of the
  net/mlx5 driver to a binary component:
  - Proposal is that the hardware steering low-level management
    functionality, for newer devices only, be moved to a binary library.
      - Not all flow configuration would move
      - Older devices would be unaffected, as they don't support this
        anyway
      - All devices have alternative (slower) path of steering using
        rdma-core dependency.
  - Such a change would be treated as a deprecation of the current
    driver model, with pre-announcement before the change to use binary
    lib.
  - Concern expressed that such a change is not a positive step for the
    community, and TB would like to ensure other drivers do not take the
    same approach.
  - Concern expressed over the change of state for an existing driver -
    what will happen on upgrade of DPDK if new binary component is
    missing?
  - There was discussion of previously agreed - but never published -
    guidelines for accepting drivers with a binary component into DPDK. 
      - Feeling was that there was nothing in the proposal that was
        outside the scope of what was previously agreed.
  - Concern expressed over the downstream impacts of this change - how
    would distros be able to package the driver.
  - Suggestion was made that, since the proposed binary dependency would
    only be for rte_flow offload, the rest of the driver could still
    build and function without the binary - and therefore without
    rte_flow support.
  - Questions were raised around how an optional dependency for certain
    functionality, like rte_flow, would be documented in our NIC driver
    documentation, especially the feature table.
  - Comparisons were drawn with existing CUDA driver dependency, and it
    was suggested that that may serve as the model which may be followed
    here:
      - The library headers could be hosted in a public repository which
        would serve as the place to report compilation issues.
      - Email contact was also suggested as an alternative.
  - The kernel approach to binary drivers was reviewed:
      - if a binary driver component is in use on a system, then all
        kernel issues on that system are the responsibility of the
        binary driver vendor - since others cannot know what impacts
        the driver may have, even on unrelated components or subsystems.