> 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 */ /**@}*/
> > >
> > > I don't see the use case for this patch, when only ancient interface types
> are
> > defined.
> > > How about RMII, GMII, RGMII, XGMII, XAUI, XAUI4, CAUI4, SFP, SFP+, SFP28,
> etc.
> > >
> > > Please don't blindly port stuff from Linux to DPDK.
> > >
> > >
> >
> > Agree with Morten here.
> > Plus, it isn't really much use to user unless all drivers report it.
> > Also, it breaks ABI (see build failures).
> 
> Agreed. I will try to make this implementation more useful and will share next
> version after handling the suggestions.
> Thanks.

If you choose to proceed with this, please note that APIs for managing PHYs and 
pluggable modules (SFP, etc.) would be more useful than simply indicating if 
dual-personality port is connected by Twisted Pair or SFP (which is the only 
case I can imagine for this API).
A PHY API could also be used for EEE ("Green Ethernet") and POE management, 
cable test and similar features.

Marvell makes PHYs, so please ask to your PHY people about relevant features 
for a PHY API.
This should be driven by use cases, not by what is available in Linux APIs.

Reply via email to