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.
