[dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
Ananyev, Konstantin
konstantin.ananyev at intel.com
Tue Nov 2 16:39:51 CET 2021
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/DM6PR12MB41079FAE6B5DA35102B1BBFACDB79@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).
More information about the dev
mailing list