Re: [PATCH net-next v3 03/15] net: Add peer info to queue-get response

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 28 Oct 2025 19:08:10 -0700 David Wei wrote:
> >> I think up to us which side we want to show. My thinking was to allow user
> >> introspection from both, but we don't have to. Right now the above example
> >> was from the container side, but technically it could be either side depending
> >> in which netns the phys dev would be located.
> >>
> >> The user knows which is which based on the ifindex passed to the queue-get
> >> query: if the ifindex is from a virtual device (e.g. netkit type), then the
> >> 'peer' section shows the phys dev, and vice versa, if the ifindex is from a
> >> phys device (say, mlx5), then the 'peer' section shows the virtual one.
> >>
> >> Maybe I'll provide a better more in-depth example with both sides and above
> >> explanation in the commit msg for v4..  
> > 
> > Yes, FWIW my mental model is that "leaking" host information into the
> > container is best avoided. Not a problem, but shouldn't be done without
> > a clear reason.
> > Typical debug scenario can be covered from the host side (container X
> > is having issues with queue Y, dump all the queues, find out which one
> > is bound to X/Y).  
> 
> Makes sense, I didn't consider leaking host info in a container. Happy
> to remove the introspection from the container side, leaving it only on
> the host side when queues are dumped.
> 
> Like Daniel mentioned, I didn't add 'src/real' or 'dst/virtual' because
> I believed this information is implicit to the user when querying a
> netdev based on its type. Do you find this to be confusing? Happy to add
> a clarifying field in the nested struct.

In veth/netkit we call "peer" the other side of an equal pipe. Same for
ndo_get_peer_dev. Queue is not a peering situation, but rather an attachment
/ delegation of a sub-object from one netdev to another.

I'd use a term like delegation or grant when talking about the HW
queue. And assignment in context of virtual.