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

[Thomas Monjalon <thomas@monjalon.net>]

30/06/2020 22:33, Honnappa Nagarahalli:
> 26/06/2020 12:38, Thomas Monjalon:
> > 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.

If you update a PMD strategy in a configuration step,
the app datapath can become out of sync.