Minutes of Technical Board Meeting, 2021-Oct-27 Members Attending --------------------------- -Aaron -Ferruh -Hemant -Honnappa -Jerin -Kevin -Konstantin (Chair) -Maxime -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-Nov-03 @3pm UTC, and will be chaired by Maxime. GPUDEV library / DWA library inclusion http://inbox.dpdk.org/dev/dm6pr12mb41079fae6b5da35102b1bbfacd...@dm6pr12mb4107.namprd12.prod.outlook.com/ http://mails.dpdk.org/archives/dev/2021-October/226070.html 1. GPU dev ========= Pros: - simple and clean API - address particular needs: - external (GPU) memory management within DPDK - provides generic framework for CPU-GPU-NIC interaction - Not specific to any particular workload - GPU program creation/upload is out of scope for this framework Concerns: - Framework is specific for just one particular accelerator class (GPU) If we go that way, does it mean we'll need a separate library/API for each new HW device class (FPGA, etc.)? 2. DWA dev ========== Pros: - HW neutral abstraction for accelerator communication - HW neutral abstraction for workload definitions (via profile) - Ability to chain services provided by HW (chain multiple profiles) - Sounds like really good approach for SoCs Concerns: - Not easy to agree/define mandatory/optional features for each particular profile - User limited to particular already implemented profiles (longer time to market, etc.) - Richness of features might cause overcomplication in both internal design/implementation and public API Conclusion ========= At that stage it is really hard to predict which approach will be more successful. As both paths can co-exist within DPDK: 1) Go ahead with both approaches as experimental lib/drivers inside DPDK 2) Re-evaluate both approaches in one year time 3) Both should follow usual DPDK policy for new lib/device classes: generic framework plus at least one driver implementation 4) Both should be usable with open-source tools (no exclusive dependency on third-party proprietary SW).
