[dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Maxime Coquelin]

The series prefixes drivers APIs with rte_<drv_name>_ in
order to avoid namespace pollution.

These APIs are experimental, so no need to follow the 
deprecation process.

Maxime Coquelin (2):
  baseband/fpga_5gnr_fec: fix API naming
  baseband/fpga_lte_fec: fix API naming

 app/test-bbdev/test_bbdev_perf.c                   | 12 ++++++------
 doc/guides/bbdevs/fpga_5gnr_fec.rst                | 14 +++++++-------
 doc/guides/bbdevs/fpga_lte_fec.rst                 | 14 +++++++-------
 drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 10 +++++-----
 .../rte_pmd_bbdev_fpga_5gnr_fec_version.map        |  2 +-
 .../baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h |  6 +++---
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.c       | 10 +++++-----
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.h       |  6 +++---
 .../rte_pmd_bbdev_fpga_lte_fec_version.map         |  2 +-
 9 files changed, 38 insertions(+), 38 deletions(-)

-- 
2.26.2

[dpdk-dev] [PATCH 1/2] baseband/fpga_5gnr_fec: fix API naming

[Maxime Coquelin]

DPDK APIs have to be prefixed with "rte_" in order to avoid
namespace pollution.

Let's fix it while fpga_5gnr_fec API is still experimental.

Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
 app/test-bbdev/test_bbdev_perf.c                   |  6 +++---
 doc/guides/bbdevs/fpga_5gnr_fec.rst                | 14 +++++++-------
 drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 10 +++++-----
 .../rte_pmd_bbdev_fpga_5gnr_fec_version.map        |  2 +-
 .../baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h |  6 +++---
 5 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index 45c0d62aca..14f150704e 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -612,14 +612,14 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
 #ifdef RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC
 	if ((get_init_device() == true) &&
 		(!strcmp(info->drv.driver_name, FPGA_5GNR_PF_DRIVER_NAME))) {
-		struct fpga_5gnr_fec_conf conf;
+		struct rte_fpga_5gnr_fec_conf conf;
 		unsigned int i;
 
 		printf("Configure FPGA 5GNR FEC Driver %s with default values\n",
 				info->drv.driver_name);
 
 		/* clear default configuration before initialization */
-		memset(&conf, 0, sizeof(struct fpga_5gnr_fec_conf));
+		memset(&conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
 
 		/* Set PF mode :
 		 * true if PF is used for data plane
@@ -647,7 +647,7 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
 		conf.flr_time_out = FLR_5G_TIMEOUT;
 
 		/* setup FPGA PF with configuration information */
-		ret = fpga_5gnr_fec_configure(info->dev_name, &conf);
+		ret = rte_fpga_5gnr_fec_configure(info->dev_name, &conf);
 		TEST_ASSERT_SUCCESS(ret,
 				"Failed to configure 5G FPGA PF for bbdev %s",
 				info->dev_name);
diff --git a/doc/guides/bbdevs/fpga_5gnr_fec.rst b/doc/guides/bbdevs/fpga_5gnr_fec.rst
index 6760391e8c..5849b31857 100644
--- a/doc/guides/bbdevs/fpga_5gnr_fec.rst
+++ b/doc/guides/bbdevs/fpga_5gnr_fec.rst
@@ -170,12 +170,12 @@ queues, priorities, load balance, bandwidth and other settings necessary for the
 device to perform FEC functions.
 
 This configuration needs to be executed at least once after reboot or PCI FLR and can
-be achieved by using the function ``fpga_5gnr_fec_configure()``, which sets up the
-parameters defined in ``fpga_5gnr_fec_conf`` structure:
+be achieved by using the function ``rte_fpga_5gnr_fec_configure()``, which sets up the
+parameters defined in ``rte_fpga_5gnr_fec_conf`` structure:
 
 .. code-block:: c
 
-  struct fpga_5gnr_fec_conf {
+  struct rte_fpga_5gnr_fec_conf {
       bool pf_mode_en;
       uint8_t vf_ul_queues_number[FPGA_5GNR_FEC_NUM_VFS];
       uint8_t vf_dl_queues_number[FPGA_5GNR_FEC_NUM_VFS];
@@ -214,15 +214,15 @@ parameters defined in ``fpga_5gnr_fec_conf`` structure:
   the FLR time out then set this setting to 0x262=610.
 
 
-An example configuration code calling the function ``fpga_5gnr_fec_configure()`` is shown
+An example configuration code calling the function ``rte_fpga_5gnr_fec_configure()`` is shown
 below:
 
 .. code-block:: c
 
-  struct fpga_5gnr_fec_conf conf;
+  struct rte_fpga_5gnr_fec_conf conf;
   unsigned int i;
 
-  memset(&conf, 0, sizeof(struct fpga_5gnr_fec_conf));
+  memset(&conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
   conf.pf_mode_en = 1;
 
   for (i = 0; i < FPGA_5GNR_FEC_NUM_VFS; ++i) {
@@ -235,7 +235,7 @@ below:
   conf.ul_load_balance = 64;
 
   /* setup FPGA PF */
-  ret = fpga_5gnr_fec_configure(info->dev_name, &conf);
+  ret = rte_fpga_5gnr_fec_configure(info->dev_name, &conf);
   TEST_ASSERT_SUCCESS(ret,
       "Failed to configure 4G FPGA PF for bbdev %s",
       info->dev_name);
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 61f9c04ba2..1d73f9540e 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -1944,10 +1944,10 @@ fpga_5gnr_fec_remove(struct rte_pci_device *pci_dev)
 }
 
 static inline void
-set_default_fpga_conf(struct fpga_5gnr_fec_conf *def_conf)
+set_default_fpga_conf(struct rte_fpga_5gnr_fec_conf *def_conf)
 {
 	/* clear default configuration before initialization */
-	memset(def_conf, 0, sizeof(struct fpga_5gnr_fec_conf));
+	memset(def_conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
 	/* Set pf mode to true */
 	def_conf->pf_mode_en = true;
 
@@ -1962,15 +1962,15 @@ set_default_fpga_conf(struct fpga_5gnr_fec_conf *def_conf)
 
 /* Initial configuration of FPGA 5GNR FEC device */
 int
-fpga_5gnr_fec_configure(const char *dev_name,
-		const struct fpga_5gnr_fec_conf *conf)
+rte_fpga_5gnr_fec_configure(const char *dev_name,
+		const struct rte_fpga_5gnr_fec_conf *conf)
 {
 	uint32_t payload_32, address;
 	uint16_t payload_16;
 	uint8_t payload_8;
 	uint16_t q_id, vf_id, total_q_id, total_ul_q_id, total_dl_q_id;
 	struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
-	struct fpga_5gnr_fec_conf def_conf;
+	struct rte_fpga_5gnr_fec_conf def_conf;
 
 	if (bbdev == NULL) {
 		rte_bbdev_log(ERR,
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map b/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
index d723bc9b0e..db43cd8403 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
+++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
@@ -5,6 +5,6 @@ DPDK_21 {
 EXPERIMENTAL {
 	global:
 
-	fpga_5gnr_fec_configure;
+	rte_fpga_5gnr_fec_configure;
 
 };
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
index 70a4acf0b7..c2752fbd52 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
+++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
@@ -30,7 +30,7 @@ extern "C" {
 /**
  * Structure to pass FPGA 4G FEC configuration.
  */
-struct fpga_5gnr_fec_conf {
+struct rte_fpga_5gnr_fec_conf {
 	/** 1 if PF is used for dataplane, 0 for VFs */
 	bool pf_mode_en;
 	/** Number of UL queues per VF */
@@ -64,8 +64,8 @@ struct fpga_5gnr_fec_conf {
  */
 __rte_experimental
 int
-fpga_5gnr_fec_configure(const char *dev_name,
-		const struct fpga_5gnr_fec_conf *conf);
+rte_fpga_5gnr_fec_configure(const char *dev_name,
+		const struct rte_fpga_5gnr_fec_conf *conf);
 
 #ifdef __cplusplus
 }
-- 
2.26.2

Re: [dpdk-dev] [PATCH 1/2] baseband/fpga_5gnr_fec: fix API naming

[Tom Rix]

On 10/2/20 1:59 AM, Maxime Coquelin wrote:
> DPDK APIs have to be prefixed with "rte_" in order to avoid
> namespace pollution.
>
> Let's fix it while fpga_5gnr_fec API is still experimental.
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  app/test-bbdev/test_bbdev_perf.c                   |  6 +++---
>  doc/guides/bbdevs/fpga_5gnr_fec.rst                | 14 +++++++-------
>  drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 10 +++++-----
>  .../rte_pmd_bbdev_fpga_5gnr_fec_version.map        |  2 +-
>  .../baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h |  6 +++---
>  5 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
> index 45c0d62aca..14f150704e 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -612,14 +612,14 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
>  #ifdef RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC
>  	if ((get_init_device() == true) &&
>  		(!strcmp(info->drv.driver_name, FPGA_5GNR_PF_DRIVER_NAME))) {
> -		struct fpga_5gnr_fec_conf conf;
> +		struct rte_fpga_5gnr_fec_conf conf;
>  		unsigned int i;
>  
>  		printf("Configure FPGA 5GNR FEC Driver %s with default values\n",
>  				info->drv.driver_name);
>  
>  		/* clear default configuration before initialization */
> -		memset(&conf, 0, sizeof(struct fpga_5gnr_fec_conf));
> +		memset(&conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
>  
>  		/* Set PF mode :
>  		 * true if PF is used for data plane
> @@ -647,7 +647,7 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
>  		conf.flr_time_out = FLR_5G_TIMEOUT;
>  
>  		/* setup FPGA PF with configuration information */
> -		ret = fpga_5gnr_fec_configure(info->dev_name, &conf);
> +		ret = rte_fpga_5gnr_fec_configure(info->dev_name, &conf);
>  		TEST_ASSERT_SUCCESS(ret,
>  				"Failed to configure 5G FPGA PF for bbdev %s",
>  				info->dev_name);
> diff --git a/doc/guides/bbdevs/fpga_5gnr_fec.rst b/doc/guides/bbdevs/fpga_5gnr_fec.rst
> index 6760391e8c..5849b31857 100644
> --- a/doc/guides/bbdevs/fpga_5gnr_fec.rst
> +++ b/doc/guides/bbdevs/fpga_5gnr_fec.rst
> @@ -170,12 +170,12 @@ queues, priorities, load balance, bandwidth and other settings necessary for the
>  device to perform FEC functions.
>  
>  This configuration needs to be executed at least once after reboot or PCI FLR and can
> -be achieved by using the function ``fpga_5gnr_fec_configure()``, which sets up the
> -parameters defined in ``fpga_5gnr_fec_conf`` structure:
> +be achieved by using the function ``rte_fpga_5gnr_fec_configure()``, which sets up the
> +parameters defined in ``rte_fpga_5gnr_fec_conf`` structure:
>  
>  .. code-block:: c
>  
> -  struct fpga_5gnr_fec_conf {
> +  struct rte_fpga_5gnr_fec_conf {
>        bool pf_mode_en;
>        uint8_t vf_ul_queues_number[FPGA_5GNR_FEC_NUM_VFS];
>        uint8_t vf_dl_queues_number[FPGA_5GNR_FEC_NUM_VFS];
> @@ -214,15 +214,15 @@ parameters defined in ``fpga_5gnr_fec_conf`` structure:
>    the FLR time out then set this setting to 0x262=610.
>  
>  
> -An example configuration code calling the function ``fpga_5gnr_fec_configure()`` is shown
> +An example configuration code calling the function ``rte_fpga_5gnr_fec_configure()`` is shown
>  below:
>  
>  .. code-block:: c
>  
> -  struct fpga_5gnr_fec_conf conf;
> +  struct rte_fpga_5gnr_fec_conf conf;
>    unsigned int i;
>  
> -  memset(&conf, 0, sizeof(struct fpga_5gnr_fec_conf));
> +  memset(&conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
>    conf.pf_mode_en = 1;
>  
>    for (i = 0; i < FPGA_5GNR_FEC_NUM_VFS; ++i) {
> @@ -235,7 +235,7 @@ below:
>    conf.ul_load_balance = 64;
>  
>    /* setup FPGA PF */
> -  ret = fpga_5gnr_fec_configure(info->dev_name, &conf);
> +  ret = rte_fpga_5gnr_fec_configure(info->dev_name, &conf);
>    TEST_ASSERT_SUCCESS(ret,
>        "Failed to configure 4G FPGA PF for bbdev %s",

4G ?

Consider a future patch to clean this up.

>        info->dev_name);
> diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> index 61f9c04ba2..1d73f9540e 100644
> --- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> +++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> @@ -1944,10 +1944,10 @@ fpga_5gnr_fec_remove(struct rte_pci_device *pci_dev)
>  }
>  
>  static inline void
> -set_default_fpga_conf(struct fpga_5gnr_fec_conf *def_conf)
> +set_default_fpga_conf(struct rte_fpga_5gnr_fec_conf *def_conf)
>  {
>  	/* clear default configuration before initialization */
> -	memset(def_conf, 0, sizeof(struct fpga_5gnr_fec_conf));
> +	memset(def_conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
>  	/* Set pf mode to true */
>  	def_conf->pf_mode_en = true;
>  
> @@ -1962,15 +1962,15 @@ set_default_fpga_conf(struct fpga_5gnr_fec_conf *def_conf)
>  
>  /* Initial configuration of FPGA 5GNR FEC device */
>  int
> -fpga_5gnr_fec_configure(const char *dev_name,
> -		const struct fpga_5gnr_fec_conf *conf)
> +rte_fpga_5gnr_fec_configure(const char *dev_name,
> +		const struct rte_fpga_5gnr_fec_conf *conf)
>  {
>  	uint32_t payload_32, address;
>  	uint16_t payload_16;
>  	uint8_t payload_8;
>  	uint16_t q_id, vf_id, total_q_id, total_ul_q_id, total_dl_q_id;
>  	struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
> -	struct fpga_5gnr_fec_conf def_conf;
> +	struct rte_fpga_5gnr_fec_conf def_conf;
>  
>  	if (bbdev == NULL) {
>  		rte_bbdev_log(ERR,
> diff --git a/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map b/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
> index d723bc9b0e..db43cd8403 100644
> --- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
> +++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
> @@ -5,6 +5,6 @@ DPDK_21 {
>  EXPERIMENTAL {
>  	global:
>  
> -	fpga_5gnr_fec_configure;
> +	rte_fpga_5gnr_fec_configure;
>  
>  };
> diff --git a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
> index 70a4acf0b7..c2752fbd52 100644
> --- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
> +++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
> @@ -30,7 +30,7 @@ extern "C" {
>  /**
>   * Structure to pass FPGA 4G FEC configuration.

4G ?

There are a number of 4G references in this file's comments.

Consider a future patch to clean this up.

>   */
> -struct fpga_5gnr_fec_conf {
> +struct rte_fpga_5gnr_fec_conf {
>  	/** 1 if PF is used for dataplane, 0 for VFs */
>  	bool pf_mode_en;
>  	/** Number of UL queues per VF */
> @@ -64,8 +64,8 @@ struct fpga_5gnr_fec_conf {
>   */
>  __rte_experimental
>  int
> -fpga_5gnr_fec_configure(const char *dev_name,
> -		const struct fpga_5gnr_fec_conf *conf);
> +rte_fpga_5gnr_fec_configure(const char *dev_name,
> +		const struct rte_fpga_5gnr_fec_conf *conf);
>  
>  #ifdef __cplusplus
>  }

Changes look complete.

Reviewed-by: Tom Rix <trix@redhat.com>

Re: [dpdk-dev] [PATCH 1/2] baseband/fpga_5gnr_fec: fix API naming

[Maxime Coquelin]

On 10/3/20 5:26 PM, Tom Rix wrote:
> 
> On 10/2/20 1:59 AM, Maxime Coquelin wrote:
>> DPDK APIs have to be prefixed with "rte_" in order to avoid
>> namespace pollution.
>>
>> Let's fix it while fpga_5gnr_fec API is still experimental.
>>
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> ---
>>  app/test-bbdev/test_bbdev_perf.c                   |  6 +++---
>>  doc/guides/bbdevs/fpga_5gnr_fec.rst                | 14 +++++++-------
>>  drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 10 +++++-----
>>  .../rte_pmd_bbdev_fpga_5gnr_fec_version.map        |  2 +-
>>  .../baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h |  6 +++---
>>  5 files changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
>> index 45c0d62aca..14f150704e 100644
>> --- a/app/test-bbdev/test_bbdev_perf.c
>> +++ b/app/test-bbdev/test_bbdev_perf.c
>> @@ -612,14 +612,14 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
>>  #ifdef RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC
>>  	if ((get_init_device() == true) &&
>>  		(!strcmp(info->drv.driver_name, FPGA_5GNR_PF_DRIVER_NAME))) {
>> -		struct fpga_5gnr_fec_conf conf;
>> +		struct rte_fpga_5gnr_fec_conf conf;
>>  		unsigned int i;
>>  
>>  		printf("Configure FPGA 5GNR FEC Driver %s with default values\n",
>>  				info->drv.driver_name);
>>  
>>  		/* clear default configuration before initialization */
>> -		memset(&conf, 0, sizeof(struct fpga_5gnr_fec_conf));
>> +		memset(&conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
>>  
>>  		/* Set PF mode :
>>  		 * true if PF is used for data plane
>> @@ -647,7 +647,7 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
>>  		conf.flr_time_out = FLR_5G_TIMEOUT;
>>  
>>  		/* setup FPGA PF with configuration information */
>> -		ret = fpga_5gnr_fec_configure(info->dev_name, &conf);
>> +		ret = rte_fpga_5gnr_fec_configure(info->dev_name, &conf);
>>  		TEST_ASSERT_SUCCESS(ret,
>>  				"Failed to configure 5G FPGA PF for bbdev %s",
>>  				info->dev_name);
>> diff --git a/doc/guides/bbdevs/fpga_5gnr_fec.rst b/doc/guides/bbdevs/fpga_5gnr_fec.rst
>> index 6760391e8c..5849b31857 100644
>> --- a/doc/guides/bbdevs/fpga_5gnr_fec.rst
>> +++ b/doc/guides/bbdevs/fpga_5gnr_fec.rst
>> @@ -170,12 +170,12 @@ queues, priorities, load balance, bandwidth and other settings necessary for the
>>  device to perform FEC functions.
>>  
>>  This configuration needs to be executed at least once after reboot or PCI FLR and can
>> -be achieved by using the function ``fpga_5gnr_fec_configure()``, which sets up the
>> -parameters defined in ``fpga_5gnr_fec_conf`` structure:
>> +be achieved by using the function ``rte_fpga_5gnr_fec_configure()``, which sets up the
>> +parameters defined in ``rte_fpga_5gnr_fec_conf`` structure:
>>  
>>  .. code-block:: c
>>  
>> -  struct fpga_5gnr_fec_conf {
>> +  struct rte_fpga_5gnr_fec_conf {
>>        bool pf_mode_en;
>>        uint8_t vf_ul_queues_number[FPGA_5GNR_FEC_NUM_VFS];
>>        uint8_t vf_dl_queues_number[FPGA_5GNR_FEC_NUM_VFS];
>> @@ -214,15 +214,15 @@ parameters defined in ``fpga_5gnr_fec_conf`` structure:
>>    the FLR time out then set this setting to 0x262=610.
>>  
>>  
>> -An example configuration code calling the function ``fpga_5gnr_fec_configure()`` is shown
>> +An example configuration code calling the function ``rte_fpga_5gnr_fec_configure()`` is shown
>>  below:
>>  
>>  .. code-block:: c
>>  
>> -  struct fpga_5gnr_fec_conf conf;
>> +  struct rte_fpga_5gnr_fec_conf conf;
>>    unsigned int i;
>>  
>> -  memset(&conf, 0, sizeof(struct fpga_5gnr_fec_conf));
>> +  memset(&conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
>>    conf.pf_mode_en = 1;
>>  
>>    for (i = 0; i < FPGA_5GNR_FEC_NUM_VFS; ++i) {
>> @@ -235,7 +235,7 @@ below:
>>    conf.ul_load_balance = 64;
>>  
>>    /* setup FPGA PF */
>> -  ret = fpga_5gnr_fec_configure(info->dev_name, &conf);
>> +  ret = rte_fpga_5gnr_fec_configure(info->dev_name, &conf);
>>    TEST_ASSERT_SUCCESS(ret,
>>        "Failed to configure 4G FPGA PF for bbdev %s",
> 
> 4G ?
> 
> Consider a future patch to clean this up.
> 
>>        info->dev_name);
>> diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
>> index 61f9c04ba2..1d73f9540e 100644
>> --- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
>> +++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
>> @@ -1944,10 +1944,10 @@ fpga_5gnr_fec_remove(struct rte_pci_device *pci_dev)
>>  }
>>  
>>  static inline void
>> -set_default_fpga_conf(struct fpga_5gnr_fec_conf *def_conf)
>> +set_default_fpga_conf(struct rte_fpga_5gnr_fec_conf *def_conf)
>>  {
>>  	/* clear default configuration before initialization */
>> -	memset(def_conf, 0, sizeof(struct fpga_5gnr_fec_conf));
>> +	memset(def_conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
>>  	/* Set pf mode to true */
>>  	def_conf->pf_mode_en = true;
>>  
>> @@ -1962,15 +1962,15 @@ set_default_fpga_conf(struct fpga_5gnr_fec_conf *def_conf)
>>  
>>  /* Initial configuration of FPGA 5GNR FEC device */
>>  int
>> -fpga_5gnr_fec_configure(const char *dev_name,
>> -		const struct fpga_5gnr_fec_conf *conf)
>> +rte_fpga_5gnr_fec_configure(const char *dev_name,
>> +		const struct rte_fpga_5gnr_fec_conf *conf)
>>  {
>>  	uint32_t payload_32, address;
>>  	uint16_t payload_16;
>>  	uint8_t payload_8;
>>  	uint16_t q_id, vf_id, total_q_id, total_ul_q_id, total_dl_q_id;
>>  	struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
>> -	struct fpga_5gnr_fec_conf def_conf;
>> +	struct rte_fpga_5gnr_fec_conf def_conf;
>>  
>>  	if (bbdev == NULL) {
>>  		rte_bbdev_log(ERR,
>> diff --git a/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map b/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
>> index d723bc9b0e..db43cd8403 100644
>> --- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
>> +++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
>> @@ -5,6 +5,6 @@ DPDK_21 {
>>  EXPERIMENTAL {
>>  	global:
>>  
>> -	fpga_5gnr_fec_configure;
>> +	rte_fpga_5gnr_fec_configure;
>>  
>>  };
>> diff --git a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
>> index 70a4acf0b7..c2752fbd52 100644
>> --- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
>> +++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
>> @@ -30,7 +30,7 @@ extern "C" {
>>  /**
>>   * Structure to pass FPGA 4G FEC configuration.
> 
> 4G ?
> 
> There are a number of 4G references in this file's comments.
> 
> Consider a future patch to clean this up.

Agree, I noticed that.
It has to be fixed in another series.

>>   */
>> -struct fpga_5gnr_fec_conf {
>> +struct rte_fpga_5gnr_fec_conf {
>>  	/** 1 if PF is used for dataplane, 0 for VFs */
>>  	bool pf_mode_en;
>>  	/** Number of UL queues per VF */
>> @@ -64,8 +64,8 @@ struct fpga_5gnr_fec_conf {
>>   */
>>  __rte_experimental
>>  int
>> -fpga_5gnr_fec_configure(const char *dev_name,
>> -		const struct fpga_5gnr_fec_conf *conf);
>> +rte_fpga_5gnr_fec_configure(const char *dev_name,
>> +		const struct rte_fpga_5gnr_fec_conf *conf);
>>  
>>  #ifdef __cplusplus
>>  }
> 
> Changes look complete.
> 
> Reviewed-by: Tom Rix <trix@redhat.com>
> 

Thanks,
Maxime

Re: [dpdk-dev] [PATCH 1/2] baseband/fpga_5gnr_fec: fix API naming

[Maxime Coquelin]

On 10/5/20 9:11 AM, Maxime Coquelin wrote:
>>> diff --git a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
>>> index 70a4acf0b7..c2752fbd52 100644
>>> --- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
>>> +++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
>>> @@ -30,7 +30,7 @@ extern "C" {
>>>  /**
>>>   * Structure to pass FPGA 4G FEC configuration.
>> 4G ?
>>
>> There are a number of 4G references in this file's comments.
>>
>> Consider a future patch to clean this up.
> Agree, I noticed that.
> It has to be fixed in another series.
> 

Another thing that we might consider fixing is the naming of the
drivers.

fpga_5gnr & fpga_lte are too generic, it should refer to an Intel
product/family.

Regards,
Maxime

[dpdk-dev] [PATCH 2/2] baseband/fpga_lte_fec: fix API naming

[Maxime Coquelin]

DPDK APIs have to be prefixed with "rte_" in order to avoid
namespace pollution.

Let's fix it while fpga_lte_fec API is still experimental.

Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
 app/test-bbdev/test_bbdev_perf.c                   |  6 +++---
 doc/guides/bbdevs/fpga_lte_fec.rst                 | 14 +++++++-------
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.c       | 10 +++++-----
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.h       |  6 +++---
 .../rte_pmd_bbdev_fpga_lte_fec_version.map         |  2 +-
 5 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index 14f150704e..d4a3681344 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -568,14 +568,14 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
 #ifdef RTE_LIBRTE_PMD_BBDEV_FPGA_LTE_FEC
 	if ((get_init_device() == true) &&
 		(!strcmp(info->drv.driver_name, FPGA_LTE_PF_DRIVER_NAME))) {
-		struct fpga_lte_fec_conf conf;
+		struct rte_fpga_lte_fec_conf conf;
 		unsigned int i;
 
 		printf("Configure FPGA LTE FEC Driver %s with default values\n",
 				info->drv.driver_name);
 
 		/* clear default configuration before initialization */
-		memset(&conf, 0, sizeof(struct fpga_lte_fec_conf));
+		memset(&conf, 0, sizeof(struct rte_fpga_lte_fec_conf));
 
 		/* Set PF mode :
 		 * true if PF is used for data plane
@@ -603,7 +603,7 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
 		conf.flr_time_out = FLR_4G_TIMEOUT;
 
 		/* setup FPGA PF with configuration information */
-		ret = fpga_lte_fec_configure(info->dev_name, &conf);
+		ret = rte_fpga_lte_fec_configure(info->dev_name, &conf);
 		TEST_ASSERT_SUCCESS(ret,
 				"Failed to configure 4G FPGA PF for bbdev %s",
 				info->dev_name);
diff --git a/doc/guides/bbdevs/fpga_lte_fec.rst b/doc/guides/bbdevs/fpga_lte_fec.rst
index fdc8a76981..a8cc3c58a8 100644
--- a/doc/guides/bbdevs/fpga_lte_fec.rst
+++ b/doc/guides/bbdevs/fpga_lte_fec.rst
@@ -169,12 +169,12 @@ queues, priorities, load balance, bandwidth and other settings necessary for the
 device to perform FEC functions.
 
 This configuration needs to be executed at least once after reboot or PCI FLR and can
-be achieved by using the function ``fpga_lte_fec_configure()``, which sets up the
-parameters defined in ``fpga_lte_fec_conf`` structure:
+be achieved by using the function ``rte_fpga_lte_fec_configure()``, which sets up the
+parameters defined in ``rte_fpga_lte_fec_conf`` structure:
 
 .. code-block:: c
 
-  struct fpga_lte_fec_conf {
+  struct rte_fpga_lte_fec_conf {
       bool pf_mode_en;
       uint8_t vf_ul_queues_number[FPGA_LTE_FEC_NUM_VFS];
       uint8_t vf_dl_queues_number[FPGA_LTE_FEC_NUM_VFS];
@@ -213,15 +213,15 @@ parameters defined in ``fpga_lte_fec_conf`` structure:
   the FLR time out then set this setting to 0x262=610.
 
 
-An example configuration code calling the function ``fpga_lte_fec_configure()`` is shown
+An example configuration code calling the function ``rte_fpga_lte_fec_configure()`` is shown
 below:
 
 .. code-block:: c
 
-  struct fpga_lte_fec_conf conf;
+  struct rte_fpga_lte_fec_conf conf;
   unsigned int i;
 
-  memset(&conf, 0, sizeof(struct fpga_lte_fec_conf));
+  memset(&conf, 0, sizeof(struct rte_fpga_lte_fec_conf));
   conf.pf_mode_en = 1;
 
   for (i = 0; i < FPGA_LTE_FEC_NUM_VFS; ++i) {
@@ -234,7 +234,7 @@ below:
   conf.ul_load_balance = 64;
 
   /* setup FPGA PF */
-  ret = fpga_lte_fec_configure(info->dev_name, &conf);
+  ret = rte_fpga_lte_fec_configure(info->dev_name, &conf);
   TEST_ASSERT_SUCCESS(ret,
       "Failed to configure 4G FPGA PF for bbdev %s",
       info->dev_name);
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 37018b9c7f..71de399eef 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -2432,10 +2432,10 @@ fpga_lte_fec_remove(struct rte_pci_device *pci_dev)
 }
 
 static inline void
-set_default_fpga_conf(struct fpga_lte_fec_conf *def_conf)
+set_default_fpga_conf(struct rte_fpga_lte_fec_conf *def_conf)
 {
 	/* clear default configuration before initialization */
-	memset(def_conf, 0, sizeof(struct fpga_lte_fec_conf));
+	memset(def_conf, 0, sizeof(struct rte_fpga_lte_fec_conf));
 	/* Set pf mode to true */
 	def_conf->pf_mode_en = true;
 
@@ -2450,15 +2450,15 @@ set_default_fpga_conf(struct fpga_lte_fec_conf *def_conf)
 
 /* Initial configuration of FPGA LTE FEC device */
 int
-fpga_lte_fec_configure(const char *dev_name,
-		const struct fpga_lte_fec_conf *conf)
+rte_fpga_lte_fec_configure(const char *dev_name,
+		const struct rte_fpga_lte_fec_conf *conf)
 {
 	uint32_t payload_32, address;
 	uint16_t payload_16;
 	uint8_t payload_8;
 	uint16_t q_id, vf_id, total_q_id, total_ul_q_id, total_dl_q_id;
 	struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
-	struct fpga_lte_fec_conf def_conf;
+	struct rte_fpga_lte_fec_conf def_conf;
 
 	if (bbdev == NULL) {
 		rte_bbdev_log(ERR,
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
index b2e423c87c..b35c7a484e 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
@@ -30,7 +30,7 @@ extern "C" {
 /**
  * Structure to pass FPGA 4G FEC configuration.
  */
-struct fpga_lte_fec_conf {
+struct rte_fpga_lte_fec_conf {
 	/**< 1 if PF is used for dataplane, 0 for VFs */
 	bool pf_mode_en;
 	/**< Number of UL queues per VF */
@@ -64,8 +64,8 @@ struct fpga_lte_fec_conf {
  */
 __rte_experimental
 int
-fpga_lte_fec_configure(const char *dev_name,
-		const struct fpga_lte_fec_conf *conf);
+rte_fpga_lte_fec_configure(const char *dev_name,
+		const struct rte_fpga_lte_fec_conf *conf);
 
 #ifdef __cplusplus
 }
diff --git a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
index a2ab086cd8..b95b7838e8 100644
--- a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
+++ b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
@@ -5,6 +5,6 @@ DPDK_21 {
 EXPERIMENTAL {
 	global:
 
-	fpga_lte_fec_configure;
+	rte_fpga_lte_fec_configure;
 
 };
-- 
2.26.2

Re: [dpdk-dev] [PATCH 2/2] baseband/fpga_lte_fec: fix API naming

[Tom Rix]

On 10/2/20 1:59 AM, Maxime Coquelin wrote:
> DPDK APIs have to be prefixed with "rte_" in order to avoid
> namespace pollution.
>
> Let's fix it while fpga_lte_fec API is still experimental.
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  app/test-bbdev/test_bbdev_perf.c                   |  6 +++---
>  doc/guides/bbdevs/fpga_lte_fec.rst                 | 14 +++++++-------
>  drivers/baseband/fpga_lte_fec/fpga_lte_fec.c       | 10 +++++-----
>  drivers/baseband/fpga_lte_fec/fpga_lte_fec.h       |  6 +++---
>  .../rte_pmd_bbdev_fpga_lte_fec_version.map         |  2 +-
>  5 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
> index 14f150704e..d4a3681344 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -568,14 +568,14 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
>  #ifdef RTE_LIBRTE_PMD_BBDEV_FPGA_LTE_FEC
>  	if ((get_init_device() == true) &&
>  		(!strcmp(info->drv.driver_name, FPGA_LTE_PF_DRIVER_NAME))) {
> -		struct fpga_lte_fec_conf conf;
> +		struct rte_fpga_lte_fec_conf conf;
>  		unsigned int i;
>  
>  		printf("Configure FPGA LTE FEC Driver %s with default values\n",
>  				info->drv.driver_name);
>  
>  		/* clear default configuration before initialization */
> -		memset(&conf, 0, sizeof(struct fpga_lte_fec_conf));
> +		memset(&conf, 0, sizeof(struct rte_fpga_lte_fec_conf));
>  
>  		/* Set PF mode :
>  		 * true if PF is used for data plane
> @@ -603,7 +603,7 @@ add_bbdev_dev(uint8_t dev_id, struct rte_bbdev_info *info,
>  		conf.flr_time_out = FLR_4G_TIMEOUT;
>  
>  		/* setup FPGA PF with configuration information */
> -		ret = fpga_lte_fec_configure(info->dev_name, &conf);
> +		ret = rte_fpga_lte_fec_configure(info->dev_name, &conf);
>  		TEST_ASSERT_SUCCESS(ret,
>  				"Failed to configure 4G FPGA PF for bbdev %s",
>  				info->dev_name);
> diff --git a/doc/guides/bbdevs/fpga_lte_fec.rst b/doc/guides/bbdevs/fpga_lte_fec.rst
> index fdc8a76981..a8cc3c58a8 100644
> --- a/doc/guides/bbdevs/fpga_lte_fec.rst
> +++ b/doc/guides/bbdevs/fpga_lte_fec.rst
> @@ -169,12 +169,12 @@ queues, priorities, load balance, bandwidth and other settings necessary for the
>  device to perform FEC functions.
>  
>  This configuration needs to be executed at least once after reboot or PCI FLR and can
> -be achieved by using the function ``fpga_lte_fec_configure()``, which sets up the
> -parameters defined in ``fpga_lte_fec_conf`` structure:
> +be achieved by using the function ``rte_fpga_lte_fec_configure()``, which sets up the
> +parameters defined in ``rte_fpga_lte_fec_conf`` structure:
>  
>  .. code-block:: c
>  
> -  struct fpga_lte_fec_conf {
> +  struct rte_fpga_lte_fec_conf {
>        bool pf_mode_en;
>        uint8_t vf_ul_queues_number[FPGA_LTE_FEC_NUM_VFS];
>        uint8_t vf_dl_queues_number[FPGA_LTE_FEC_NUM_VFS];
> @@ -213,15 +213,15 @@ parameters defined in ``fpga_lte_fec_conf`` structure:
>    the FLR time out then set this setting to 0x262=610.
>  
>  
> -An example configuration code calling the function ``fpga_lte_fec_configure()`` is shown
> +An example configuration code calling the function ``rte_fpga_lte_fec_configure()`` is shown
>  below:
>  
>  .. code-block:: c
>  
> -  struct fpga_lte_fec_conf conf;
> +  struct rte_fpga_lte_fec_conf conf;
>    unsigned int i;
>  
> -  memset(&conf, 0, sizeof(struct fpga_lte_fec_conf));
> +  memset(&conf, 0, sizeof(struct rte_fpga_lte_fec_conf));
>    conf.pf_mode_en = 1;
>  
>    for (i = 0; i < FPGA_LTE_FEC_NUM_VFS; ++i) {
> @@ -234,7 +234,7 @@ below:
>    conf.ul_load_balance = 64;
>  
>    /* setup FPGA PF */
> -  ret = fpga_lte_fec_configure(info->dev_name, &conf);
> +  ret = rte_fpga_lte_fec_configure(info->dev_name, &conf);
>    TEST_ASSERT_SUCCESS(ret,
>        "Failed to configure 4G FPGA PF for bbdev %s",
>        info->dev_name);
> diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> index 37018b9c7f..71de399eef 100644
> --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> @@ -2432,10 +2432,10 @@ fpga_lte_fec_remove(struct rte_pci_device *pci_dev)
>  }
>  
>  static inline void
> -set_default_fpga_conf(struct fpga_lte_fec_conf *def_conf)
> +set_default_fpga_conf(struct rte_fpga_lte_fec_conf *def_conf)
>  {
>  	/* clear default configuration before initialization */
> -	memset(def_conf, 0, sizeof(struct fpga_lte_fec_conf));
> +	memset(def_conf, 0, sizeof(struct rte_fpga_lte_fec_conf));
>  	/* Set pf mode to true */
>  	def_conf->pf_mode_en = true;
>  
> @@ -2450,15 +2450,15 @@ set_default_fpga_conf(struct fpga_lte_fec_conf *def_conf)
>  
>  /* Initial configuration of FPGA LTE FEC device */
>  int
> -fpga_lte_fec_configure(const char *dev_name,
> -		const struct fpga_lte_fec_conf *conf)
> +rte_fpga_lte_fec_configure(const char *dev_name,
> +		const struct rte_fpga_lte_fec_conf *conf)
>  {
>  	uint32_t payload_32, address;
>  	uint16_t payload_16;
>  	uint8_t payload_8;
>  	uint16_t q_id, vf_id, total_q_id, total_ul_q_id, total_dl_q_id;
>  	struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
> -	struct fpga_lte_fec_conf def_conf;
> +	struct rte_fpga_lte_fec_conf def_conf;
>  
>  	if (bbdev == NULL) {
>  		rte_bbdev_log(ERR,
> diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
> index b2e423c87c..b35c7a484e 100644
> --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
> +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
> @@ -30,7 +30,7 @@ extern "C" {
>  /**
>   * Structure to pass FPGA 4G FEC configuration.
>   */
> -struct fpga_lte_fec_conf {
> +struct rte_fpga_lte_fec_conf {
>  	/**< 1 if PF is used for dataplane, 0 for VFs */
>  	bool pf_mode_en;
>  	/**< Number of UL queues per VF */
> @@ -64,8 +64,8 @@ struct fpga_lte_fec_conf {
>   */
>  __rte_experimental
>  int
> -fpga_lte_fec_configure(const char *dev_name,
> -		const struct fpga_lte_fec_conf *conf);
> +rte_fpga_lte_fec_configure(const char *dev_name,
> +		const struct rte_fpga_lte_fec_conf *conf);
>  
>  #ifdef __cplusplus
>  }
> diff --git a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
> index a2ab086cd8..b95b7838e8 100644
> --- a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
> +++ b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
> @@ -5,6 +5,6 @@ DPDK_21 {
>  EXPERIMENTAL {
>  	global:
>  
> -	fpga_lte_fec_configure;
> +	rte_fpga_lte_fec_configure;
>  
>  };

Looks fine.

Reviewed-by: Tom Rix <trix@redhat.com>

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Akhil Goyal]

> 
> The series prefixes drivers APIs with rte_<drv_name>_ in
> order to avoid namespace pollution.
> 
> These APIs are experimental, so no need to follow the
> deprecation process.
> 
Added Fixes commit in patch description.

Series applied to dpdk-next-crypto

Thanks.

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Maxime Coquelin]

Hi Akhil,

Adding Thomas as he pulls your tree.

On 10/6/20 9:42 PM, Akhil Goyal wrote:
> 
>>
>> The series prefixes drivers APIs with rte_<drv_name>_ in
>> order to avoid namespace pollution.
>>
>> These APIs are experimental, so no need to follow the
>> deprecation process.
>>
> Added Fixes commit in patch description.

Thanks for applying it to your tree.

I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
because I thought it is was not a good idea to backport API changes,
even if this is experimental it might be annoying for the user.

Thomas, do you confirm?

Thanks,
Maxime
> Series applied to dpdk-next-crypto
> 
> Thanks.
> 

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Thomas Monjalon]

07/10/2020 10:22, Maxime Coquelin:
> Hi Akhil,
> 
> Adding Thomas as he pulls your tree.
> 
> On 10/6/20 9:42 PM, Akhil Goyal wrote:
> > 
> >>
> >> The series prefixes drivers APIs with rte_<drv_name>_ in
> >> order to avoid namespace pollution.
> >>
> >> These APIs are experimental, so no need to follow the
> >> deprecation process.
> >>
> > Added Fixes commit in patch description.
> 
> Thanks for applying it to your tree.
> 
> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
> because I thought it is was not a good idea to backport API changes,
> even if this is experimental it might be annoying for the user.
> 
> Thomas, do you confirm?

Absolutely: API must not change in a stable branch.

If an API is changed, it must be in the release notes.
But stable branches are not allowed to update such sections
of the release notes.

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Maxime Coquelin]

On 10/7/20 12:09 PM, Thomas Monjalon wrote:
> 07/10/2020 10:22, Maxime Coquelin:
>> Hi Akhil,
>>
>> Adding Thomas as he pulls your tree.
>>
>> On 10/6/20 9:42 PM, Akhil Goyal wrote:
>>>
>>>>
>>>> The series prefixes drivers APIs with rte_<drv_name>_ in
>>>> order to avoid namespace pollution.
>>>>
>>>> These APIs are experimental, so no need to follow the
>>>> deprecation process.
>>>>
>>> Added Fixes commit in patch description.
>>
>> Thanks for applying it to your tree.
>>
>> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
>> because I thought it is was not a good idea to backport API changes,
>> even if this is experimental it might be annoying for the user.
>>
>> Thomas, do you confirm?
> 
> Absolutely: API must not change in a stable branch.
> 
> If an API is changed, it must be in the release notes.

Ok, even for experimental APIs? I thought not.

> But stable branches are not allowed to update such sections
> of the release notes.
> 
> 

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Thomas Monjalon]

07/10/2020 12:12, Maxime Coquelin:
> On 10/7/20 12:09 PM, Thomas Monjalon wrote:
> > 07/10/2020 10:22, Maxime Coquelin:
> >> On 10/6/20 9:42 PM, Akhil Goyal wrote:
> >>>>
> >>>> The series prefixes drivers APIs with rte_<drv_name>_ in
> >>>> order to avoid namespace pollution.
> >>>>
> >>>> These APIs are experimental, so no need to follow the
> >>>> deprecation process.
> >>>>
> >>> Added Fixes commit in patch description.
> >>
> >> Thanks for applying it to your tree.
> >>
> >> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
> >> because I thought it is was not a good idea to backport API changes,
> >> even if this is experimental it might be annoying for the user.
> >>
> >> Thomas, do you confirm?
> > 
> > Absolutely: API must not change in a stable branch.
> > 
> > If an API is changed, it must be in the release notes.
> 
> Ok, even for experimental APIs? I thought not.

Yes, experimental means it can change in the main branch
without prior notice. But it must be noted when it's changed.

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Maxime Coquelin]

On 10/7/20 12:29 PM, Thomas Monjalon wrote:
> 07/10/2020 12:12, Maxime Coquelin:
>> On 10/7/20 12:09 PM, Thomas Monjalon wrote:
>>> 07/10/2020 10:22, Maxime Coquelin:
>>>> On 10/6/20 9:42 PM, Akhil Goyal wrote:
>>>>>>
>>>>>> The series prefixes drivers APIs with rte_<drv_name>_ in
>>>>>> order to avoid namespace pollution.
>>>>>>
>>>>>> These APIs are experimental, so no need to follow the
>>>>>> deprecation process.
>>>>>>
>>>>> Added Fixes commit in patch description.
>>>>
>>>> Thanks for applying it to your tree.
>>>>
>>>> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
>>>> because I thought it is was not a good idea to backport API changes,
>>>> even if this is experimental it might be annoying for the user.
>>>>
>>>> Thomas, do you confirm?
>>>
>>> Absolutely: API must not change in a stable branch.
>>>
>>> If an API is changed, it must be in the release notes.
>>
>> Ok, even for experimental APIs? I thought not.
> 
> Yes, experimental means it can change in the main branch
> without prior notice. But it must be noted when it's changed.
> 
> 
> 

Ok, do you want me to send add-on patches that you will squash when
pulling Akhil's branch?

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Thomas Monjalon]

07/10/2020 12:52, Maxime Coquelin:
> On 10/7/20 12:29 PM, Thomas Monjalon wrote:
> > 07/10/2020 12:12, Maxime Coquelin:
> >> On 10/7/20 12:09 PM, Thomas Monjalon wrote:
> >>> 07/10/2020 10:22, Maxime Coquelin:
> >>>> On 10/6/20 9:42 PM, Akhil Goyal wrote:
> >>>>>>
> >>>>>> The series prefixes drivers APIs with rte_<drv_name>_ in
> >>>>>> order to avoid namespace pollution.
> >>>>>>
> >>>>>> These APIs are experimental, so no need to follow the
> >>>>>> deprecation process.
> >>>>>>
> >>>>> Added Fixes commit in patch description.
> >>>>
> >>>> Thanks for applying it to your tree.
> >>>>
> >>>> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
> >>>> because I thought it is was not a good idea to backport API changes,
> >>>> even if this is experimental it might be annoying for the user.
> >>>>
> >>>> Thomas, do you confirm?
> >>>
> >>> Absolutely: API must not change in a stable branch.
> >>>
> >>> If an API is changed, it must be in the release notes.
> >>
> >> Ok, even for experimental APIs? I thought not.
> > 
> > Yes, experimental means it can change in the main branch
> > without prior notice. But it must be noted when it's changed.
> 
> Ok, do you want me to send add-on patches that you will squash when
> pulling Akhil's branch?

Yes please

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Thomas Monjalon]

07/10/2020 13:06, Thomas Monjalon:
> 07/10/2020 12:52, Maxime Coquelin:
> > On 10/7/20 12:29 PM, Thomas Monjalon wrote:
> > > 07/10/2020 12:12, Maxime Coquelin:
> > >> On 10/7/20 12:09 PM, Thomas Monjalon wrote:
> > >>> 07/10/2020 10:22, Maxime Coquelin:
> > >>>> On 10/6/20 9:42 PM, Akhil Goyal wrote:
> > >>>>>>
> > >>>>>> The series prefixes drivers APIs with rte_<drv_name>_ in
> > >>>>>> order to avoid namespace pollution.
> > >>>>>>
> > >>>>>> These APIs are experimental, so no need to follow the
> > >>>>>> deprecation process.
> > >>>>>>
> > >>>>> Added Fixes commit in patch description.
> > >>>>
> > >>>> Thanks for applying it to your tree.
> > >>>>
> > >>>> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
> > >>>> because I thought it is was not a good idea to backport API changes,
> > >>>> even if this is experimental it might be annoying for the user.
> > >>>>
> > >>>> Thomas, do you confirm?
> > >>>
> > >>> Absolutely: API must not change in a stable branch.
> > >>>
> > >>> If an API is changed, it must be in the release notes.
> > >>
> > >> Ok, even for experimental APIs? I thought not.
> > > 
> > > Yes, experimental means it can change in the main branch
> > > without prior notice. But it must be noted when it's changed.
> > 
> > Ok, do you want me to send add-on patches that you will squash when
> > pulling Akhil's branch?
> 
> Yes please

Better: Akhil can squash in his tree and remove the Cc: stable tag.

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Akhil Goyal]

> 07/10/2020 13:06, Thomas Monjalon:
> > 07/10/2020 12:52, Maxime Coquelin:
> > > On 10/7/20 12:29 PM, Thomas Monjalon wrote:
> > > > 07/10/2020 12:12, Maxime Coquelin:
> > > >> On 10/7/20 12:09 PM, Thomas Monjalon wrote:
> > > >>> 07/10/2020 10:22, Maxime Coquelin:
> > > >>>> On 10/6/20 9:42 PM, Akhil Goyal wrote:
> > > >>>>>>
> > > >>>>>> The series prefixes drivers APIs with rte_<drv_name>_ in
> > > >>>>>> order to avoid namespace pollution.
> > > >>>>>>
> > > >>>>>> These APIs are experimental, so no need to follow the
> > > >>>>>> deprecation process.
> > > >>>>>>
> > > >>>>> Added Fixes commit in patch description.
> > > >>>>
> > > >>>> Thanks for applying it to your tree.
> > > >>>>
> > > >>>> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
> > > >>>> because I thought it is was not a good idea to backport API changes,
> > > >>>> even if this is experimental it might be annoying for the user.
> > > >>>>
> > > >>>> Thomas, do you confirm?
> > > >>>
> > > >>> Absolutely: API must not change in a stable branch.
> > > >>>
> > > >>> If an API is changed, it must be in the release notes.
> > > >>
> > > >> Ok, even for experimental APIs? I thought not.
> > > >
> > > > Yes, experimental means it can change in the main branch
> > > > without prior notice. But it must be noted when it's changed.
> > >
> > > Ok, do you want me to send add-on patches that you will squash when
> > > pulling Akhil's branch?
> >
> > Yes please
> 
> Better: Akhil can squash in his tree and remove the Cc: stable tag.

Sure will do that.

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Maxime Coquelin]

On 10/7/20 2:05 PM, Akhil Goyal wrote:
>> 07/10/2020 13:06, Thomas Monjalon:
>>> 07/10/2020 12:52, Maxime Coquelin:
>>>> On 10/7/20 12:29 PM, Thomas Monjalon wrote:
>>>>> 07/10/2020 12:12, Maxime Coquelin:
>>>>>> On 10/7/20 12:09 PM, Thomas Monjalon wrote:
>>>>>>> 07/10/2020 10:22, Maxime Coquelin:
>>>>>>>> On 10/6/20 9:42 PM, Akhil Goyal wrote:
>>>>>>>>>>
>>>>>>>>>> The series prefixes drivers APIs with rte_<drv_name>_ in
>>>>>>>>>> order to avoid namespace pollution.
>>>>>>>>>>
>>>>>>>>>> These APIs are experimental, so no need to follow the
>>>>>>>>>> deprecation process.
>>>>>>>>>>
>>>>>>>>> Added Fixes commit in patch description.
>>>>>>>>
>>>>>>>> Thanks for applying it to your tree.
>>>>>>>>
>>>>>>>> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
>>>>>>>> because I thought it is was not a good idea to backport API changes,
>>>>>>>> even if this is experimental it might be annoying for the user.
>>>>>>>>
>>>>>>>> Thomas, do you confirm?
>>>>>>>
>>>>>>> Absolutely: API must not change in a stable branch.
>>>>>>>
>>>>>>> If an API is changed, it must be in the release notes.
>>>>>>
>>>>>> Ok, even for experimental APIs? I thought not.
>>>>>
>>>>> Yes, experimental means it can change in the main branch
>>>>> without prior notice. But it must be noted when it's changed.
>>>>
>>>> Ok, do you want me to send add-on patches that you will squash when
>>>> pulling Akhil's branch?
>>>
>>> Yes please
>>
>> Better: Akhil can squash in his tree and remove the Cc: stable tag.
> 
> Sure will do that.
> 

Thanks Akhil for handling it, I just posted the release note patch.

Maxime

Re: [dpdk-dev] [PATCH 0/2] baseband: fix drivers API

[Maxime Coquelin]

On 10/7/20 1:06 PM, Thomas Monjalon wrote:
> 07/10/2020 12:52, Maxime Coquelin:
>> On 10/7/20 12:29 PM, Thomas Monjalon wrote:
>>> 07/10/2020 12:12, Maxime Coquelin:
>>>> On 10/7/20 12:09 PM, Thomas Monjalon wrote:
>>>>> 07/10/2020 10:22, Maxime Coquelin:
>>>>>> On 10/6/20 9:42 PM, Akhil Goyal wrote:
>>>>>>>>
>>>>>>>> The series prefixes drivers APIs with rte_<drv_name>_ in
>>>>>>>> order to avoid namespace pollution.
>>>>>>>>
>>>>>>>> These APIs are experimental, so no need to follow the
>>>>>>>> deprecation process.
>>>>>>>>
>>>>>>> Added Fixes commit in patch description.
>>>>>>
>>>>>> Thanks for applying it to your tree.
>>>>>>
>>>>>> I did not add Fixes tag and Cc'ed stable@dpdk.org on purpose,
>>>>>> because I thought it is was not a good idea to backport API changes,
>>>>>> even if this is experimental it might be annoying for the user.
>>>>>>
>>>>>> Thomas, do you confirm?
>>>>>
>>>>> Absolutely: API must not change in a stable branch.
>>>>>
>>>>> If an API is changed, it must be in the release notes.
>>>>
>>>> Ok, even for experimental APIs? I thought not.
>>>
>>> Yes, experimental means it can change in the main branch
>>> without prior notice. But it must be noted when it's changed.
>>
>> Ok, do you want me to send add-on patches that you will squash when
>> pulling Akhil's branch?
> 
> Yes please

OK, will do that later today.

Thanks,
Maxime