diff mbox series

[v1,1/3] net/ixgbe: promote some API to stable

Message ID 20210901050707.570163-2-haiyue.wang@intel.com (mailing list archive)
State Superseded, archived
Delegated to: Ferruh Yigit
Headers
Series Promote some API to stable |

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Wang, Haiyue Sept. 1, 2021, 5:07 a.m. UTC 
  The DPDK Symbol Bot reports:
Please note the symbols listed below have expired. In line with the
DPDK ABI policy, they should be scheduled for removal, in the next
DPDK release.

Symbol
rte_pmd_ixgbe_mdio_lock
rte_pmd_ixgbe_mdio_unlock
rte_pmd_ixgbe_mdio_unlocked_read
rte_pmd_ixgbe_mdio_unlocked_write
rte_pmd_ixgbe_upd_fctrl_sbp

Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
---
 drivers/net/ixgbe/rte_pmd_ixgbe.h |  5 -----
 drivers/net/ixgbe/version.map     | 10 +++++-----
 2 files changed, 5 insertions(+), 10 deletions(-)

Comments

Ferruh Yigit Sept. 1, 2021, 9:02 a.m. UTC | #1 
On 9/1/2021 6:07 AM, Haiyue Wang wrote:
> The DPDK Symbol Bot reports:
> Please note the symbols listed below have expired. In line with the
> DPDK ABI policy, they should be scheduled for removal, in the next
> DPDK release.
> 
> Symbol
> rte_pmd_ixgbe_mdio_lock
> rte_pmd_ixgbe_mdio_unlock
> rte_pmd_ixgbe_mdio_unlocked_read
> rte_pmd_ixgbe_mdio_unlocked_write
> rte_pmd_ixgbe_upd_fctrl_sbp

I wonder if we should keep PMD specific APIs as experimental (Not talking about
mbuf 'dynfield' / 'dynflag' APIs, we can promote them).

If an application is using PMD specific API, not sure if it will concern about
PMD specific APIs.
And keeping PMD specific APIs lets us remove them as soon as we can, also adds
additional discourage for users to use them.

> 
> Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>


<...>
Wang, Haiyue Sept. 1, 2021, 11:13 a.m. UTC | #2 
> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Wednesday, September 1, 2021 17:02
> To: Wang, Haiyue <haiyue.wang@intel.com>; dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net
> Subject: Re: [dpdk-dev] [PATCH v1 1/3] net/ixgbe: promote some API to stable
> 
> On 9/1/2021 6:07 AM, Haiyue Wang wrote:
> > The DPDK Symbol Bot reports:
> > Please note the symbols listed below have expired. In line with the
> > DPDK ABI policy, they should be scheduled for removal, in the next
> > DPDK release.
> >
> > Symbol
> > rte_pmd_ixgbe_mdio_lock
> > rte_pmd_ixgbe_mdio_unlock
> > rte_pmd_ixgbe_mdio_unlocked_read
> > rte_pmd_ixgbe_mdio_unlocked_write
> > rte_pmd_ixgbe_upd_fctrl_sbp
> 
> I wonder if we should keep PMD specific APIs as experimental (Not talking about
> mbuf 'dynfield' / 'dynflag' APIs, we can promote them).

Yes, makes sense.

> 
> If an application is using PMD specific API, not sure if it will concern about
> PMD specific APIs.
> And keeping PMD specific APIs lets us remove them as soon as we can, also adds
> additional discourage for users to use them.

Can update this to DPDK ABI Policy, section 3.5.3.
https://doc.dpdk.org/guides/contributing/abi_policy.html

> 
> >
> > Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
> 
> 
> <...>
>
Ray Kinsella Sept. 1, 2021, 1:55 p.m. UTC | #3 
On 01/09/2021 12:13, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Sent: Wednesday, September 1, 2021 17:02
>> To: Wang, Haiyue <haiyue.wang@intel.com>; dev@dpdk.org
>> Cc: mdr@ashroe.eu; thomas@monjalon.net
>> Subject: Re: [dpdk-dev] [PATCH v1 1/3] net/ixgbe: promote some API to stable
>>
>> On 9/1/2021 6:07 AM, Haiyue Wang wrote:
>>> The DPDK Symbol Bot reports:
>>> Please note the symbols listed below have expired. In line with the
>>> DPDK ABI policy, they should be scheduled for removal, in the next
>>> DPDK release.
>>>
>>> Symbol
>>> rte_pmd_ixgbe_mdio_lock
>>> rte_pmd_ixgbe_mdio_unlock
>>> rte_pmd_ixgbe_mdio_unlocked_read
>>> rte_pmd_ixgbe_mdio_unlocked_write
>>> rte_pmd_ixgbe_upd_fctrl_sbp
>>
>> I wonder if we should keep PMD specific APIs as experimental (Not talking about
>> mbuf 'dynfield' / 'dynflag' APIs, we can promote them).
> 
> Yes, makes sense.
> 
>>
>> If an application is using PMD specific API, not sure if it will concern about
>> PMD specific APIs.
>> And keeping PMD specific APIs lets us remove them as soon as we can, also adds
>> additional discourage for users to use them.
> 
> Can update this to DPDK ABI Policy, section 3.5.3.
> https://doc.dpdk.org/guides/contributing/abi_policy.html

