From: huangdengdui <huangdengdui@huawei.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>, <dev@dpdk.org>,
<damodharam.ammepalli@broadcom.com>
Cc: <aman.deep.singh@intel.com>, <yuying.zhang@intel.com>,
<thomas@monjalon.net>, <andrew.rybchenko@oktetlabs.ru>,
<stephen@networkplumber.org>, <jerinjacobk@gmail.com>,
<ajit.khaparde@broadcom.com>, <liuyonglong@huawei.com>,
<fengchengwen@huawei.com>, <haijie1@huawei.com>,
<lihuisong@huawei.com>
Subject: Re: [PATCH v2 0/6] support setting lanes
Date: Thu, 16 May 2024 20:48:21 +0800 [thread overview]
Message-ID: <ec8befe8-46a0-4fb4-9ebb-fcd03d0fb8b4@huawei.com> (raw)
In-Reply-To: <51c392a2-0154-4191-b6cb-7ead9888eefa@amd.com>
Hi, Ferruh
Sorry for replying your email very late.
The answers to your questions are as follows. Please correct me if I am wrong.
On 2024/4/4 21:58, Ferruh Yigit wrote:
>
> Hi Dengdui, Damodharam,
>
> As details of the implementation under discussion, I have a high level
> question.
>
> Why/when an application need to configure the lanes explicitly?
>
> In above description, it mentions if one port is configured as 4x25G and
> other 2x50G, port can't be up. How do you end up being in this situation?
>
According to the Ethernet standard document[1], speed and lanes need to be configured to the PHY together.
Currently, the application just set one speed like 100G to the driver.
And this doesn't matter with lane number.
Currently, the lane number of one NIC for a specified speed depand on their default behavior.
As a result, this situation will be happened.
> Lets assume first port is configured as 100G, and FW configured it as
> 4x25G, and again user configured second port as 100G, why FW can't
> detect this and configure ports with correct lane configuration?
When the auto-negotiation is disabled, FW of the local port never know the configuration of
the peer port.
After all, not all NICs support auto-negotiation feature.
>
> In this case, if we push the responsibility to the user, when user is
> configuring the second port how she will know what is the lane
> configuration for first port, and what is the proper lane configuration
> for the second port?
So we need to support the lane query function for above reason.
>
> Instead of pushing this configuration to user, why it can't be handled
> internally?
>
> As long as user requested speed configured by device, the lane
> configuration has no impact to the user, right?> Is there a case/reason user need to explicitly set, lets say PAM4
> against NRZ?
>
Sorry, I can not understand what you mean.
[1]
https://lore.kernel.org/netdev/20201010154119.3537085-1-idosch@idosch.org/T/
next prev parent reply other threads:[~2024-05-16 12:48 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-12 7:52 [PATCH 0/3] " Dengdui Huang
2024-03-12 7:52 ` [PATCH 1/3] ethdev: " Dengdui Huang
2024-03-19 3:02 ` Stephen Hemminger
2024-03-20 1:16 ` huangdengdui
2024-03-12 7:52 ` [PATCH 2/3] net/hns3: " Dengdui Huang
2024-03-12 7:52 ` [PATCH 3/3] app/testpmd: " Dengdui Huang
2024-03-15 21:47 ` Damodharam Ammepalli
2024-03-19 2:38 ` huangdengdui
2024-03-22 7:09 ` [PATCH v2 0/6] " Dengdui Huang
2024-03-22 7:09 ` [PATCH v2 1/6] ethdev: " Dengdui Huang
2024-03-22 13:58 ` Thomas Monjalon
2024-03-22 15:15 ` Ajit Khaparde
2024-03-22 17:32 ` Tyler Retzlaff
2024-03-22 22:30 ` Damodharam Ammepalli
2024-03-25 6:24 ` huangdengdui
2024-03-25 9:30 ` Thomas Monjalon
2024-03-25 21:14 ` Damodharam Ammepalli
2024-03-26 1:42 ` lihuisong (C)
2024-03-26 3:45 ` Ajit Khaparde
2024-03-26 10:30 ` Thomas Monjalon
2024-03-26 11:15 ` lihuisong (C)
2024-03-26 13:47 ` Ajit Khaparde
2024-03-26 18:11 ` Ajit Khaparde
2024-03-26 18:21 ` Damodharam Ammepalli
2024-03-30 11:38 ` huangdengdui
2024-04-01 20:07 ` Thomas Monjalon
2024-04-01 22:29 ` Damodharam Ammepalli
2024-05-22 20:44 ` Ferruh Yigit
2024-04-02 8:37 ` huangdengdui
2024-04-02 15:28 ` Stephen Hemminger
2024-04-04 13:45 ` Ferruh Yigit
2024-03-29 3:25 ` lihuisong (C)
2024-03-22 7:09 ` [PATCH v2 2/6] test: updated UT for " Dengdui Huang
2024-03-22 7:09 ` [PATCH v2 3/6] ethdev: add function to parse link mode info Dengdui Huang
2024-03-22 7:09 ` [PATCH v2 4/6] net/hns3: use parse link mode info function Dengdui Huang
2024-03-22 7:09 ` [PATCH v2 5/6] net/hns3: support setting lanes Dengdui Huang
2024-03-22 7:09 ` [PATCH v2 6/6] app/testpmd: " Dengdui Huang
2024-04-04 13:58 ` [PATCH v2 0/6] " Ferruh Yigit
2024-05-16 12:48 ` huangdengdui [this message]
2024-05-22 20:49 ` Ferruh Yigit
2024-03-18 14:56 ` [PATCH 0/3] " Thomas Monjalon
2024-03-18 21:26 ` Damodharam Ammepalli
2024-03-18 21:42 ` Stephen Hemminger
2024-03-18 22:55 ` Ajit Khaparde
2024-03-20 11:41 ` Thomas Monjalon
2024-03-20 12:31 ` Ferruh Yigit
2024-03-21 2:02 ` huangdengdui
2024-03-21 8:28 ` Thomas Monjalon
2024-03-22 2:28 ` huangdengdui
2024-03-22 4:38 ` Jerin Jacob
2024-03-22 5:25 ` Ajit Khaparde
2024-03-22 5:51 ` Jerin Jacob
2024-03-22 13:51 ` Thomas Monjalon
2024-03-25 14:04 ` Jerin Jacob
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=ec8befe8-46a0-4fb4-9ebb-fcd03d0fb8b4@huawei.com \
--to=huangdengdui@huawei.com \
--cc=ajit.khaparde@broadcom.com \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=damodharam.ammepalli@broadcom.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=haijie1@huawei.com \
--cc=jerinjacobk@gmail.com \
--cc=lihuisong@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=yuying.zhang@intel.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 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).