On 2024-02-26 07:06, Jiri Pirko wrote:
In previous generations of Intel NICs the trasmit scheduler was only
limited by PCIe bandwidth when scheduling/assigning hairpin-badwidth
between VFs. Changes to E810 HW design introduced scheduler limitation,
so that available hairpin-bandwidth is bound to external port speed.
In order to address this limitation and enable NFV services such as
"service chaining" a knob to adjust the scheduler config was created.
Driver can send a configuration message to the FW over admin queue and
internal FW logic will reconfigure HW to prioritize and add more BW to
VF to VF traffic. As end result for example 10G port will no longer limit
hairpin-badwith to 10G and much higher speeds can be achieved.
Devlink loopback param set to "prioritized" enables higher
What's the downside of having this always on? > How is this different to
"enabled"? See more below.
FW reconfigures HW scheduler to use unallocated/unused resources to
support higher BW on loopback traffic. So if every PF has this option
set to prioritized it may not improve BW as there will be no extra
resources for specific port to utilize, but the exact number will vary
depending on supported port speeds, how many ports are enabled etc.
hairpin-badwitdh on related PFs. Configuration is applicable only to
8x10G and 4x25G cards.
Changing loopback configuration will trigger CORER reset in order to take
effect.
Example command to change current value:
devlink dev param set pci/0000:b2:00.3 name loopback value prioritized \
The name is misleading (IIU what the know is about). Could you think
about naming it differently?
Not sure I get this one. We support 3 loopback modes/settings and refer
to them as such.
Could you elaborate how it is misleading? What name would you suggest?
+ - Controls loopback behavior by tuning scheduler bandwidth.
+ Supported values are ``enabled``, ``disabled``, ``prioritized``.
+ The latter allows for bandwidth higher than external port speed
+ when looping back traffic between VFs. Works with 8x10G and 4x25G
Sorry, this is insufficient documentation. Does not tell me anything
about what the know is and how the values change the behaviour of that.
What would you like to see here? More elaborative explanation similar to
commit description or something else? This is fairly condensed
description of what the knob does. "Enabled/Disabled" should not need
much of a description.
