Re: [dpdk-dev] [dpdk-techboard] [PATCH] crypto/qat: add data-path APIs

[Thomas Monjalon <thomas@monjalon.net>]

26/06/2020 08:55, Jerin Jacob:
> On Fri, Jun 12, 2020 at 8:10 PM Fan Zhang <roy.fan.zhang@intel.com> wrote:
> >
> > This patch adds data-path APIs to QAT symmetric dirver to support
> > raw data as input.
> >
> > For applications/libraries that want to benefit from the data-path
> > encryption acceleration provided by QAT but not necessarily depends
> > on DPDK data-path structures (such as VPP), some performance
> > degradation is unavoidable to convert between their specific data
> > structure and DPDK cryptodev operation as well as mbufs.
> >
> > This patch takes advantage of existing QAT implementations to form
> > symmetric data-path enqueue and dequeue APIs that support raw data
> > as input so that they can have wider usability towards those
> > applications/libraries without performance drop caused by the data
> > structure conversions. In the meantime the less performance-sensitive
> > cryptodev device and session management remains intact so that DPDK
> > cryptodev remains to be unified control path library for QAT.
> >
> > Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> > Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
> > ---
> 
> + Techboard,
> 
> I think, this problem is not specific to QAT nor the crypto subsystem.
> If we are planning to expose the PMD specific descriptors, It would good to get
> general agreement from everyone. Probably we can/need to extend ethdev
> PMDs as well based on the need.
> 
> If we are taking this path, at minimum, we need a generic control path
> API with cryptodev,
> to query such capability. (Probably API to register descriptor and
> query supported descriptor as PMD
> can support multiple descriptors)

I fully agree, it needs to be a community decision.

Today, if an application wants to use DPDK, either it adopts mbuf,
or it pays the cost of mbuf conversion.

The question is: can DPDK provides helpers for a non-mbuf datapath?

The benefit is clear for applications which are not mbuf-centric.

The disadvantages I can think about:
- Opening a new API layer is adding more work for everybody
  (development, test, maintenance).
- Applications must duplicate a part of the DPDK datapath.
- Lack of consistency between the configuration APIs
  and the datapath implemented by the application.