From: Jamal Hadi Salim <jhs@mojatatu.com>
To: John Fastabend <john.r.fastabend@intel.com>
Cc: Tom Herbert <therbert@google.com>,
John Fastabend <john.fastabend@gmail.com>,
Stephen Hemminger <stephen@networkplumber.org>,
ben@decadent.org.uk, "Brandeburg,
Jesse" <jesse.brandeburg@intel.com>,
Linux Netdev List <netdev@vger.kernel.org>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: Re: [RFC PATCH] net: add a rate_limit attribute to netdev_queue and a rtnetlink
Date: Sun, 14 Jul 2013 13:44:12 -0400 [thread overview]
Message-ID: <51E2E36C.8030307@mojatatu.com> (raw)
In-Reply-To: <51DE220A.40505@intel.com>
On 13-07-10 11:10 PM, John Fastabend wrote:
>
>> Will this be usable in the case that more than one queue shares a rate?
>
> Here I must not understand the question. Each queue has independent
> rate limiters. At least in the hardware supported by ixgbe. Maybe
> other hardware has a different implementation?
>
I think Tom might be alluding to scenarios where a rate (as a resource)
is shared by multiple ingress as well as egress interfaces (in your case
queues). This is a very popular use case with tc (in particular in
conjunction with IFB).
In such a case, the rate by itself would need to modeled as an indexable
attribute.
Some hardware (example modern broadcom switching chips, maybe yours)
are not capable; So the index would have local semantics as in your
case. But I know hardware that does support shared rates.
Maybe you could come up with IFLA_QUEUE_RATE_LOCAL vs
IFLA_QUEUE_RATE_GLOBAL which will encapsulate a global index
for the shared rate.
cheers,
jamal
next prev parent reply other threads:[~2013-07-14 17:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-10 14:04 [RFC PATCH] net: add a rate_limit attribute to netdev_queue and a rtnetlink John Fastabend
2013-07-10 21:18 ` Tom Herbert
2013-07-11 3:10 ` John Fastabend
2013-07-14 17:44 ` Jamal Hadi Salim [this message]
2013-07-14 21:14 ` Tom Herbert
2013-07-15 3:02 ` John Fastabend
2013-07-11 23:35 ` David Miller
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=51E2E36C.8030307@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=ben@decadent.org.uk \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.fastabend@gmail.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=therbert@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.