Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports

Jakub Kicinski
2019-03-15T20:45:02Z

On Fri, 15 Mar 2019 21:08:14 +0100, Jiri Pirko wrote:
> >> IIUC, Jiri/Jakub are proposing creation of 2 devlink objects for each port -
> >> host facing ports and switch facing ports. This is in addition to the netdevs
> >> that are created today.

To be clear I'm not in favour of the dual-object proposal.

> >I am not proposing any different.
> >I am proposing only two changes.
> >1. control hostport params via referring hostport (not via indirect peer)
>
> Not really possible. If you passthrough VF into VM, the hostport goes
> along with it.
>
> >2. flavour should not be vf/pf, flavour should be hostport, switchport.
> >Because switch is flat and agnostic of pf/vf/mdev.
>
> Not sure. It's good to have this kind of visibility.

Yes, this subthread honestly makes me go from 60% sure to 95% sure we
shouldn't do the dual object thing :( Seems like Parav is already
confused by it and suggests host port can exist without switch port :(

> >> Are you suggesting that all the devlink objects should be visible only at the
> >> hypervisor layer?
> >>
> >Of course not.
> >
> >Ports and params controlled by hypervisor should be exposed at hypervisor/eswitch wherever its parent devlink instance exist.
> >Ports which should be visible inside a VM should be exposed inside a VM.
> >So for a given VF,
> >
> >If eswitch is at hypervisor level,
> >$ devlink port show
> >pci/0000:05:00.0/10002 eth netdev flavour switchport switch_id 00154d130d2f peer pci/0000:05:10.1/0
> >pci/0000:05:10.1/0 eth netdev flavour hostport switch_id 00154d130d2f peer pci/0000:05:00.0/10002
> >
> >where VF is enumerated,
> >$ devlink port show
> >pci/0000:05:10.1/0 eth netdev flavour hostport
>
> So this is how it looks like in VM, right?
>
> >This is because unprivileged VF doesn't have visibility to eswitch and its links.