From: Michal Kubecek <mkubecek@suse.cz>
To: Danielle Ratson <danieller@nvidia.com>
Cc: Jiri Pirko <jiri@resnulli.us>, Andrew Lunn <andrew@lunn.ch>,
Jakub Kicinski <kuba@kernel.org>,
Ido Schimmel <idosch@idosch.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
Jiri Pirko <jiri@nvidia.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
mlxsw <mlxsw@nvidia.com>, Ido Schimmel <idosch@nvidia.com>,
"johannes@sipsolutions.net" <johannes@sipsolutions.net>
Subject: Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes
Date: Thu, 26 Nov 2020 22:07:48 +0100 [thread overview]
Message-ID: <20201126210748.mzbe7ei3wjhvryym@lion.mk-sys.cz> (raw)
In-Reply-To: <DM6PR12MB4516B65021D4107188447282D8FA0@DM6PR12MB4516.namprd12.prod.outlook.com>
On Wed, Nov 25, 2020 at 10:35:35AM +0000, Danielle Ratson wrote:
> > > What do you think of passing the link modes you have suggested as a
> > > bitmask, similar to "supported", that contains only one positive bit?
> > > Something like that:
>
> Hi Michal,
>
> Thanks for your response.
>
> Actually what I said is not very accurate.
> In ethtool, for speed 100G and 4 lanes for example, there are few link modes that fits:
> ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT
> ETHTOOL_LINK_MODE_100000baseSR4_Full_BIT
> ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT
> ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT
>
> The difference is the media. And in the driver we shrink into one bit.
> But maybe that makes passing a bitmask more sense, or am I missing something?
But as far as I understand, at any moment, only one of these will be
actually in use so that's what the driver should report. Or is the
problem that the driver cannot identify the media in use? (To be
precise: by "cannot identify" I mean "it's not possible for the driver
to find out", not "current code does not distinguish".)
Michal
next prev parent reply other threads:[~2020-11-26 21:07 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-10 15:41 [PATCH net-next 0/6] Support setting lanes via ethtool Ido Schimmel
2020-10-10 15:41 ` [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes Ido Schimmel
2020-10-11 22:37 ` Jakub Kicinski
2020-10-12 15:33 ` Danielle Ratson
2020-10-12 15:58 ` Jakub Kicinski
2020-10-13 14:29 ` Danielle Ratson
2020-10-13 15:43 ` Jakub Kicinski
2020-10-16 22:15 ` Andrew Lunn
2020-10-19 7:19 ` Danielle Ratson
2020-10-19 11:04 ` Michal Kubecek
2020-10-19 12:26 ` Jiri Pirko
2020-10-19 13:24 ` Michal Kubecek
2020-10-20 7:39 ` Danielle Ratson
2020-10-21 7:08 ` Michal Kubecek
2020-10-21 7:20 ` Danielle Ratson
2020-10-21 8:47 ` Michal Kubecek
2020-10-22 6:15 ` Danielle Ratson
2020-10-22 16:27 ` Michal Kubecek
2020-11-23 9:47 ` Danielle Ratson
2020-11-24 22:12 ` Michal Kubecek
2020-11-25 10:35 ` Danielle Ratson
2020-11-26 21:07 ` Michal Kubecek [this message]
2020-12-01 17:22 ` Danielle Ratson
2020-12-02 0:52 ` Edwin Peer
2020-12-02 1:17 ` Edwin Peer
2020-10-19 12:24 ` Jiri Pirko
2020-10-19 12:38 ` Andrew Lunn
2020-10-12 16:40 ` Michal Kubecek
2020-10-12 19:10 ` Johannes Berg
2020-10-12 20:08 ` Jakub Kicinski
2020-10-12 17:03 ` Michal Kubecek
2020-11-19 20:38 ` Edwin Peer
2020-11-23 9:40 ` Jiri Pirko
2020-11-30 17:01 ` Edwin Peer
2020-11-30 17:14 ` Jiri Pirko
2020-11-30 18:00 ` Edwin Peer
2020-12-01 11:22 ` Jiri Pirko
2020-12-02 0:32 ` Edwin Peer
2020-12-02 10:09 ` Jiri Pirko
2020-12-02 17:53 ` Edwin Peer
2020-10-10 15:41 ` [PATCH net-next 2/6] ethtool: Expose the number of lanes in use Ido Schimmel
2020-10-10 15:41 ` [PATCH net-next 3/6] mlxsw: ethtool: Remove max lanes filtering Ido Schimmel
2020-10-10 15:41 ` [PATCH net-next 4/6] mlxsw: ethtool: Add support for setting lanes when autoneg is off Ido Schimmel
2020-10-10 15:41 ` [PATCH net-next 5/6] mlxsw: ethtool: Expose the number of lanes in use Ido Schimmel
2020-10-10 15:41 ` [PATCH net-next 6/6] net: selftests: Add lanes setting test Ido Schimmel
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=20201126210748.mzbe7ei3wjhvryym@lion.mk-sys.cz \
--to=mkubecek@suse.cz \
--cc=andrew@lunn.ch \
--cc=danieller@nvidia.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@idosch.org \
--cc=idosch@nvidia.com \
--cc=jiri@nvidia.com \
--cc=jiri@resnulli.us \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
/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).