Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Wojciech Drewek <wojciech.drewek@intel.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: pabeni@redhat.com, netdev@vger.kernel.org, edumazet@google.com,
	marcin.szycik@linux.intel.com, anthony.l.nguyen@intel.com,
	idosch@nvidia.com, kuba@kernel.org,
	intel-wired-lan@lists.osuosl.org, przemyslaw.kitszel@intel.com
Subject: Re: [Intel-wired-lan] [PATCH net-next 0/3] ethtool: Max power support
Date: Tue, 2 Apr 2024 13:38:59 +0200	[thread overview]
Message-ID: <a3fd2b83-93af-4a59-a651-1ffe0dbddbe4@intel.com> (raw)
In-Reply-To: <38d874e3-f25b-4af2-8c1c-946ab74c1925@lunn.ch>



On 30.03.2024 22:57, Andrew Lunn wrote:
> On Fri, Mar 29, 2024 at 10:23:18AM +0100, Wojciech Drewek wrote:
>> Some ethernet modules use nonstandard power levels [1]. Extend ethtool
>> module implementation to support new attributes that will allow user
>> to change maximum power. Rename structures and functions to be more
>> generic. Introduce an example of the new API in ice driver.
>>
>> Ethtool examples:
>> $ ethtool --show-module enp1s0f0np0
>> Module parameters for enp1s0f0np0:
>> power-min-allowed: 1000 mW
>> power-max-allowed: 3000 mW
>> power-max-set: 1500 mW
>>
>> $ ethtool --set-module enp1s0f0np0 power-max-set 4000
> 
> We have had a device tree property for a long time:
> 
>   maximum-power-milliwatt:
>     minimum: 1000
>     default: 1000
>     description:
>       Maximum module power consumption Specifies the maximum power consumption
>       allowable by a module in the slot, in milli-Watts. Presently, modules can
>       be up to 1W, 1.5W or 2W.
> 
> Could you flip the name around to be consistent with DT?

Yea, I'm open to any name suggestion although I don't like the unit in the parameter name :) 

> 
>> minimum-power-allowed: 1000 mW
>> maximum-power-allowed: 3000 mW
>> maximum-power-set: 1500 mW
> 
> Also, what does minimum-power-allowed actually tell us? Do you imagine
> it will ever be below 1W because of bad board design? Do you have a
> bad board design which does not allow 1W?

Yes. in case of QSFP we don't support 1W, 1.5W is the minimum.
This parameter tells the user what is the lowest limit he can set.

> 
> Also, this is about the board, the SFP cage, not the actual SFP
> module?  Maybe the word cage needs to be in these names?

It's about cage. Thanks for bringing it to my attention because now I
see it might be misleading. I'm extending {set|show}-module command
but the changes are about max power in the cage. With that in mind
I agree that adding 'cage' to the names makes sense.

> 
> Do we want to be able to enumerate what the module itself supports?
> If so, we need to include module in the name, to identify the numbers
> are about the module, not the cage.

I hope that my previous paragraph answers this as well.

> 
>     Andrew

  parent reply	other threads:[~2024-04-02 11:39 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-29  9:23 [Intel-wired-lan] [PATCH net-next 0/3] ethtool: Max power support Wojciech Drewek
2024-03-29  9:23 ` [Intel-wired-lan] [PATCH net-next 1/3] ethtool: Make module API more generic Wojciech Drewek
2024-03-29  9:23 ` [Intel-wired-lan] [PATCH net-next 2/3] ethtool: Introduce max power support Wojciech Drewek
2024-03-29 22:29   ` Jakub Kicinski
2024-03-29 22:29     ` Jakub Kicinski
2024-04-02 11:25     ` Wojciech Drewek
2024-04-02 14:34       ` Jakub Kicinski
2024-04-03 10:19         ` Wojciech Drewek
2024-04-04  0:18           ` Jakub Kicinski
2024-04-04 12:19             ` Wojciech Drewek
2024-03-30 22:14   ` Andrew Lunn
2024-03-30 22:14     ` Andrew Lunn
2024-04-03  9:50     ` Wojciech Drewek
2024-03-29  9:23 ` [Intel-wired-lan] [PATCH net-next 3/3] ice: Implement ethtool max power configuration Wojciech Drewek
2024-03-29 22:16 ` [Intel-wired-lan] [PATCH net-next 0/3] ethtool: Max power support Jakub Kicinski
2024-04-02  9:58   ` Wojciech Drewek
2024-03-30 21:57 ` Andrew Lunn
2024-03-30 21:57   ` Andrew Lunn
2024-04-02 11:38   ` Wojciech Drewek [this message]
2024-04-02 14:25     ` Jakub Kicinski
2024-04-02 14:53       ` Andrew Lunn
2024-04-02 14:46     ` Andrew Lunn
2024-04-02 14:57       ` Jakub Kicinski
2024-04-03 13:18       ` Wojciech Drewek
2024-04-03 13:40         ` Andrew Lunn
2024-04-04 12:21           ` Wojciech Drewek
2024-04-03 13:49         ` Andrew Lunn
2024-04-04 12:45           ` Wojciech Drewek
2024-04-04 13:53             ` Andrew Lunn
2024-04-09 12:20               ` Wojciech Drewek
2024-04-09 13:39                 ` Andrew Lunn
2024-04-12 13:21                   ` Wojciech Drewek
2024-04-15 22:03                     ` Andrew Lunn
2024-04-18 11:48                       ` Wojciech Drewek

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=a3fd2b83-93af-4a59-a651-1ffe0dbddbe4@intel.com \
    --to=wojciech.drewek@intel.com \
    --cc=andrew@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=edumazet@google.com \
    --cc=idosch@nvidia.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=marcin.szycik@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@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