Hi Morten and Stephen,

To address your comments, I revisited to change and concluded following points:

1. Extending Link Types Alongside Legacy:

I'm aligned on extending link types while retaining legacy support — No 
concerns here. I will add following link type to the list.

        - NONE
        - TP
        - AUI
        - MII
        - FIBRE
        - BNC
        - DA
        - SGMII
        - QSGMII
        - XFI
        - SFI
        - XLAUI
        - GAUI
        - SFI
        - XAUI
        - XLAUI
        - GAUI
        - GBASE
        - CAUI
        - LAUI
        - SFP
        - SFP_DD
        - SFP_PLUS
        - SFP28
        - QSFP
        - QSFP_PLUS
        - QSFP28
        - QSFP56
        - QSFP_DD
        - OTHER

2. ABI Breakage Concern:
"I'm not entirely clear on how this change results in an ABI breakage, as the 
new bit field is added within the existing space. Could you please elaborate on 
the specific aspects that lead to ABI incompatibility ?" Worst case, since this 
is 25.11, API breakage is fine.

3. Reporting Link Type by Drivers:
General APIs often expose capabilities, and drivers selectively implement them. 
Setting the link type to 0 when unsupported is a reasonable fallback.
Ensuring 0 is treated as “unknown” or “not supported” rather than misleading.

4. Regarding management interfaces for PHYs or modules:
This patch does not introduce any management APIs for PHYs or modules. Its sole 
purpose is to expose the link type as an additional attribute to the user. Any 
support for PHY or module management should be handled separately and is 
outside the scope of this change.

Thanks
Sunil Kumar Kori

> > From: Sunil Kumar Kori [mailto:sk...@marvell.com]
> > Sent: Tuesday, 10 June 2025 07.02
> >
> > > On Fri, 6 Jun 2025 11:54:52 +0200
> > > Morten Brørup <m...@smartsharesystems.com> wrote:
> > >
> > > > > From: sk...@marvell.com [mailto:sk...@marvell.com]
> > > > > Sent: Friday, 6 June 2025 11.28
> > > > >
> > > > > From: Sunil Kumar Kori <sk...@marvell.com>
> > > > >
> > > > > Adding link type parameter to provide the type of port like
> > > > > twisted pair, fibre etc.
> > > > >
> > > > > Also added an API to convert the RTE_ETH_LINK_TYPE_XXX to a
> > > > > readable string.
> > > > >
> > > > > Signed-off-by: Nithin Dabilpuram <ndabilpu...@marvell.com>
> > > > > Signed-off-by: Sunil Kumar Kori <sk...@marvell.com>
> > > > > ---
> > > > > +/**@{@name PORT type
> > > > > + * Ethernet port type
> > > > > + */
> > > > > +#define RTE_ETH_LINK_TYPE_NONE  0x00 /**< Not defined */
> > > > > +#define RTE_ETH_LINK_TYPE_TP    0x01 /**< Twisted Pair */
> > > > > +#define RTE_ETH_LINK_TYPE_AUI   0x02 /**< Attachment Unit Interface 
> > > > > */
> > > > > +#define RTE_ETH_LINK_TYPE_MII   0x03 /**< Media Independent Interface
> > > > > */
> > > > > +#define RTE_ETH_LINK_TYPE_FIBRE 0x04 /**< Fibre */
> > > > > +#define RTE_ETH_LINK_TYPE_BNC   0x05 /**< BNC */
> > > > > +#define RTE_ETH_LINK_TYPE_DA    0x06 /**< Direct Attach copper */
> > > > > +#define RTE_ETH_LINK_TYPE_OTHER 0x1F /**< Other type */ /**@}*/
> > > >

Reply via email to