Mon, Jul 11, 2022 at 07:29:57PM CEST, kuba@kernel.org wrote:

On Sat, 9 Jul 2022 07:14:31 +0200 Jiri Pirko wrote:

quoted

quoted

I resisted the port function aberration as long as I could. It's   

Why do you say "aberration"? It is a legitimate feature that is allowing
to solve legitimate issues. Maybe I'm missing something.

From netdev perspective it's an implementation detail irrelevant 
to the user. The netdev model is complete without it.

Well it is a configuration of a device part out of the scope of netdev.
So yes, netdev model is complete without it. But does does not mean we
don't need such configuration. I may be missing your point.

quoted

quoted

a limitation of your design as far as I'm concerned.  

What do you mean? This is not related to us only. The need to work with
port function (the other side of the wire) is definitelly nothing
specific to mlx5 driver.

quoted

Switches use TC to configure egress queuing, that's our Linux model.
Representor is the switch side, TC qdisc on it maps to the egress
of the switch.  

Sure.

quoted

I don't understand where the disconnect between us is, you know that's
what mlxsw does..  

No disconnect. mlxsw works like that. However, there is no VF/SF in
mlxsw world. The other side of the wire is a different host.

However in case of VF/SF, we also need to configure the other side of
the wire, which we are orchestrating. That is the sole purpose of why we
have devlink port function. And once we have such object, why is it
incorrect to use it for the needed configuration?

So the function conversation _is_ relevant here, eh? Sad but it is what
it is.

I'm not sure I follow what "function conversation" you mean. :/

quoted

Okay, if you really feel that we need to reuse TC interface for this
feature (however mismathing it might be),

Not what I said, I'm not gonna say it the fourth time.

Okay, sorry for being slow, but I still don't understand your point :/

quoted

lets create a netdev for the port function to hook this to. But do we
want such a beast? But to hook this to eswitch port representor seems
to me plain wrong.

I presume you're being facetious. Extra netdev is gonna help nothing. 

I'm somewhat am, yes.

AFAIU the problem is that you want to control endpoints which are not
ndevs with this API. Is that the main or only reason? Can we agree that
it's legitimate but will result in muddying the netdev model (which in
itself is good and complete)?

I don't think this has anything to do with netdev model. It is actually
out of the scope of it, therefore there cannot be any mudding of it.