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

[Jerin Jacob <jerinjacobk@gmail.com>]

On Fri, Nov 12, 2021 at 7:17 AM Ananyev, Konstantin
<konstantin.ananyev@intel.com> wrote:
>
>
> >
> > >
> > >
> > >
> > > 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).

Yes. Only for one profile for now(L3FWD).
We don't have plan for emulating complex profiles like L1 Processing
for 5G.(I believe it is not even possible with the required quality)

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