<snip> > > > > Hi Jerin, > > > > 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/DM6PR12MB41079FAE6B5DA35102B1BBFACDB7 > 9...@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? > > I'd say (4) is a good thing to have. > Will allow people to try/test DWA approach and framework itself without > access to specific HW. Agree in general it is good as a standard of the expected behavior. But, it might be difficult/complex to implement all the profiles. For ex: L1 processing for 5G.
> > > [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). > > > > > >
