Hi, please allow me to revive this old thread...
On Thu, 2023-08-24 at 09:04 +0200, Jiri Pirko wrote: > > Wed, Aug 23, 2023 at 09:13:34PM CEST, [email protected] wrote: > > > > > > > > On 8/22/2023 8:34 AM, Jiri Pirko wrote: > > > > > > Tue, Aug 22, 2023 at 05:12:55PM CEST,[email protected] wrote: > > > > > > > > On Tue, 22 Aug 2023 08:12:28 +0200 Jiri Pirko wrote: > > > > > > > > > > NACK! Port function is there to configure the VF/SF from > > > > > > > > > > the eswitch > > > > > > > > > > side. Yet you use it for the configureation of the actual > > > > > > > > > > VF, which is > > > > > > > > > > clear misuse. Please don't > > > > > > > > Stating where they are supposed to configure the rate would be > > > > > > > > helpful. > > > > > > TC? > > > > > > > > Our implementation is an extension to this commit 42c2eb6b1f43 ice: > > > > Implement > > > > devlink-rate API). > > > > > > > > We are setting the Tx max & share rates of individual queues in a VF > > > > using > > > > the devlink rate API. > > > > > > > > Here we are using DEVLINK_PORT_FLAVOUR_VIRTUAL as the attribute for the > > > > port > > > > to distinguish it from being eswitch. > > > > I understand, that is a wrong object. So again, you should use > > "function" subobject of devlink port to configure "the other side of the > > wire", that means the function related to a eswitch port. Here, you are > > doing it for the VF directly, which is wrong. If you need some rate > > limiting to be configured on an actual VF, use what you use for any > > other nic. Offload TC. I have a doubt WRT the above. Don't we need something more/different here? I mean: a possible intent is limiting the amount of resources (BW in the VF -> esw direction) that the application owing the VF could use. If that is enforced via TC on the VF side (say, a different namespace or VM), the VF user could circumvent such limit - changing the tc configuration - either by mistake or malicious action. Looking at the thing from a different perspective, the TX B/W on the VF side is the RX B/W on the eswitch side, so the same effect could be obtained with a (new/different) API formally touching only eswitch side object. WDYT? Thanks, Paolo _______________________________________________ Intel-wired-lan mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
