Fri, Mar 15, 2019 at 09:44:54PM CET, jakub.kicin...@netronome.com wrote: >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 :(
Although I understand your hesitation, the host ports are also associated with the asic and should be under the devlink instance. It is just a matter of proper documentation and clear code to avoid confusions. > >> >> 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. >
