On 14/04/2020 3:44 PM, Thomas Monjalon wrote:
14/04/2020 16:02, Trahe, Fiona:
Hi Thomas,
From: Thomas Monjalon <tho...@monjalon.net>
14/04/2020 15:04, Trahe, Fiona:
14/04/2020 12:21, Ferruh Yigit:
http://inbox.dpdk.org/dev/mn2pr11mb35507d4b96677a41e66440c5e3...@mn2pr11mb3550.na
mprd11.prod.outlook.com/
I am not convinced.
I don't like rawdev in general.
Rawdev is good only for hardware support which cannot be generic
like SoC, FPGA management or DMA engine.
[Fiona] CRC and BIP are not crypto algorithms, they are error detection
processes.
So there is no class in DPDK that these readily fit into.
There was resistance to adding another xxxddev, and even if one had been added
for error_detection_dev, there would still have been another layer needed
to couple this with cryptodev. Various proposals for this have been discussed
on the ML
in RFC and recent patches, there doesn't seem to be an appetite for this as a
generic API.
So it seems that only Intel has software and hardware engines that provide this
specialised feature coupling. In that case rawdev seems like the most
appropriate vehicle to expose this.
Adding some vendor-specific API is not a good answer.
It will work in some cases, but it won't make DPDK better.
What's the purpose of DPDK if it's not solving a common problem
for different hardware?
The current proposal in rawdev could easily be supported by any hardware
which supports chaining multiple functions/services into a single
operation, in this case symmetric crypto and error detection, but it
could conceivably support chaining symmetric/asymmetric crypto
operations or chaining symmetric crypto and compression operations.
[Fiona] Based on that logic rawdev should be deprecated.
But the community has agreed that it has a place.
No, as I said above, rawdev is good for SoC, FPGA management or DMA engine.
I distinctly remember when rawdev was being proposed one of the uses
cases proposed was that a new classes of APIs could be prototyped and
developed under rawdev and when a solid consensus was reached then
migrated to a mainstream DPDK library. I think every effort has been
made here to engage the community to develop a generic approach. As
Fiona notes there hasn't really been much of an appetite for this.
Therefore I think the option to use rawdev makes sense, it allows an
initial proposal to be deployed, without a generic solution agreement,
it will also give others in the community to see how this approach can
work and hopefully lead to more engagement on a generic solution. Also
as APIs in rawdev are essentially treated as private APIs the onus is on
Intel to support this going forward.
And the common problem here is device exposure.
With a specialised service on top.
Here the intent is to use rawdev because we don't find a good API.
API defeat is a no-go.
[Fiona] It's not that we haven't found a good API, but that there doesn't seem
to be a general requirement for such a specialised API
There is a requirement to combine features of different classes.
[Fiona] Can you point me to that requirement please?
Yes, rte_security is trying to address this exact issue.
I don't agree rte_security addresses the problem of different device
types supporting the same services. The problem being addressed here is
a single device which supports the chaining of multiple services (sym
crypto & error detection)
We suggested it, but did not get community engagement and have
dropped our generic API requirement, instead focussing on this specialised case.
I did not see such generic proposal, sorry.
In the past, rte_security was an "answer" to this issue with crypto and ethdev.
This is a real topic, please let's find a generic elegant solution.
