Public bug reported:
* Explain the feature
Managing TX rate of VFs becomes non-trivial task when a big number of VFs are
used. This issue can be handled with some grouping mechanism.
Currently driver provide two ways to limit TX rate of the VF: TC police
action and NDO API callback. Implementation of grouping within this two
infrastructures problematic, due to the following:
NDO API rate limiting is legacy feature, even though it's available in
switchdev mode, and extending it with new abstraction is not good
anyway;
TC police action is flow based and requires net device with Qdisc on it and
implementing this will bring unwanted complications.
According to aforesaid devlink is the most appropriate place.
* How to test
Set tx_max value on the devlink port with a command. For ex.:
$ devlink port function rate set pci/0000:82:00.0/1 tx_max 10gbit
or if grouping is required, create rate group with configured tx_max value in a
single command and assign port to this group:
$ devlink port function rate add pci/0000:82:00.0/1st_group tx_max 8gbit
$ devlink port function rate set pci/0000:82:00.0/1 tx_max 10gbit parent
1st_group
Configuration is done. Run traffic and do measurement.
* What it could break.
As this pull request backported 130 patches from devlink/netlink, it may break
some functionalities from net core layer. Also, the network drivers which are
not used by BF are disabled to avoid the fix of conflicts.
** Affects: linux-bluefield (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1962490
Title:
Support VF groups rate limit
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1962490/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs