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