netdev - Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKOOJTw54DxitbYHW7vNVWRv9BbsdmW_ARTgpMu5HBVjkTeQ5w@mail.gmail.com>
Date:   Mon, 30 Nov 2020 10:00:16 -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 30, 2020 at 9:14 AM Jiri Pirko <jiri@...nulli.us> wrote:

> >> 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.
>
> I don't follow what exactly are you implying. Could you elaborate a bit
> more?

Perhaps an example...

Consider a physical QSFP connector comprising 4 lanes. Today, if the
speed is forced, we would achieve 100G speeds using all 4 lanes with
NRZ encoding. If we configure the port for PAM4 encoding at the same
speed, then we only require 2 of the available 4 lanes. The remaining 2
lanes are wasted. If we only require 2 of the 4 lanes, why not split the
port and request the same speed of one of the now split out ports? Now,
this same speed is only achievable using PAM4 encoding (it is implied)
and we have a spare, potentially usable, assuming an appropriate break-
out cable, port instead of the 2 unused lanes.

So concretely, I'm suggesting that if we want to force PAM4 at the lower
speeds, split the port and then we don't need an ethtool interface change
at all to achieve the same goal. Having a spare (potentially usable) port
is better than spare (unusable) lanes.

Now, if the port can't be split for some reason (perhaps there aren't
sufficient device MAC resources, stats contexts, whatever), then that's
a different story. But, even so, perhaps the port lane topology more
appropriately belongs as part of a device configuration interface in
devlink and the number of lanes available to a port should be a
property of the port instead of a link mode knob?

Regards,
Edwin Peer

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4160 bytes)