26/06/2020 08:55, Jerin Jacob: > On Fri, Jun 12, 2020 at 8:10 PM Fan Zhang <roy.fan.zh...@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.zh...@intel.com> > > Signed-off-by: Piotr Bronowski <piotrx.bronow...@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.
