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.
