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

[Jerin Jacob <jerinjacobk@gmail.com>]

On Tue, Nov 2, 2021 at 9:35 PM Ananyev, Konstantin
<konstantin.ananyev@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/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

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