From: Stephen Hemminger <stephen@networkplumber•org>
To: John Fastabend <john.fastabend@gmail•com>
Cc: netdev@vger•kernel.org, therbert@google•com, ben@decadent•org.uk,
jesse.brandeburg@intel•com, jeffrey.t.kirsher@intel•com
Subject: Re: [RFC PATCH] net: add a tx_queue attribute rate_queue_limits in Mbps
Date: Mon, 24 Jun 2013 08:11:43 -0700 [thread overview]
Message-ID: <20130624081143.7424f455@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <20130624032407.7546.96685.stgit@nitbit.x32>
On Sun, 23 Jun 2013 20:24:11 -0700
John Fastabend <john.fastabend@gmail•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
next prev parent reply other threads:[~2013-06-24 15:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 3:24 [RFC PATCH] net: add a tx_queue attribute rate_queue_limits in Mbps John Fastabend
2013-06-24 15:11 ` Stephen Hemminger [this message]
2013-06-24 18:03 ` John Fastabend
2013-06-25 19:00 ` Ben Hutchings
2013-06-25 21:08 ` John Fastabend
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130624081143.7424f455@nehalam.linuxnetplumber.net \
--to=stephen@networkplumber$(echo .)org \
--cc=ben@decadent$(echo .)org.uk \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=jesse.brandeburg@intel$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=therbert@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox