> >
> > /** Error Detection Algorithms */
> > enum rte_rawdev_multi_fn_err_detect_algorithm {
> >         RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH,
> 
> IMO, It does not make sense to add protocol specific stuff in rawdev
> symbols.
> 
> IMO, It is better to have a separate library for CRC and BIP32 acceleration 
> like
> the rte_security library and underneath still it can use rawdev or anydev if
> required.

[DC] This protocol stuff is only in the rawdev interface definition, which is 
known only to the application and the rawdev PMDs which will use this interface.
So these defines/enums/structs etc for CRC and BIP are completely opaque to 
rte_rawdev itself.

This is how all existing rawdev PMDs interfaces are defined, where the 
interface is very specific to the job(s) the PMD is implementing.

Also, these particular defines/enums/structs for CRC and BIP are only for 
defining xform and op chains containing these particular operations.
The actual code to do the CRC and BIP is already in the AESNI-MB library or 
DPDK rte_net_crc library, which our aesni_mb and qat rawdev PMDs will call/use

> 
> IMO, Exposing the public API in
> drivers/raw/common/rte_rawdev_multi_fn.h is a shortcut.
> IMO, public API should be in lib/..

[DC] To be honest, I tend to agree. I don't like that public APIs are exposed 
from the drivers directory.
But as I mentioned above, this is how all rawdev PMD interfaces are defined, 
where the interface definition is within the PMD directory (e.g. 
drivers/raw/dpaa2_cmdif/rte_pmd_dpaa2_cmdif.h)
Our's is slightly different in that we have 2 PMDs which will use the same 
interface, which is why we have added it in drivers/raw/common
So by keeping our interface under drivers, we are trying to be consistent with 
all existing rawdev PMDs

As I mentioned in my previous post though, this could potentially be moved 
under lib in the future if other PMDs would find it useful

We could possibly rename our interface file to rte_pmd_multi_fn.h to be a bit 
more consistent with the majority of the existing PMDs and take away the idea 
for now that this is some kind of extension to the main rte_rawdev API.
But unfortunately there is no full consistency in the rawdev PMD interface 
filenames (e.g. dpaa2_cmdif uses the "rte_pmd_" prefix - rte_pmd_dpaa2_cmdif.h, 
octeontx2_dma uses the "_rawdev" suffix - otx2_dpi_rawdev.h)

> 
> Just my 2c.

Reply via email to