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

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<snip>

> 
> 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.
+1

> 
> 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.
Agree, this was captured in [1]

[1] https://dpdkna2019.sched.com/event/WYBw/custom-meta-data-in-pmds-honnappa-nagarahalli-arm

The other benefit is that, projects like VPP do not have to maintain their own driver code. So, at a big picture level, we (the humanity 😊) save on effort.

> 
> The disadvantages I can think about:
> - Opening a new API layer is adding more work for everybody
>   (development, test, maintenance).
Documentation to capture descriptor format.

> - Applications must duplicate a part of the DPDK datapath.
> - Lack of consistency between the configuration APIs
>   and the datapath implemented by the application.
I did not understand this, can you please elaborate?
Since the datapath is completely implemented in the application, the responsibility of keeping it updated with the features added by the configuration APIs remains with the application.

> 
>