I understand and agree.
However we never made any exceptions for PMD specific APIs in the policy.

Leave them as experimental for the moment.
I will add a clause to the policy ....

Thomas / David - any opinion?

> 
>>
>>>
>>> Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
>>
>>
>> <...>
>>
>
diff mbox series

Patch

diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.h b/drivers/net/ixgbe/rte_pmd_ixgbe.h
index 90fc8160b1..7fcdbe7452 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe.h
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe.h
@@ -586,7 +586,6 @@  int rte_pmd_ixgbe_bypass_wd_reset(uint16_t port);
  *   - (-ENODEV) if *port* invalid.
  *   - (IXGBE_ERR_SWFW_SYNC) If sw/fw semaphore acquisition failed
  */
-__rte_experimental
 int
 rte_pmd_ixgbe_mdio_lock(uint16_t port);
 
@@ -600,7 +599,6 @@  rte_pmd_ixgbe_mdio_lock(uint16_t port);
  *   - (-ENOTSUP) if hardware doesn't support.
  *   - (-ENODEV) if *port* invalid.
  */
-__rte_experimental
 int
 rte_pmd_ixgbe_mdio_unlock(uint16_t port);
 
@@ -622,7 +620,6 @@  rte_pmd_ixgbe_mdio_unlock(uint16_t port);
  *   - (-ENODEV) if *port* invalid.
  *   - (IXGBE_ERR_PHY) If PHY read command failed
  */
-__rte_experimental
 int
 rte_pmd_ixgbe_mdio_unlocked_read(uint16_t port, uint32_t reg_addr,
 				 uint32_t dev_type, uint16_t *phy_data);
@@ -646,7 +643,6 @@  rte_pmd_ixgbe_mdio_unlocked_read(uint16_t port, uint32_t reg_addr,
  *   - (-ENODEV) if *port* invalid.
  *   - (IXGBE_ERR_PHY) If PHY read command failed
  */
-__rte_experimental
 int
 rte_pmd_ixgbe_mdio_unlocked_write(uint16_t port, uint32_t reg_addr,
 				  uint32_t dev_type, uint16_t phy_data);
@@ -725,7 +721,6 @@  enum {
  *   - (-ENODEV) if *port* invalid.
  *   - (-ENOTSUP) if hardware doesn't support this feature.
  */
-__rte_experimental
 int
 rte_pmd_ixgbe_upd_fctrl_sbp(uint16_t port, int enable);
 
diff --git a/drivers/net/ixgbe/version.map b/drivers/net/ixgbe/version.map
index bca5cc5826..f0f29d8749 100644
--- a/drivers/net/ixgbe/version.map
+++ b/drivers/net/ixgbe/version.map
@@ -16,6 +16,10 @@  DPDK_22 {
 	rte_pmd_ixgbe_macsec_enable;
 	rte_pmd_ixgbe_macsec_select_rxsa;
 	rte_pmd_ixgbe_macsec_select_txsa;
+	rte_pmd_ixgbe_mdio_lock;
+	rte_pmd_ixgbe_mdio_unlock;
+	rte_pmd_ixgbe_mdio_unlocked_read;
+	rte_pmd_ixgbe_mdio_unlocked_write;
 	rte_pmd_ixgbe_ping_vf;
 	rte_pmd_ixgbe_set_all_queues_drop_en;
 	rte_pmd_ixgbe_set_tc_bw_alloc;
@@ -31,6 +35,7 @@  DPDK_22 {
 	rte_pmd_ixgbe_set_vf_vlan_filter;
 	rte_pmd_ixgbe_set_vf_vlan_insert;
 	rte_pmd_ixgbe_set_vf_vlan_stripq;
+	rte_pmd_ixgbe_upd_fctrl_sbp;
 
 	local: *;
 };
@@ -40,9 +45,4 @@  EXPERIMENTAL {
 
 	rte_pmd_ixgbe_get_fdir_info;
 	rte_pmd_ixgbe_get_fdir_stats;
-	rte_pmd_ixgbe_mdio_lock;
-	rte_pmd_ixgbe_mdio_unlock;
-	rte_pmd_ixgbe_mdio_unlocked_read;
-	rte_pmd_ixgbe_mdio_unlocked_write;
-	rte_pmd_ixgbe_upd_fctrl_sbp;
 };