Wed, Jan 13, 2021 at 09:32:41AM CET, [email protected] wrote: >On Tue, Jan 12, 2021 at 08:21:22PM -0800, Jakub Kicinski wrote: >> On Tue, 12 Jan 2021 10:39:30 +0200 Ido Schimmel wrote: >> > From: Danielle Ratson <[email protected]> >> > >> > The switch ASIC has a limited capacity of physical ('flavour physical' >> > in devlink terminology) ports that it can support. While each system is >> > brought up with a different number of ports, this number can be >> > increased via splitting up to the ASIC's limit. >> > >> > Expose physical ports as a devlink resource so that user space will have >> > visibility to the maximum number of ports that can be supported and the >> > current occupancy. >> >> Any thoughts on making this a "generic" resource? > >It might be possible to allow drivers to pass the maximum number of >physical ports to devlink during their initialization. Devlink can then >use it as an indication to register the resource itself instead of the >driver. It can report the current occupancy without driver intervention >since the list of ports is maintained in devlink. > >There might be an issue with the resource identifier which is a 64-bit >number passed from drivers. I think we can partition this to identifiers >allocated by devlink / drivers. > >Danielle / Jiri?
There is no concept of "generic resource". And I think it is a good reason for it, as the resource is something which is always quite hw-specific. Port number migth be one exception. Can you think of anything else? If not, I would vote for not having "generic resource" just for this one case.
