All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Danielle Ratson <danieller@mellanox.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, jiri@nvidia.com,
	andrew@lunn.ch, f.fainelli@gmail.com, mkubecek@suse.cz,
	mlxsw@nvidia.com, idosch@nvidia.com,
	Danielle Ratson <danieller@nvidia.com>
Subject: Re: [PATCH net-next repost v2 2/7] ethtool: Get link mode in use instead of speed and duplex parameters
Date: Thu, 7 Jan 2021 16:42:40 -0800	[thread overview]
Message-ID: <20210107164240.17fcda6e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20210106130622.2110387-3-danieller@mellanox.com>

On Wed,  6 Jan 2021 15:06:17 +0200 Danielle Ratson wrote:
> From: Danielle Ratson <danieller@nvidia.com>
> 
> Currently, when user space queries the link's parameters, as speed and
> duplex, each parameter is passed from the driver to ethtool.
> 
> Instead, get the link mode bit in use, and derive each of the parameters
> from it in ethtool.
> 
> Signed-off-by: Danielle Ratson <danieller@nvidia.com>
> ---
>  Documentation/networking/ethtool-netlink.rst |   1 +
>  include/linux/ethtool.h                      |   1 +
>  include/uapi/linux/ethtool.h                 |   2 +
>  net/ethtool/linkmodes.c                      | 252 ++++++++++---------
>  4 files changed, 137 insertions(+), 119 deletions(-)
> 
> diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
> index 05073482db05..c21e71e0c0e8 100644
> --- a/Documentation/networking/ethtool-netlink.rst
> +++ b/Documentation/networking/ethtool-netlink.rst
> @@ -406,6 +406,7 @@ Kernel response contents:
>    ``ETHTOOL_A_LINKMODES_PEER``                bitset  partner link modes
>    ``ETHTOOL_A_LINKMODES_SPEED``               u32     link speed (Mb/s)
>    ``ETHTOOL_A_LINKMODES_DUPLEX``              u8      duplex mode
> +  ``ETHTOOL_A_LINKMODES_LINK_MODE``           u8      link mode

Are there other places in the uapi we already limit ourselves to 
u8 / max 255? Otherwise u32 is better, the nlattr will be padded,
anyway.

>    ``ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFG``    u8      Master/slave port mode
>    ``ETHTOOL_A_LINKMODES_MASTER_SLAVE_STATE``  u8      Master/slave port state
>    ==========================================  ======  ==========================
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index afae2beacbc3..668a7737a483 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -129,6 +129,7 @@ struct ethtool_link_ksettings {
>  		__ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertising);
>  	} link_modes;
>  	u32	lanes;
> +	enum ethtool_link_mode_bit_indices link_mode;
>  };
>  
>  /**
> diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
> index 80edae2c24f7..f61f726d1567 100644
> --- a/include/uapi/linux/ethtool.h
> +++ b/include/uapi/linux/ethtool.h
> @@ -1733,6 +1733,8 @@ enum ethtool_link_mode_bit_indices {
>  
>  #define SPEED_UNKNOWN		-1
>  
> +#define LINK_MODE_UNKNOWN	-1

Why do we need this? Link mode is output only, so just don't report 
the nlattr when it's unknown.

>  static inline int ethtool_validate_speed(__u32 speed)
>  {
>  	return speed <= INT_MAX || speed == (__u32)SPEED_UNKNOWN;


> @@ -29,7 +150,9 @@ static int linkmodes_prepare_data(const struct ethnl_req_info *req_base,
>  {
>  	struct linkmodes_reply_data *data = LINKMODES_REPDATA(reply_base);
>  	struct net_device *dev = reply_base->dev;
> +	const struct link_mode_info *link_info;
>  	int ret;
> +	unsigned int i;

rev xmas tree

>  	data->lsettings = &data->ksettings.base;
>  
> @@ -43,6 +166,16 @@ static int linkmodes_prepare_data(const struct ethnl_req_info *req_base,
>  		goto out;
>  	}
>  
> +	if (data->ksettings.link_mode) {
> +		for (i = 0; i < __ETHTOOL_LINK_MODE_MASK_NBITS; i++) {
> +			if (data->ksettings.link_mode == i) {

I stared at this for a minute, the loop is entirely pointless, right?

> +				link_info = &link_mode_params[i];
> +				data->lsettings->speed = link_info->speed;
> +				data->lsettings->duplex = link_info->duplex;
> +			}
> +		}
> +	}
> +
>  	data->peer_empty =
>  		bitmap_empty(data->ksettings.link_modes.lp_advertising,
>  			     __ETHTOOL_LINK_MODE_MASK_NBITS);

  reply	other threads:[~2021-01-08  0:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 13:06 [PATCH net-next repost v2 0/7] Support setting lanes via ethtool Danielle Ratson
2021-01-06 13:06 ` [PATCH net-next repost v2 1/7] ethtool: Extend link modes settings uAPI with lanes Danielle Ratson
2021-01-08  0:35   ` Jakub Kicinski
2021-01-11 14:00     ` Danielle Ratson
2021-01-11 17:57       ` Jakub Kicinski
2021-01-06 13:06 ` [PATCH net-next repost v2 2/7] ethtool: Get link mode in use instead of speed and duplex parameters Danielle Ratson
2021-01-08  0:42   ` Jakub Kicinski [this message]
2021-01-08  1:11     ` Andrew Lunn
2021-01-06 13:06 ` [PATCH net-next repost v2 3/7] ethtool: Expose the number of lanes in use Danielle Ratson
2021-01-06 13:06 ` [PATCH net-next repost v2 4/7] mlxsw: ethtool: Remove max lanes filtering Danielle Ratson
2021-01-06 13:06 ` [PATCH net-next repost v2 5/7] mlxsw: ethtool: Add support for setting lanes when autoneg is off Danielle Ratson
2021-01-06 13:06 ` [PATCH net-next repost v2 6/7] mlxsw: ethtool: Pass link mode in use to ethtool Danielle Ratson
2021-01-06 13:06 ` [PATCH net-next repost v2 7/7] net: selftests: Add lanes setting test Danielle Ratson
2021-01-08  0:45   ` Jakub Kicinski
2021-01-10 12:35     ` Danielle Ratson
2021-01-07 17:36 ` [PATCH net-next repost v2 0/7] Support setting lanes via ethtool Edwin Peer

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=20210107164240.17fcda6e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=danieller@mellanox.com \
    --cc=danieller@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@nvidia.com \
    --cc=jiri@nvidia.com \
    --cc=mkubecek@suse.cz \
    --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 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.