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: Thu, 4 Apr 2024 14:45:43 +0200 [thread overview]
Message-ID: <206686dc-c39b-4b52-a35c-914b93fe3f36@intel.com> (raw)
In-Reply-To: <61a89488-e79a-4175-8868-3de36af7f62d@lunn.ch>
On 03.04.2024 15:49, Andrew Lunn wrote:
>>> $ ethtool --set-module enp1s0f0np0 power-max-set 4000
>>>
>>> actually talk to the SFP module and tell it the maximum power it can
>>> consume. So in this case, it is not the cage, but the module?
>>
>> It does not work that way in ice example.
>>>
>>> Or is it talking to some entity which is managing the overall power
>>> consumption of a number of cages, and asking it to allocate a maximum
>>> of 4W to this cage. It might return an error message saying there is
>>> no power budget left?
>>
>> That's right, we talk to firmware to set those restrictions.
>> In the ice implementation, the driver is responsible for checking if the
>> overall board budget is not exceeded.
>
> So i can get the board to agree that the cage can supply 3W to the
> module, but how do i then tell the module this?
I'd assume it is not possible, if the module consumes more power
than maximum than the link will not come up and error will be printed.
>
> I would also suggest you don't focus too much on ICE. I find it better
> to think about an abstract system. A board with a power supply to a
> number of SFP cages, and some cages have modules in them. What does
> the kAPI look like, the use cases for this abstract system.
My design for this API is to have an option to get and set maximum
power that the module in the cage can consume. It's not about modifying
module's power consumption, it's about setting restrictions for it.
The use case is to let the user change maximum power in the given cage
(so he can plug in the module with higher power consumption). Before that
he will lower maximum power in different cage. Thanks to that the overall
budget for the board won't be exceeded. Does it make sense for the abstract
system you described?
>
> Andrew
>
>
>
next prev parent reply other threads:[~2024-04-04 12:45 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
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 [this message]
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=206686dc-c39b-4b52-a35c-914b93fe3f36@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