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]
Message-ID: <5790200B.8000201@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