Mon, Mar 03, 2025 at 11:06:23PM +0100, kuba@xxxxxxxxxx wrote: >On Thu, 27 Feb 2025 13:22:25 +0100 Jiri Pirko wrote: >> >> I'm not sure how you imagine getting rid of them. One PCI PF >> >> instantiates one devlink now. There are lots of configuration (e.g. params) >> >> that is per-PF. You need this instance for that, how else would you do >> >> per-PF things on shared ASIC instance? >> > >> >There are per-PF ports, right? >> >> 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. > >> >> Creating SFs is per-PF operation for example. I didn't to thorough >> >> analysis, but I'm sure there are couple of per-PF things like these. >> > >> >Seems like adding a port attribute to SF creation would be a much >> >smaller extension than adding a layer of objects. >> > >> >> Also not breaking the existing users may be an argument to keep per-PF >> >> instances. >> > >> >We're talking about multi-PF devices only. Besides pretty sure we >> >moved multiple params and health reporters to be per port, so IDK >> >what changed now. >> >> 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?
