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 Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/1962490
Title:
Support VF groups rate limit
Status in linux-bluefield package in Ubuntu:
New
Bug description:
* 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1962490/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
