[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR05MB486663979B27ABD9B0281EBDD17B0@AM0PR05MB4866.eurprd05.prod.outlook.com>
Date: Fri, 8 Nov 2019 18:56:57 +0000
From: Parav Pandit <parav@...lanox.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: Jakub Kicinski <jakub.kicinski@...ronome.com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Saeed Mahameed <saeedm@...lanox.com>,
"kwankhede@...dia.com" <kwankhede@...dia.com>,
"leon@...nel.org" <leon@...nel.org>,
"cohuck@...hat.com" <cohuck@...hat.com>,
Jiri Pirko <jiri@...lanox.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
Subject: RE: [PATCH net-next 12/19] devlink: Introduce mdev port flavour
> -----Original Message-----
> From: Jiri Pirko <jiri@...nulli.us>
> Sent: Friday, November 8, 2019 12:34 PM
> To: Parav Pandit <parav@...lanox.com>
> Cc: Jakub Kicinski <jakub.kicinski@...ronome.com>;
> alex.williamson@...hat.com; davem@...emloft.net; kvm@...r.kernel.org;
> netdev@...r.kernel.org; Saeed Mahameed <saeedm@...lanox.com>;
> kwankhede@...dia.com; leon@...nel.org; cohuck@...hat.com; Jiri Pirko
> <jiri@...lanox.com>; linux-rdma@...r.kernel.org
> Subject: Re: [PATCH net-next 12/19] devlink: Introduce mdev port flavour
>
> Fri, Nov 08, 2019 at 07:23:44PM CET, parav@...lanox.com wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jiri Pirko <jiri@...nulli.us>
> >
> >[..]
> >> 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.
Powered by blists - more mailing lists