Hi Akhil,
> > diff --git a/drivers/baseband/fpga_5gnr_fec/Makefile
> > b/drivers/baseband/fpga_5gnr_fec/Makefile
> > index 3f5c511..b68a79f 100644
> > --- a/drivers/baseband/fpga_5gnr_fec/Makefile
> > +++ b/drivers/baseband/fpga_5gnr_fec/Makefile
> > @@ -23,4 +23,7 @@ LIBABIVER := 1
> > # library source files
> > SRCS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC) +=
> > rte_fpga_5gnr_fec.c
> >
> > +# export include files
> > +SYMLINK-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC)-include
> +=
> > fpga_5gnr_fec.h
> > +
> > include $(RTE_SDK)/mk/rte.lib.mk
> > diff --git a/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
> > b/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
> > new file mode 100644
> > index 0000000..7eebc7d
> > --- /dev/null
> > +++ b/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
> > @@ -0,0 +1,74 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2020 Intel Corporation */
> > +
> > +#ifndef _FPGA_5GNR_FEC_H_
> > +#define _FPGA_5GNR_FEC_H_
> > +
> > +#include <stdint.h>
> > +#include <stdbool.h>
> > +
> > +/**
> > + * @file fpga_5gnr_fec.h
> > + *
> > + * Interface for Intel(R) FGPA 5GNR FEC device configuration at the
> > +host level,
> > + * directly accessible by the application.
> > + * Configuration related to 5GNR functionality is done through
> > + * librte_bbdev library.
> > + *
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice */
>
> The exposed PMD header files are normally prefixed as rte_pmd_
>
> You should rename your other header file as fpga_5gnr_fec.h And this one as
> rte_pmd_fpga_5gnr_fec.h
>
OK
> BTW what is the need of a pmd API to configure the fpga?
> Is it not possible to do that as one of rte_bbdev_ops ?
This configuration is done agnostically of bbdev, the application doesn't need
to know there is actual HW device requiring to be configured below the hood.
Also this operation would be possible for the VF driver which doesn't have
access to related registers.
Typical deployment is within a container environment and this configuration is
done without any need of any dependency on anything from librte_bbdev.
Something we were considering was to push a standalone application (without
dependency on BBDEV or even DPDK) to do that configuration from PF.
Currently DPDK community are only able to run the PF driver, since to run from
the VF would need a separate application to configure the device to allow usage
from VF.
We need to provide such application externally to DPDK currently (pretty much
that function wrapped up with args and xml parsing).
So we were wondering whether this could still be provided with DPDK (even if
application has no DPDK dependency) or just push it externally on git hub. I
see pros and cons, any view on that or similar concern for other crypto drivers?
>
> I can see that the comments in rte_bbdev_ops are not in proper format.
> '<' should not be there if comment is before the element Could you please
> correct them in a separate patch? Please check other structures as well
>
Thanks. This was missed all over the place, will make a ticket for fixing in
separate patch.
For now will fix in that new serie today.
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +/**< Number of Virtual Functions FGPA 4G FEC supports */ #define
> > +FPGA_5GNR_FEC_NUM_VFS 8
> > +
> > +/**
> > + * Structure to pass FPGA 4G FEC configuration.
> > + */
> > +struct fpga_5gnr_fec_conf {
> > + /**< 1 if PF is used for dataplane, 0 for VFs */
> > + bool pf_mode_en;
> > + /**< Number of UL queues per VF */
> > + uint8_t vf_ul_queues_number[FPGA_5GNR_FEC_NUM_VFS];
> > + /**< Number of DL queues per VF */
> > + uint8_t vf_dl_queues_number[FPGA_5GNR_FEC_NUM_VFS];
> > + /**< UL bandwidth. Needed for schedule algorithm */
> > + uint8_t ul_bandwidth;
> > + /**< DL bandwidth. Needed for schedule algorithm */
> > + uint8_t dl_bandwidth;
> > + /**< UL Load Balance */
> > + uint8_t ul_load_balance;
> > + /**< DL Load Balance */
> > + uint8_t dl_load_balance;
> > + /**< FLR timeout value */
> > + uint16_t flr_time_out;
>
> If you are adding comment before the element, then no need to add '<'
