Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions

Wed, Dec 07, 2022 at 05:59:41PM CET, kuba@kernel.org wrote:

On Wed, 7 Dec 2022 14:10:42 +0100 Jiri Pirko wrote:

quoted

quoted

quoted

Why do we need this association at all?  

Someone someday may want netns delegation and if we don't have the
support from the start we may break backward compat introducing it.  

Hmm. Can you imagine a usecase?

Running DPLL control in a namespace / container.

I mean - I generally think netns is overused, but yes, it's what
containers use, so I think someone may want to develop their
timer controller SW in as a container?

The netdevices to control are already in the container. Isn't that
enough?

quoted

Link to devlink instance btw might be a problem. In case of mlx5, one
dpll instance is going to be created for 2 (or more) PFs. 1 per ConnectX
ASIC as there is only 1 clock there. And PF devlinks can come and go,
does not make sense to link it to any of them.

If only we stuck to the "one devlink instance per ASIC", huh? :)

Yeah...

quoted

Thinking about it a bit more, DPLL itself has no network notion. The
special case is SyncE pin, which is linked to netdevice. Just a small
part of dpll device. And the netdevice already has notion of netns.
Isn't that enough?

So we can't use devlink or netdev. Hm. So what do we do?
Make DPLLs only visible in init_net? And require init_net admin?
And when someone comes asking we add an explicit "move to netns"
command to DPLL?

Well, as I wrote. The only part needed to be network namespaced are the
netdev related pins. And netdevices have netns support. So my question
again, why is that not enough?