> -----Original Message----- > From: Jakub Kicinski <[email protected]> > Sent: Wednesday, July 3, 2019 11:13 PM > To: Sudarsana Reddy Kalluru <[email protected]> > Cc: Jiri Pirko <[email protected]>; [email protected]; > [email protected]; Michal Kalderon <[email protected]>; Ariel > Elior <[email protected]> > Subject: Re: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for > configuration attributes. > > On Wed, 3 Jul 2019 12:56:39 +0000, Sudarsana Reddy Kalluru wrote: > > Apologies for bringing this topic again. From the driver(s) code > > paths/'devlink man pages', I understood that devlink-port object is an > > entity on top of the PCI bus device. Some drivers say NFP represents > > vnics (on pci-dev) as a devlink-ports and, some represents > > (virtual?) ports on the PF/device as devlink-ports. In the case of > > Marvell NIC driver, we don't have [port] partitioning of the PCI > > device. And the config attributes are specific to PCI-device (not the > > vports/vnics of PF). Hence I didn't see a need for creating > > devlink-port objects in the system for Marvell NICs. And planning to > > add the config attributes to 'devlink-dev' object. Please let me know > > if my understanding and the proposal is ok? > > I understand where you're coming from. > > We want to make that judgement call on attribute-by-attribute basis. > We want consistency across vendors (and, frankly, multiple drivers of the > same vendor). If attribute looks like it belongs to the port, rather than the > entire device/ASIC operation, we should make it a port attribute.
Thanks for your mail. I'll go with creating PCI-dev/0 (i.e., port-id 0) for port based attributes as there's no port partitioning for Marvell NICs.
