Wed, Mar 05, 2025 at 01:04:12AM +0100, kuba@xxxxxxxxxx wrote: >On Tue, 4 Mar 2025 14:11:40 +0100 Jiri Pirko wrote: >> Mon, Mar 03, 2025 at 11:06:23PM +0100, kuba@xxxxxxxxxx wrote: >> >On Thu, 27 Feb 2025 13:22:25 +0100 Jiri Pirko wrote: >> >> Depends. On normal host sr-iov, no. On smartnic where you have PF in >> >> host, yes. >> > >> >Yet another "great choice" in mlx5 other drivers have foreseen >> >problems with and avoided. >> >> What do you mean? How else to model it? Do you suggest having PF devlink >> port for the PF that instantiates? That would sound like Uroboros to me. > >I reckon it was always more obvious to those of us working on >NPU-derived devices, to which a PCIe port is just a PCIe port, >with no PCIe<>MAC "pipeline" to speak of. > >The reason why having the "PF port" is a good idea is exactly >why we're having this conversation. If you don't you'll assign >to the global scope attributes which are really just port attributes. Well, we have devlink port for uplink for this purpose. Why isn't that enough? > >> >> Looks like pretty much all current NICs are multi-PFs, aren't they? >> > >> >Not in a way which requires cross-port state sharing, no. >> >You should know this. >> >> This is not about cross-port state sharing. This is about per-PF >> configuration. What am I missing? > >Maybe we lost the thread of the conversation.. :) >I'm looking at the next patch in this series and it says: > > devlink: Introduce shared rate domains > > The underlying idea is modeling a piece of hardware which: > 1. Exposes multiple functions as separate devlink objects. > 2. Is capable of instantiating a transmit scheduling tree spanning > multiple functions. > > Modeling this requires devlink rate nodes with parents across other > devlink objects. > >Are these domains are not cross port? Sure. Cross PF even. What I suggest is, if we have devlink instance of which these 2 PFs are nested, we have this "domain" explicitly defined and we don't need any other construct.
