DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
@ 2021-11-02 15:39 Ananyev, Konstantin
  2021-11-11 11:44 ` Jerin Jacob
  0 siblings, 1 reply; 12+ messages in thread
From: Ananyev, Konstantin @ 2021-11-02 15:39 UTC (permalink / raw)
  To: dev; +Cc: techboard

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-11-19  4:35 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-02 15:39 [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27 Ananyev, Konstantin
2021-11-11 11:44 ` Jerin Jacob
2021-11-11 12:32   ` Ananyev, Konstantin
2021-11-12  0:56     ` Honnappa Nagarahalli
2021-11-12  1:46       ` Ananyev, Konstantin
2021-11-12  6:19         ` Jerin Jacob
2021-11-12  2:24   ` Honnappa Nagarahalli
2021-11-12  6:26     ` Jerin Jacob
2021-11-18 15:13       ` Honnappa Nagarahalli
2021-11-18 16:27         ` Jerin Jacob
2021-11-18 20:07           ` Honnappa Nagarahalli
2021-11-19  4:34             ` Jerin Jacob

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).