Subject: Re: [RFC net-next 0/5] devlink: Add unique identifier to devlink port function

From: Jakub Kicinski <[email-masked]>
Date: Wed, 7 May 2025 17:43:08 -0700

On Tue, 6 May 2025 18:34:22 +0300 Mark Bloch wrote:
> >> Flow:
> >> 1. A user requests a container with networking connectivity.
> >> 2. Kubernetes allocates a VF on host X. An agent on the host handles VF
> >>    configuration and sends the PF number and VF index to the central
> >>    management software.  
> > 
> > What is "central management software" here? Deployment specific or
> > some part of k8s?  
> 
> It's the k8s API server.
> 
> >   
> >> 3. An agent on the DPU side detects the changes made on host X. Using
> >>    the PF number and VF index, it identifies the corresponding
> >>    representor, attaches it to an OVS bridge, and allows OVN to program
> >>    the relevant steering rules.  
> > 
> > What does it mean that DPU "detects it", what's the source and 
> > mechanism of the notification?
> > Is it communicating with the central SW during  the process?  
> 
> The agent (running in the ARM/DPU) listens for events from the k8s API server.

Interesting. So a deployment with no security boundaries. The internals
of the IPU and the k8s on the host are in the same domain of control.

So how does the user remotely power cycle the hosts?

What I'm getting at is that your mental model seems to be missing any
sort of HW inventory database, which lists all the hosts and how they
plug into the DC. The administrator of the system must already know
where each machine is exactly in the chassis for basic DC ops. And
that HW DB is normally queried in what you describe. If there is any
security domain crossing in the picture it will require cross checking
against that HW DB.

I don't think this is sufficiently well established to warrant new uAPI.
You can use a UUID and pass it via ndo_get_phys_port_id.