On Wed, Oct 20, 2021 at 2:12 AM Stephen Hemminger <step...@networkplumber.org> wrote: > > On Wed, 20 Oct 2021 01:06:10 +0530 > Jerin Jacob <jerinjac...@gmail.com> wrote: > > > On Wed, Oct 20, 2021 at 12:38 AM Thomas Monjalon <tho...@monjalon.net> > > wrote: > > > > > > 19/10/2021 20:14, jer...@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. >
