lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 11 Jul 2022 10:29:57 -0700 From: Jakub Kicinski <kuba@...nel.org> To: Jiri Pirko <jiri@...nulli.us> Cc: Jiri Pirko <jiri@...dia.com>, Dima Chumak <dchumak@...dia.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, Simon Horman <horms@...ge.net.au>, Michal Wilczynski <michal.wilczynski@...el.com> Subject: Re: [PATCH net-next 0/5] devlink rate police limiter On Sat, 9 Jul 2022 07:14:31 +0200 Jiri Pirko wrote: > >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. > >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. > > >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. > > >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. > 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. > 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. 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)?
Powered by blists - more mailing lists