[v1,1/3] net/ixgbe: promote some API to stable
Checks
Commit Message
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
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>
<...>
> -----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>
>
>
> <...>
>
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>
>>
>>
>> <...>
>>
>
@@ -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);
@@ -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;
};