From: Ido Schimmel <idosch@idosch.org>
To: "Drewek, Wojciech" <wojciech.drewek@intel.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@intel.com>,
"idosch@nvidia.com" <idosch@nvidia.com>
Subject: Re: [PATCH iwl-next v2] ice: Disable Cage Max Power override
Date: Tue, 12 Sep 2023 17:26:37 +0300 [thread overview]
Message-ID: <ZQB1HcpTsB2Sf6Co@shredder> (raw)
In-Reply-To: <MW4PR11MB5776601FD7C2C577C78576A3FDE4A@MW4PR11MB5776.namprd11.prod.outlook.com>
On Fri, Sep 01, 2023 at 01:34:04PM +0000, Drewek, Wojciech wrote:
>
>
> > -----Original Message-----
> > From: Ido Schimmel <idosch@idosch.org>
> > Sent: środa, 30 sierpnia 2023 17:17
> > To: Drewek, Wojciech <wojciech.drewek@intel.com>
> > Cc: Jakub Kicinski <kuba@kernel.org>; intel-wired-lan@lists.osuosl.org;
> > netdev@vger.kernel.org; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>;
> > idosch@nvidia.com
> > Subject: Re: [PATCH iwl-next v2] ice: Disable Cage Max Power override
> >
> > On Tue, Aug 29, 2023 at 09:12:22AM +0000, Drewek, Wojciech wrote:
> > > In some cases users are trying to use media with power exceeding max
> > allowed value.
> > > Port split require system reboot so it feels natural to me to restore default
> > settings.
> >
> > I don't believe it's the kernel's responsibility to undo changes done by
> > external tools. Given that the tool is able to change this setting, I
> > assume it can also restore it back to default.
>
> I agree with that, but we can end up with no link if we don't restore
> default settings. Let me explain how.
>
> >
> > Moreover, it doesn't sound like port split won't work without this
> > change, so placing this change there only because we assume that a
> > reboot will follow seems random.
>
> After port split, we might end up with no link in one of the ports.
> In dual port card if we increase max pwr on the 1st cage the 2nd one
> will have max pwr decreased automatically. This might be useful if we have port
> option with count 1, the second cage is not used in this case. If we then split and
> use two ports now, the second port will use second cage which has decreased max pwr, default module
> used there will not work.
Not sure I understand how it's related to port split. You have a dual
port card with two netdevs (e.g., eth0 and eth1) and two cages. You used
some tool to increase the max power on the first cage which means that
the second cage will have its max power decreased. Now you split the
first port:
# devlink port split eth0 count 2
eth0s0 and eth0s1 correspond to the first cage. Why are they affected by
the second cage?
I have a feeling we mean different things by "port split". As far as I'm
concerned, you split a port in order to connect a splitter cable to the
cage. For example:
https://network.nvidia.com/related-docs/prod_cables/PB_MCP7H50-Vxxxyzz_200GbE_QSFP56_to_2x100GbE_QSFP56_DAC.pdf
>
> So, should we leave the restoration of the default settings to the user?
Let's first clear up the above. BTW, if a port doesn't come up because
of power issues you can try communicating it to user space using
'ETHTOOL_LINK_EXT_STATE_POWER_BUDGET_EXCEEDED'.
>
> >
> > I think the best way forward is to extend ethtool as was already
> > suggested. It should allow you to avoid the split brain situation where
> > the hardware is configured by both the kernel and an external tool.
>
> I'll try to follow up with the ethtool extension.
next prev parent reply other threads:[~2023-09-12 14:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 8:54 [PATCH iwl-next v2] ice: Disable Cage Max Power override Wojciech Drewek
2023-08-24 9:38 ` Przemek Kitszel
2023-08-24 15:32 ` Jakub Kicinski
2023-08-25 11:01 ` Drewek, Wojciech
2023-08-26 0:54 ` Jakub Kicinski
2023-08-27 8:47 ` Ido Schimmel
2023-08-29 9:12 ` Drewek, Wojciech
2023-08-30 15:17 ` Ido Schimmel
2023-09-01 13:34 ` Drewek, Wojciech
2023-09-12 14:26 ` Ido Schimmel [this message]
2023-09-15 13:15 ` Drewek, Wojciech
2023-09-21 12:09 ` Ido Schimmel
2023-10-05 13:58 ` [Intel-wired-lan] " Drewek, Wojciech
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=ZQB1HcpTsB2Sf6Co@shredder \
--to=idosch@idosch.org \
--cc=idosch@nvidia.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=wojciech.drewek@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;
as well as URLs for NNTP newsgroup(s).