Re: [PATCH net-next 0/5] devlink rate police limiter
From: Jakub Kicinski <kuba@kernel.org>
Date: 2022-07-07 20:17:03
On Thu, 7 Jul 2022 13:20:12 +0200 Jiri Pirko wrote:
Wait. Lets draw the basic picture of "the wire": --------------------------+ +-------------------------- eswitch representor netdev|=====thewire====|function (vf/sf/whatever --------------------------+ +------------------------- Now the rate setting Dima is talking about, it is the configuration of the "function" side. Setting the rate is limitting the "function" TX/RX Note that this function could be of any type - netdev, rdma, vdpa, nvme.
The patches add policing, are you saying we're gonna drop RDMA or NVMe I/O?
Configuring the TX/RX rate (including groupping) applies to all of these.
I don't understand why the "side of the wire" matters when the patches target both Rx and Tx. Surely that covers both directions.
Putting the configuration on the eswitch representor does not fit: 1) it is configuring the other side of the wire, the configuration should be of the eswitch port. Configuring the other side is confusing and misleading. For the purpose of configuring the "function" side, we introduced "port function" object in devlink. 2) it is confuguring netdev/ethernet however the confuguration applies to all queues of the function.
If you think it's technically superior to put it in devlink that's fine. I'll repeat myself - what I'm asking for is convergence so that drivers don't have to implement 3 different ways of configuring this. We have devlink rate for from-VF direction shaping, tc police for bi-dir policing and obviously legacy NDOs. None of them translate between each other so drivers and user space have to juggle interfaces.