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 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
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
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>
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>
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
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
>
> 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.
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. >
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.
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. > >
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.
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?
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
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.
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
> 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.
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