30/06/2020 22:33, Honnappa Nagarahalli:

26/06/2020 12:38, Thomas Monjalon:

quoted

26/06/2020 08:55, Jerin Jacob:

quoted

On Fri, Jun 12, 2020 at 8:10 PM Fan Zhang [off-list ref] wrote:

quoted

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.

quoted

quoted

Signed-off-by: Fan Zhang <redacted>
Signed-off-by: Piotr Bronowski <redacted>
---

+ 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

quoted

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.

quoted

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.

quoted

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