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

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

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

From my understanding, Jerin talks about
SW implementation for only one profile for now (L3FWD).

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