> -----Original Message----- > From: Jiri Pirko <jiri@xxxxxxxxxxx> > Sent: Friday, November 8, 2019 12:34 PM > To: Parav Pandit <parav@xxxxxxxxxxxx> > Cc: Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx>; > alex.williamson@xxxxxxxxxx; davem@xxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; > netdev@xxxxxxxxxxxxxxx; Saeed Mahameed <saeedm@xxxxxxxxxxxx>; > kwankhede@xxxxxxxxxx; leon@xxxxxxxxxx; cohuck@xxxxxxxxxx; Jiri Pirko > <jiri@xxxxxxxxxxxx>; linux-rdma@xxxxxxxxxxxxxxx > Subject: Re: [PATCH net-next 12/19] devlink: Introduce mdev port flavour > > Fri, Nov 08, 2019 at 07:23:44PM CET, parav@xxxxxxxxxxxx wrote: > > > > > >> -----Original Message----- > >> From: Jiri Pirko <jiri@xxxxxxxxxxx> > > > >[..] > >> Well, I don't really need those in the phys_port_name, mainly simply > >> because they would not fit. However, I believe that you should fillup > >> the PF/VF devlink netlink attrs. > >> > >> Note that we are not talking here about the actual mdev, but rather > >> devlink_port associated with this mdev. And devlink port should have this > info. > >> > >> > >> > > >> >> >What in hypothetical case, mdev is not on top of PCI... > >> >> > >> >> Okay, let's go hypothetical. In that case, it is going to be on > >> >> top of something else, wouldn't it? > >> >Yes, it will be. But just because it is on top of something, doesn't > >> >mean we > >> include the whole parent dev, its bridge, its rc hierarchy here. > >> >There should be a need. > >> >It was needed in PF/VF case due to overlapping numbers of VFs via > >> >single > >> devlink instance. You probably missed my reply to Jakub. > >> > >> Sure. Again, I don't really care about having that in phys_port_name. > >> But please fillup the attrs. > >> > >Ah ok. but than that would be optional attribute? > >Because you can have non pci based mdev, though it doesn't exist today along > with devlink to my knowledge. > > Non-optional now. We can always change the code to not fill it up or fill up > another attr instead. no UAPI harm. Ok. sounds good. Will implement this in the respin.
