Re: [dpdk-dev] [RFC] Accelerator API to chain packet processing functions

[Jerin Jacob <jerinjacobk@gmail.com>]

On Fri, Mar 13, 2020 at 11:30 PM Coyle, David <david.coyle@intel.com> wrote:
>
> >
> > On Fri, Mar 6, 2020 at 8:25 PM Coyle, David <david.coyle@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