Message-ID: <20241004161041.0eb3aad6@kmaincent-XPS-13-7390>
Date: Fri, 4 Oct 2024 16:10:41 +0200
From: Kory Maincent <kory.maincent@...tlin.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Jonathan Corbet <corbet@....net>, Donald Hunter
 <donald.hunter@...il.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 linux-doc@...r.kernel.org, Kyle Swenson <kyle.swenson@....tech>, Dent
 Project <dentproject@...uxfoundation.org>, kernel@...gutronix.de
Subject: Re: [PATCH net-next 11/12] net: pse-pd: Add support for event
 reporting using devm_regulator_irq_helper

On Fri, 4 Oct 2024 16:02:15 +0200
Oleksij Rempel <o.rempel@...gutronix.de> wrote:

> On Fri, Oct 04, 2024 at 03:56:33PM +0200, Oleksij Rempel wrote:
> > On Thu, Oct 03, 2024 at 05:22:58PM +0200, Andrew Lunn wrote:  
>  [...]  
>  [...]  
>  [...]  
> > > 
> > > I think we will need two event, the base regulator event, and a
> > > networking event. Since it is a regulator, sending a normal regulator
> > > event makes a lot of sense. But mapping that regulator event to a
> > > netns:ifnam is going to be hard. Anything wanting to take an action is
> > > probably going to want to use ethtool, and so needs to be in the
> > > correct netns, etc. But it does get messy if there is some sort of
> > > software driven prioritisation going on, some daemon needs to pick a
> > > victim to reduce power to, and the interfaces are spread over multiple
> > > network namespaces.
> > > 
> > > What i don't know is if we can use an existing event, or we should add
> > > a new one. Often rtnetlink_event() is used:
> > > 
> > > https://elixir.bootlin.com/linux/v6.12-rc1/source/net/core/rtnetlink.c#L6679
> > > 
> > > but without some PSE information in it, it would be hard to know why
> > > it was sent. So we probably either want a generic ethtool event, or a
> > > PSE event.  
> > 
> > Hm... assuming we have following scenario:
> > 
> >                                   .---------   PI 1
> >                                  / .---------  PI 2
> >                    .========= PSE /----------( PI 3 ) NNS red
> >                   //              \----------( PI 4 ) NNS blue
> > Main supply      //                `---------( PI 5 ) NNS blue
> > o================´--- System, CPU
> > 
> > In this case we seems to have a new challenge:
> > 
> > On one side, a system wide power manager should see and mange all ports.
> > On other side, withing a name space, we should be able to play in a
> > isolated sand box. There is a reason why it is isolated. So, we should
> > be able to sandbox power delivery and port prios too. Means, by creating
> > network names space, we will need a power names space. 
> > 
> > I can even imagine a use case: an admin limited access to a switch for
> > developer. A developer name space is created with PSE budget and max
> > prios available for this name space. This will prevent users from DoSing
> > system critical ports.
> > 
> > At this point, creating a power name space will an overkill for this
> > patch set, so it should be enough to allow controlling prios over
> > ethtool per port and isolation support if needed. 

Yes, I will add simple ethtool notification for now to report events on each
interfaces.

> Oh, sorry, i'm too tired. Too many words are missing in my answer ...

Nearly the weekend!! Rest well!

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Powered by blists - more mailing lists