[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKOOJTxEgR_E5YL2Y_wPUw_MFggLt8jbqyh5YOEKpH0=YHp7ug@mail.gmail.com>
Date: Mon, 30 Nov 2020 09:01:43 -0800
From: Edwin Peer <edwin.peer@...adcom.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Ido Schimmel <idosch@...sch.org>, netdev <netdev@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, jiri@...dia.com,
danieller@...dia.com, andrew@...n.ch, f.fainelli@...il.com,
mkubecek@...e.cz, mlxsw@...dia.com,
Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI
with lanes
On Mon, Nov 23, 2020 at 1:40 AM Jiri Pirko <jiri@...nulli.us> wrote:
> >Why can't this be implied by port break-out configuration? For higher
> >speed signalling modes like PAM4, what's the difference between a
> >port with unused lanes vs the same port split into multiple logical
> >ports? In essence, the driver could then always choose the slowest
>
> There is a crucial difference. Split port is configured alwasy by user.
> Each split port has a devlink instace, netdevice associated with it.
> It is one level above the lanes.
Right, but the one still implies the other. Splitting the port implies fewer
lanes available.
I understand the concern if the device cannot provide sufficient MAC
resources to provide for the additional ports, but leaving a net device
unused (with the option to utilize an additional, now spare, port) still
seems better to me than leaving lanes unused and always wasted.
Otherwise, the earlier suggestion of fully specifying the forced link
mode (although I don't think Andrew articulated it quite that way)
instead of a forced speed and separate lane mode makes most
sense.
Regards,
Edwin Peer
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4160 bytes)
Powered by blists - more mailing lists