[dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

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).