From: Thomas Monjalon <thomas@monjalon.net>
To: Huisong Li <lihuisong@huawei.com>
Cc: dev@dpdk.org, ferruh.yigit@intel.com
Subject: Re: [dpdk-dev] Questions about reporting auto-negotiation capability
Date: Mon, 29 Mar 2021 09:03:28 +0200 [thread overview]
Message-ID: <9105928.7imIDBDKWL@thomas> (raw)
In-Reply-To: <2a9f3c44-44da-854b-8b25-772a3570baa4@huawei.com>
29/03/2021 06:02, Huisong Li:
> Hi, all
>
> 'speed_capa' in struct rte_eth_dev_info is defined as follows:
>
> uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */
>
>
> Most PMD drivers use this field to report the speeds capability
> supported by the device to the upper-layer app.
>
> But it seems that few NICs report their auto-negotiation capability
> through this field. If NIC also uses it to report
>
> their auto-negotiation capability through this field, and should set it
> to ETH_LINK_SPEED_AUTONEG(0) based on
>
> the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the
> report of the speeds capability .
>
>
> I don't know how to correctly report the auto-negotiation capability of
> the device. Thanks for your reply.
ETH_LINK_SPEED_AUTONEG is not for capabilities.
Anyway, if it is set, it changes nothing (0) in the bitmap.
I see mlx5 is wrongly using it.
speed_capa is only for enumerating speeds.
next prev parent reply other threads:[~2021-03-29 7:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-29 4:02 [dpdk-dev] Questions about reporting auto-negotiation capability Huisong Li
2021-03-29 7:03 ` Thomas Monjalon [this message]
2021-03-29 7:19 ` Thomas Monjalon
2021-03-29 11:44 ` Huisong Li
2021-03-29 12:05 ` Thomas Monjalon
2021-03-29 14:18 ` Ajit Khaparde
2021-03-29 7:28 ` [dpdk-dev] [PATCH] drivers/net: remove useless autoneg capability Thomas Monjalon
2021-03-29 14:12 ` Ajit Khaparde
2021-04-01 13:26 ` Ferruh Yigit
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=9105928.7imIDBDKWL@thomas \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=lihuisong@huawei.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.