On Fri, Mar 13, 2020 at 11:30 PM Coyle, David <david.co...@intel.com> wrote: > > > > > On Fri, Mar 6, 2020 at 8:25 PM Coyle, David <david.co...@intel.com> wrote: > > > > > > > > > > > > > /** 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. > > > > If you see .map file in driver/raw/. None of the drivers are exposing any > > API > > with rte_rawdev_*. > > This addition will be exposing new rte_rawdev_* APIs from driver/rawdev/. > > That's is not correct. > > > > $ find drivers/raw/ -name *.map > > drivers/raw/skeleton/rte_rawdev_skeleton_version.map > > drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map > > drivers/raw/ntb/rte_rawdev_ntb_version.map > > drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map > > drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map > > drivers/raw/ioat/rte_rawdev_ioat_version.map > > drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map > > drivers/raw/ifpga/rte_rawdev_ifpga_version.map > > > > IMO, Correct thing to do will be, > > > > Either of > > > > 1) As mentioned below, If you would like to limit the scope only to a new > > rawdev driver then > > a) Create a new driver at driver/raw/<new driver>/ > > b) expose the drier specific customer API as > > rte_<new-driver>_...(example: > > drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map > > > > 2) If we would like to have public API then create a subsystem like > > libsecurity > > to have features. Let the API exposed from lib/... > > > > [DC] Yes you are right here, it was incorrect to include rawdev in the > interface filename and in the symbols within... rawdev will be removed from > all these > And we are going with option 1 above, to limit this to the new rawdev drivers. > As I mentioned in the original post, if it is found that this interface could > be useful to other drivers/applications in the future, then it can be moved > to the public API under lib as a new library or an extension of an existing > one possibly
+1