netdev - Re: [RFC PATCH] net: add a tx_queue attribute rate_queue

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130624081143.7424f455@nehalam.linuxnetplumber.net>
Date:	Mon, 24 Jun 2013 08:11:43 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	netdev@...r.kernel.org, therbert@...gle.com, ben@...adent.org.uk,
	jesse.brandeburg@...el.com, jeffrey.t.kirsher@...el.com
Subject: Re: [RFC PATCH] net: add a tx_queue attribute rate_queue_limits in
 Mbps

On Sun, 23 Jun 2013 20:24:11 -0700
John Fastabend <john.fastabend@...il.com> wrote:

> This adds a rate_queue_limit attribute to the tx_queue sysfs entry
> to allow rate limiting in units of Mpbs. Along with mqprio and BQL
> this provides another knob to tune queue performance. By default it
> is disabled with a setting of '0'.
> 
> By adding this as a queue attribute and _not_ a qdisc option allows
> using rate limits with qdisc schemes that may not align with tx rings
> and also allows using QOS schemes along with rate limits.
> 
> A sample implementation is provided for ixgbe. Any improvements or
> suggestions welcome I would also be interested to know if this works
> with other hardware and if Mbps is a good default unit.
> 
> I tested this briefly with iperf/netperf,
> 
> # echo 4000 > /sys/class/net/p3p2/queues/tx-0/tx_rate_limit
> # cat /sys/class/net/p3p2/queues/tx-0/tx_rate_limit
> 4000

I like the facility and there is a real need for it, but we need
to think about what best API for it is.

There are several possible API's for this. My preference in order is:
  1. Netlink: 
       PRO: most well structured and can notify control applications
       CON: doesn't propagate well down to device
  2. Ethtool:
       PRO: fits current model of speed/duplex
       CON: still and ioctl based model, non-extensible structures
  3. Sysfs
       PRO: easy to add
       CON: not a general mechanism, ends up being per-device
  4. Module parameter
       PRO: easy to code
       CON: hard to manage from application, hard to associate with multiple devices

     
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html