On Tue, Nov 2, 2021 at 9:35 PM Ananyev, Konstantin <konstantin.anan...@intel.com> wrote: > > 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
Now that there is approval from TB. I would like to ask, Is anyone planning to review the specification header file [1]? There was a comment to remove the TLV length. I will do that next version with implementation. Identified the following set of work for this. 1) Common code at lib/dwa/ 2) Marvell DPU based driver at drivers/dwa/cnxk/ 3) Test application at app/test-dwa/ 4) It is possible to have an SW driver(To allow non-specialized HW to use the framework) for this by: a) Emulate DWA HW as a separate DPDK process b) Add drivers/dwa/sw/ and use memif driver so to create a communication channel between emulated DWA HW process and DPDK application. c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile using DPDK libraries for SW driver. I think, Item (4) aka SW drivers as useful(We don't need to implement for all profiles, I think, just for l3fwd it make sense to add, to allow to use of the framework in just SW mode). Is there any opinion on adding item (4) in DPDK? I saw mixed opinions earlier on this. I would like to understand, Is there any objection to doing item(4) in DPDK as it needs a good amount of work and I don't want to do throw it away if the community doesn't like this. Any opinion? [1] http://mails.dpdk.org/archives/dev/2021-October/226070.html > 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). > >
