netdev - Re: [RFC] ethtool bandwidth per-queue commands

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 20 Jul 2016 18:06:19 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	ivan <khorivan@...il.com>, netdev@...r.kernel.org
Cc:	kan.liang@...el.com, David Miller <davem@...emloft.net>
Subject: Re: [RFC] ethtool bandwidth per-queue commands

On 16-07-20 01:00 PM, ivan wrote:
> Hi everyone.
> 
> The ethtool interface has ETHTOOL_PERQUEUE command that is used to
> read/set per-queue parameters for multiqueue Ethernet devices.
> 
> I want to apply additional per-queue commands like per-queue bandwidth
> and per-queue number of descriptors (like number of rings).
> 
> Currently only ETHTOOL_G/SCOALESCE sub commands are added for
> per-queue interface (but I haven't seen counterpart for ethtool util).
> 
> Using ETHTOOL_G/SCOALESCE per-queue command as an example,
> I'm going to add 2 additional and 2 known commands for ethtool
> per-queue interface:
> 
> ETHTOOL_G/SBANDWIDTH     /* Get/Set ethtool per queue bandwidth.
> Bandwidth can be set with % or absolute in Mb/s */
> 

For tx rate limiting we have an ndo op for this already,

   ndo_set_tx_maxrate

which can be tuned via sysfs at the moment. It would logically make
sense to add an rx rate limit if you are looking for something more
like a policer. Or do this via setup_tc() interface as we do with
mqprio qdisc today.

If you are interested in max and min rates per queue groups one such
possibility being a queue group of one you may find the ./net/dcb
stack interesting as well. Although the DCB spec has lots of bits
about protocols and such the kernel interfaces do not care if the
protocol is running at all. Unfortunately when this was done originally
we didn't make this as clear as we should have.

.John