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