Members Attending ================= Bruce Richardson Hemant Agrawal Jerin Jacob Konstantin Ananyev Maxime Coquelin Morten Brørup (chair) Stephen Hemminger Thomas Monjalon
NOTE ==== The technical board meetings are on every second Wednesday at 3 pm UTC. Meetings are public. DPDK community members are welcome to attend on Zoom: https://zoom-lfx.platform.linuxfoundation.org/meeting/96459488340?password=d808f1f6-0a28-4165-929e-5a5bcae7efeb Agenda: https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db Minutes of previous meetings: http://core.dpdk.org/techboard/minutes Next meeting will be on: Wednesday 27-May-2026 at 3pm UTC, and will be chaired by: Konstantin Ananyev. Agenda Items ============ 1. Patch backlog and lack of reviews ------------------------------------ The patch backlog has grown from 300 to 500 items. Although the backlog isn't worse than usual, it still needs addressing. Currently, Thomas is the only person reviewing and merging patches for many directories, which sometimes leads to delays in merging. The board agreed to merge patches without full consensus during the early release cycle, as issues could be addressed in later release candidates. It was noted that simple comments and informal feedback on patches is also valuable when considering merging patches without Acked-by or Reviewed-by tags. The board discussed various incentives to get more reviews: gamification, recognition of top reviewers, requiring code contributors to also contribute reviews. To proceed experimenting with some of this, we will try making a dashboard showing the balance of code contributed vs. reviews contributed per contributor. Many of the patches in the backlog lacking review are documentation updates from January. The board discussed creating a documentation maintainer role as a webmaster-like role: responsible for collecting and consolidating content, but not for the content itself. We will seek candidates on the announcement mailing list. 2. Wish List review ------------------- The board reviewed the list of new wishes in Bugzilla: https://issues.dpdk.org/reports?component=wishes&status=UNCONFIRMED The board decided on a process where wishes accepted (possibly for further consideration) by the tech board would be marked with status Confirmed, with a reference to the tech board minutes where discussed. #1905: Reduce memory footprint by using rte_max_lcore instead of RTE_MAX_LCORE Some build-time constants have a large effect on how much memory is allocated by DPDK. The board noted that the max number of lcores is not the only one; e.g. the max number of queues per port has a high effect on memory usage. Getting completely rid of these, and making arrays etc. fully dynamic would be the optimal solution. But replacing them by startup-time variables may be easier to implement. There is no need for individual wishes per build-time constant affecting memory usage. This wish will be considered in broad context, covering all the relevant build-time constants, with flexibility on implementation order, also considering the impact of getting rid of each one. This wish was accepted for the roadmap. #1906: Use DPDK memory for lcore variables The board identified some disadavantages with this proposal; mainly that it would probably consume an additional hugepage TLB entry per thread, instead of a number of ordinary TLB entries. This wish was kept on the wish list for further investigation. #1912: free mbufs should not have next and nb_segs initialized The concept of not requiring any non-constant mbuf fields to be initialized when freeing an mbuf into its mempool, and instead leave initialization to the Rx path of the drivers was discussed. The board was concerned about how such a change would affect performance. The store buffers in many CPUs can handle up to 32 (consecutive) bytes each. So, if the Rx path needs to write more than 32 bytes into the mbuf, it requires more store buffers, which may then become a bottleneck. In the context of performance, an alternative was discussed: The "nb_segs" field (residing in the mbuf's first cache line) can be used as a gate to determine if the "next" field (residing in the mbuf's second cache line) is valid or not. Jerin also emphasized that hardware implementations typically handle memory pooling differently, with automatic freeing on the TX side. This wish was kept on the wish list for further investigation. #1913: Introduce RTE_EAL_INIT_PRIO() alternative to RTE_INIT_PRIO() Introducing a macro to allow libraries (and applications and drivers) to install their initialization functions into hooks at various stages during EAL initialization may help decorrelate library dependencies. This wish was accepted for the roadmap. #1929: Ethdev Tx Completion API Adding a Tx completion capability - with separate transmit stages for descriptor setup and cleanup phases - would be useful for post-processing features, such as packet capture and time stamping. The board was concerned about performance, particularly regarding per-packet completions versus bulk completions. Enabling per-packet notifications would require additional PCI bandwidth and thus impact throughput. Bruce suggested adding a per-packet flag as a potential implementation approach. This wish was kept on the wish list for further investigation. Venlig hilsen / Kind regards, -Morten Brørup
