From: Sunil Kumar Kori <skori@marvell.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
"dev@dpdk.org" <dev@dpdk.org>,
Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
Stephen Hemminger <stephen@networkplumber.org>,
David Marchand <david.marchand@redhat.com>,
Bruce Richardson <bruce.richardson@intel.com>
Subject: RE: [EXTERNAL] Re: [PATCH v3 1/1] ethdev: add support to provide link type
Date: Thu, 14 Aug 2025 05:09:50 +0000 [thread overview]
Message-ID: <CO6PR18MB386034432836E3AFA6C992FDB435A@CO6PR18MB3860.namprd18.prod.outlook.com> (raw)
In-Reply-To: <1975832.6tgchFWduM@thomas>
> 13/08/2025 10:43, skori@marvell.com:
> > + * Ethernet port type
>
> You mean "link port type"
>
Ack.
> > + */
> > +#define RTE_ETH_LINK_TYPE_NONE 0 /**< Not defined */
> > +#define RTE_ETH_LINK_TYPE_TP 1 /**< Twisted Pair */
> > +#define RTE_ETH_LINK_TYPE_AUI 2 /**< Attachment Unit Interface */
> > +#define RTE_ETH_LINK_TYPE_MII 3 /**< Media Independent Interface */
> > +#define RTE_ETH_LINK_TYPE_FIBRE 4 /**< Fibre */
>
> In general we use the US word "fiber",
> but we are not very consistent, so it is not a strong opinion.
>
Ack. I will change it.
> > +#define RTE_ETH_LINK_TYPE_BNC 5 /**< BNC */
> > +#define RTE_ETH_LINK_TYPE_DA 6 /**< Direct Attach copper */
> > +#define RTE_ETH_LINK_TYPE_SGMII 7 /**< SGMII */
> > +#define RTE_ETH_LINK_TYPE_QSGMII 8 /**< QSGMII */
> > +#define RTE_ETH_LINK_TYPE_XFI 9 /**< XFI */
> > +#define RTE_ETH_LINK_TYPE_SFI 10 /**< SFI */
> > +#define RTE_ETH_LINK_TYPE_XLAUI 11 /**< XLAUI */
> > +#define RTE_ETH_LINK_TYPE_GAUI 12 /**< GAUI */
> > +#define RTE_ETH_LINK_TYPE_XAUI 13 /**< XAUI */
> > +#define RTE_ETH_LINK_TYPE_GBASE 14 /**< GBASE */
> > +#define RTE_ETH_LINK_TYPE_CAUI 15 /**< CAUI */
> > +#define RTE_ETH_LINK_TYPE_LAUI 16 /**< LAUI */
> > +#define RTE_ETH_LINK_TYPE_SFP 17 /**< SFP */
> > +#define RTE_ETH_LINK_TYPE_SFP_DD 18 /**< SFP_DD */
>
> You should use more full words in comments, at least for DD.
I thought that these are standard and well known. So didn't add but there is no harm in adding comments. I will add that.
>
> > +#define RTE_ETH_LINK_TYPE_SFP_PLUS 19 /**< SFP_PLUS */
>
> Please add more spaces to allow a correct alignment.
>
Ack.
> > +#define RTE_ETH_LINK_TYPE_SFP28 20 /**< SFP28 */
> > +#define RTE_ETH_LINK_TYPE_QSFP 21 /**< QSFP */
> > +#define RTE_ETH_LINK_TYPE_QSFP_PLUS 22 /**< QSFP_PLUS */ #define
> > +RTE_ETH_LINK_TYPE_QSFP28 23 /**< QSFP28 */ #define
> > +RTE_ETH_LINK_TYPE_QSFP56 24 /**< QSFP56 */ #define
> > +RTE_ETH_LINK_TYPE_QSFP_DD 25 /**< QSFP_DD */ #define
> > +RTE_ETH_LINK_TYPE_OTHER 0x1F /**< Other type */
>
> Why the last one is in hexadecimal? and why 1F?
>
> Is there a logic in the order and numbering for this list?
>
> Why not using an enum?
>
- As struct rte_eth_link:: link_type is a 5 bits field. Hence used the last value as other/unknown link type. We can change it to decimal value.
- I have no reasoning for numbering.
- Yes, It be kept in enum. No strong opinion on this.
> Thanks
>
>
>
>
next prev parent reply other threads:[~2025-08-14 5:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 11:31 [PATCH] " skori
2025-06-05 15:26 ` Stephen Hemminger
2025-06-06 9:28 ` [PATCH v2 1/1] " skori
2025-06-06 9:54 ` Morten Brørup
2025-06-06 15:23 ` Stephen Hemminger
2025-06-10 5:02 ` [EXTERNAL] " Sunil Kumar Kori
2025-06-10 6:45 ` Morten Brørup
2025-08-13 7:42 ` Sunil Kumar Kori
2025-08-13 8:42 ` [PATCH] " skori
2025-08-13 8:43 ` [PATCH v3 1/1] " skori
2025-08-13 10:25 ` Thomas Monjalon
2025-08-13 12:16 ` Ivan Malov
2025-08-13 14:17 ` Stephen Hemminger
2025-08-14 5:09 ` Sunil Kumar Kori [this message]
2025-08-13 15:04 ` Stephen Hemminger
2025-08-14 8:10 ` [PATCH v4 " skori
2025-08-14 9:04 ` Morten Brørup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CO6PR18MB386034432836E3AFA6C992FDB435A@CO6PR18MB3860.namprd18.prod.outlook.com \
--to=skori@marvell.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ndabilpuram@marvell.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).