Re: [dpdk-dev] [RFC PATCH 0/1] Dataplane Workload Accelerator library

[Jerin Jacob <jerinjacobk@gmail.com>]

On Wed, Oct 20, 2021 at 2:12 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Wed, 20 Oct 2021 01:06:10 +0530
> Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> > On Wed, Oct 20, 2021 at 12:38 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > 19/10/2021 20:14, jerinj@marvell.com:
> > > > Definition of Dataplane Workload Accelerator
> > > > --------------------------------------------
> > > > Dataplane Workload Accelerator(DWA) typically contains a set of CPUs,
> > > > Network controllers and programmable data acceleration engines for
> > > > packet processing, cryptography, regex engines, baseband processing, etc.
> > > > This allows DWA to offload  compute/packet processing/baseband/
> > > > cryptography-related workload from the host CPU to save the cost and power.
> > > > Also to enable scaling the workload by adding DWAs to the Host CPU as needed.
> > > >
> > > > Unlike other devices in DPDK, the DWA device is not fixed-function
> > > > due to the fact that it has CPUs and programmable HW accelerators.
> > > > This enables DWA personality/workload to be completely programmable.
> > > > Typical examples of DWA offloads are Flow/Session management,
> > > > Virtual switch, TLS offload, IPsec offload, l3fwd offload, etc.
> > >
> > > If I understand well, the idea is to abstract the offload
> > > of some stack layers in the hardware.
> >
> > Yes. It may not just HW, For expressing the complicated workloads
> > may need CPU and/or other HW accelerators.
> >
> > > I am not sure we should give an API for such stack layers in DPDK.
> >
> > Why not
> This is the problem of should DPDK reinvent higher protocol layers?
> Given the myriad of other projects using DPDK that already provide these
> protocols; the de facto decision has been to not add higher layers.
>
> The boundary between DPDK and OVS, VPP, yastack, ... has stayed roughly
> the same for several years. If DPDK starts to overlap these other projects
> it makes life harder.

The intention is to NOT replace these projects, instead, the intention
is to use these projects in the accelerator.
There is a subtle difference between defining the workload vs
implementing the workload.
This RFC attempts the former.

I am trying to address the use case where the end-user needs to
offload a workload
to the accelerator, which contains a set of CPUs, Network controllers
and programmable data acceleration
engines for packet processing, cryptography, regex engines, baseband
processing, etc.

Offload is expressed in very high-level TLV messages. Accelerator
picks these messages,
and using the above technologies to implement it in acceleration HW.
This enables offloading the workloads from the Host CPU.

There are discrete attempts to solve this problem in isolation like
https://github.com/att/sessionOffload.
If you see the above workload the application cares for very
high-level messages for
AddSession, DeleteSession, GetSession, SendStats etc and leave the
accelerator for _implementing_ those workloads.

In order to enable the above use case, the following items need to be
sorted out:
1) Communication between Accelerator and host CPU application
2) Implement the workload in Accelerator

Since this is anyway discussed in today's TB meeting. I am sharing my
thoughts here.

IMO, There are two ways to do it:

Way 1:
1) Introduce libraries specific to accelerator communication like
gpudev, xpudev, dpudev etc
2) Implement the workload in accelerator specific fashion in the application.

Pros:

Cons:
- Need for introducing multiple libraries for specific accelerator
communication in DPDK
- Specific application needs to be written for each accelerator that
needs to be offloaded.


Way 2:
1) Introduce the generic library for accelerator communication.
2) Application express the workload in a non-accelator specific fashion and let
the accelerator implementation(Dont have the requirement to add it in
DPDK code base) implement
the functional model.


Pros:
-  The same DPDK application can use to offload various accelerator technologies
-  More contributors can use the library as it is no specific one type
of accelerator device

Cons:


















>
> If the HW support crosses over between projects it gets very complex.
>