Thread (26 messages) 26 messages, 4 authors, 2022-07-14

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help